Comments on sstc-saml-x509-authn-attrib-profile-draft-11

["Ari Kermaier" <ari.kermaier@oracle.com>]

I suppose it's bad form to upload a draft and then post comments on it myself the next day, but I noticed something that might bear discussion and modification.

The X.509 attribute sharing profile discusses requirements for a successful samlp:Response to the samlp:AttributeQuery, and defines behavior w.r.t. presence/number of saml:Assertion and saml:AttributeStatement elements.

In both sstc-saml-x509-authn-attrib-profile-cd-02 [lines 174-176] and sstc-saml-x509-authn-attrib-profile-draft-10 [lines 184-186], it requires a successful Response to have exactly 1 Assertion, and exactly 1 AttributeStatement.

Mailing list and meeting discussion threads arrived at the conclusion that there was no need to restrict a Response from carrying multiple Assertion and/or AttributeStatement elements. Thus, I modified the language in sstc-saml-x509-authn-attrib-profile-draft-11 [lines 185-186] to read:

"Any <Assertion> element(s) MUST satisfy the following conditions:
The <Assertion> element MUST contain at least one <AttributeStatement> element that conveys the attributes of the principal to the service provider."

Thinking about implementation, however, caused me to have second thoughts about this language:

Since the [SAMLCore] schema requires at least 1 Attribute element in an AttributeStatement, a response in which none of the requested user attributes could be returned (e.g., the attributes do not exist) could not have an empty AttributeStatement. This means that, according to either the new or old language, the Response could not contain an Assertion with no AttributeStatement; the new language provides the ability to omit the Assertion entirely in this case.

But is this the best behavior? The case of no Attributes to return might be better handled by returning a Response containing an Assertion (with the correct Subject) but with no AttributeStatement. Maybe the new language should be changed to require 1 or more Assertions in a successful response, but allow 0 or more AttributeStatements.

Thoughts?

Thanks,
Ari Kermaier
Oracle