OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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


  1. 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?


  1. 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?


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


  1. 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.


  1. 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.


  1. 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.


  1. 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]