AI 245

[Greg Whitehead <greg.whitehead@hp.com>]

> d. *LDAP Attribute Profile (saml-profiles-saml2.0)

> http://www.oasis-open.org/archives/security-services/200601/msg00013.html

This seems to have settled out.  We may need a couple of errata items to ensure that the thread doesn't have to be re-enacted again later!

One issue is just an error in the spec example.  Another issue is whether the ASN.1 wrapper is intended to handle binary data.  The tendency seems to be to avoid having the additional wrapper layer. If you include the base64-encoded value directly, using the LDAP profile for it doesn't have any particular implication for special processing.  Finally, there's a philosophical issue about attribute syntax assumptions.  You can't assume anything about the encoding of values by looking at the name format; it would be a local deployment issue.  Out-of-band agreement will be necessary at some level.

AI: Greg W. to propose some clarifying text for the attribute profile section.

As documented in the minutes from that fateful day when I got my AI, there are two separate issues:

1) LDAP Attribute Profile, binary values

saml-profiles-2.0-os.pdf line 1762

In describing the encoding for binary values, the LDAP profile text is ambiguous about whether the ASN.1 OCTET STRING wrapper should be included or not. The consensus on the call was that it should NOT be included. I propose the following change to the text:

"... by base64-encoding [RFC2045] the encompassing ASN.1 OCTET STRING-encoded LDAP attribute value."

->

"... by base64-encoding [RFC2045] the contents of the ASN.1 OCTET STRING-encoded LDAP attribute value (not including the ASN.1 OCTET STRING wrapper)."

2) Philosophical issue about attribute syntax

Let me go on record (again) as saying that I'm not happy with this... but it's what we've got and we need to document it.

"Note that nothing can be inferred from an Attribute's NameFormat about the syntax of it's attribute values. That is, attribute name formats may be re-used across multiple attribute profiles and so the use of a particular name format in an Attribute cannot be used to infer the use of a particular attribute profile. The implication of this is that deployments MUST agree out-of-band on which attribute profile to use for each attribute name (where an attribute name is identified by a unique combination of Name and NameFormat)."

At a minimum, I think this should go in saml-core-2.0-os.pdf after line 1217. It may be worth repeating in the introduction to the SAML Attribute Profiles section in saml-profiles-2.0-os.pdf.

-Greg