RE: [security-services] Trust management and validation viametadata

Indirect trust support in metadata could be a very powerful thing. For me, the goal is less administration. If an admin has to manually configure an entity that is indirectly trusted, then we haven't bought much. If an administrator only has to configure data on a Certificate Authority level then we have made his life simpler. So here is my suggestion:

It seems backward that entities would submit both their certificates and metadata to a CA. Let's have the CA sign some meta-data, including it's certificate, attributes supported, name-formats supported and maybe authentication classes supported (exclude endpoints). Let the CA sign this 'super-metadata' send this out to the sub-entities with the signed certificate chains. The sub-entity can then embed this 'super-metadata' in it's own metadata, creating a meta-data chain.

The administrative advantage comes when creating attribute and NameID mapping. When trust is established in the CA, there is an associated configuration that can be re-used for all entities certified by the CA. Another advantage is the sub-entity would not have to re-submit his metadata to be re-signed every time attributes are added or endpoints are changed.

Lets say my SP sells discounts to university students from Utah. So I create one trust relationship with the State of Utah by importing the department of education's CA certificate. I know that all of Utah's universities support the eduPerson attributes and the kerberos nameID format (I know this by reading the super-metadata of one of the universities.) I create a mapping for eduPerson and Kerberos nameID to my local database or application. Then I associate this mapping to this trust relationship with the state of Utah. When a student from any Utah university accesses me, I will need a metadata locator service (I'm thinking something like Shibboleth's WAYF), but after that everything can be automatic.

security-services message