SAML 2 profile questions

Here are questions about the SAML 2 profile draft (see http://wiki.oasis-open.org/imi/SAML2TokenProfile). Thanks for writing this document, Scott.

There are a number of places where the draft says “SIP”, and what I think is meant is “IMI 1.0”. In fact, I haven’t found one instance where the draft is actually referring to the Simple Identity Provider (SIP) profile (for self-issued cards). These references should be updated.

2.3.3 states:

Assertions issued in accordance with this profile MUST contain a single <saml:AuthnStatement> that reflects the authentication of the token requester to the identity provider. It MAY contain a single <saml:AttributeStatement> that carries one or more <saml:Attribute> elements reflecting the claims requested by the relying party, in the manner specified by SIP.

In 2.3.3, why is the AuthnStatement mandatory, rather than optional? Isn’t it legitimate to have the token convey claims while being silent about authentication?

Similarly, why is the AttributeStatement optional? Because sometimes there are no claims?

In 2.3.3, the draft states:

If the requested claim types include a claim type with a URI corresponding to a SAML name identifier format known to the identity provider, it may satisfy that claim request by including a <saml:NameID> element of the proper format in the assertion's subject.

Does this mean that there would be a claim whose value does not come from a saml:AttributeValue element of a saml:AttributeStatement, but instead, whose value comes from the saml:NameID value of the saml:Subject? Could you give an example so we have a better idea what this would look like and what the goal is here?

In 2.3.3, the draft states that “the assertion MUST be signed”. I understand the value of this, but I’d like us to at least discuss this before assuming that this should be a MUST. For instance, is this a MUST when the token is used with the SAML 2.0 protocol?

2.3.4 states that “The <saml:SubjectConfirmationData> element, if present, MUST NOT contain a NotBefore or Recipient XML attribute.” Why is that the case?

In 2.4.1, why is the token type not urn:oasis:names:tc:SAML:2.0:assertion as per the IMI 1.0 spec example, rather than http://docs.oasisopen.

org/imi/ns/token/saml2/200908, which seems like an unnecessary introduction of a new identifier?

2.4.3 states “If it does include a <wsp:AppliesTo> element, it SHOULD NOT identify itself using the location of its endpoint, as this complicates the identity provider's ability to identify the relying party. A logical name SHOULD be used instead.” Given that existing practice is typically to use an endpoint, shouldn’t this be softened to admit the use of either logical identifiers or endpoint addresses?

2.4.4 Again refers to the NameID element in the context of language talking about claims. Is it the intent of the spec that a special case be made for NameID to treat it as a means of representing a claim, even though it is not a SAML 2.0 attribute?

Somebody who’s more of an expert in SAML metadata than me should probably review 2.5 more closely. John???

2.6 states “The Information Card model's support for hiding the identity of the relying party from the identity provider, combined with constraints on the implementation of the model for use with web browsers, leads to requests for "unconstrained" bearer assertions with no audience or subject confirmation conditions on use. This is extremely dangerous and insecure, even if assertion validity is extremely short term. This profile recommends against such a practice and urges implementations, if they do support such behavior, to enable deployers to disable it by requiring requests for bearer assertions be accompanied by the identity of the relying party.” Do others feel that this criticism of non-auditing cards, which have important privacy properties, is a bit over the top?

-- Mike

imi message