RE: [security-services] Trust management and validationviametadata

>The point is to communicate a trust list in metadata. A KeyDescriptor inside
>a role doesn't naturally have the ability to do this.
Ok, I understand now.  This almost seems like a problem with the XMLSignature spec and not something we would define.
    

    

>>just assumed that if someone wanted indirect trust they would
>>always use a X509 certificate-chain (containing the root CA
>>and any subordinate CA info).  So is the problem when X509 is
>>not used?  

>No, that's not indirect trust. Say I send you such a chain in metadata.
>That's nice, but why bother? The metadata signer is basically saying the EE
>cert in the chain is your key, so what does the chain add? Nothing.

    

    
I agree that SSL is the usual use case for using x509 certificate chains - this being one type of indirect trust.  x509 cert chains are not limited to just this.  The "Trust Models Guidelines" specifies two types of trust, "Business Agreements" and "Authentication".  I took the authentication trust to mean SSL/PKI as you described it.  If I wanted indirect trust for the "business agreements" trust I could also use PKI/x509 certificate chains to establish this trust.
    

    
 

    
In fact, if I were to implement indirect trust, I would use PKI/x509 simply because I have those tools built here in house (or via OpenSSL).  I have avoided the indirect trust because of the administration issue I mentioned before: Even if the authentication trust and business trust were established indirectly, the administrator still has to manually create configuration for each entity - why not just establish direct trust?  
    

    
 

    
(I could only come up with one use case against this thinking: A CA that revokes and reissues certificates on a regular basis)
    

    
 

    
- Cameron