Comments/questions on sstc-saml-metadata-2.0-cd-02

Our engineering team had a number of questions/comments on
metadata:

 

 
The <EntitiesDescriptor>
     element permits nesting of one or more <EntitiesDescriptor> element(s)
     inside it.  It would be helpful to have some description of what
     semantics are intended when this is done.  For example, how do the
     various attributes (e.g. validUntil) get inherited by the child
     <EntitiesDescriptor> elements and their children?

 

 
According to schema you can
     have any number of <RoleDescriptor>, <IDPSSODescriptor>, …
     elements inside an EntityDescriptor. The assumption is that this is
     because a single entity can take on any of the roles.  However, there
     isn’t any normative text saying that you can only have one of each
     of the various role descriptors.  So what would it mean if an <EntityDescriptor>
     element contains multiple <IDPSSODescriptor> elements, each with
     different settings?  Is this allowed?

 

 
There is no metadata to
     indicate that an entity supports the URI protocol binding. Should we add
     something for this?

 

 
It may be difficult to work out
     with the current structure, but the current inclusion of certain
     attributes and elements in the metadata mean that the setting has to apply
     to all trusted partner connections and in our experience, this is often
     undesirable.  For example, the “WantAuthnRequestsSigned”
     attribute on an IDPSSODescriptor means that ALL partner sights must comply
     with the setting.  If omitted it as declared to be false.  I may
     need to have some SP’s connect with unsigned requests and other SP’s
     connect with signed requests.  It’s worse when looking at the “AuthnRequestsSigned”
     attribute of the <SPSSODescriptor> element.  My SP may have many
     different IDP’s.  What if one IDP requires signed requests and
     another requires they not be signed.  This seems to require a
     complete coordination of settings across all IDPs and SPs in a realm and
     this seems quite unrealistic. We could potentially deal with this by
     permitting multiple copies of the role descriptor elements, each with
     different settings (see #2 above).  However, if there are multiple
     IDPSSODescriptor elements, we currently would have no way to determine
     which one applies to any particular message exchange.

 

 
The metadata doesn’t help
     define Web SSO arrangements where the SSO assertions should carry one or
     more AttributeStatements. [Of course, neither does the AuthnRequest
     protocol.]  This is a very common configuration and figuring out how
     to represent this in metadata would be useful.

 

 
Separate from #5, if a web SSO
     exchange DOES carry attributes (even though it’s not defined by metadata),
     AND an AttributeAuthorityDescriptor is defined, we assume that use of the
     attributes in the first case is completely separate from declarations
     within the AttributeAuthorityDescriptor. For example, we assume it is
     valid to push attributes in an SSO assertion that are defined by one
     profile even if the AttributeAuthorityDescriptor indicates that it doesn’t
     support that profile.

 

 
We provide no guidance on the
     use of multiple endpoint declarations for the same service when the
     endpoint is defined with EndpointType (i.e. it isn’t an
     IndexedEndpointType).  For example, for the SingleSignOnService
     element in the IDPSSODescriptor is of type EndpointType but allows more
     than one to be specified. How does an SP choose which one to use when more
     than one is present?

 

Rob Philpott

Senior Consulting Engineer 

RSA Security Inc. 

Tel: 781-515-7115 

Mobile: 617-510-0893 

Fax: 781-515-7020 

mailto: