Attribute encoding - meaning of 'name' with URL

[Cantor, Scott]

On 7/31/14, 7:36 PM, "John Horne" <john.horne at plymouth.ac.uk> wrote:

>> 
>Okay, and to some extent that's what I ended up thinking. However, the
>attribute already has an 'id' defined, so why not use that instead of
>requiring the 'name' field as well?

Because it's a very inflexible design to tightly couple your internal
nomenclature to distributed system requirements. The essence of a
metadirectory is that indirection.

>It also seems to confirm though that this (name) is simply something
>agreed between the IdP and SP, and in itself may well have no meaning.

Do names ever have meaning? You're talking about philosophy basically.

When you define a standard like SAML, you define what names are supposed
to mean and how they get used. I spent a very, very long time doing that
because naming is so crucial to software.

>That is, I could just as easily have agreed to use the name 'fred',
>'xyz' or 'hjhj4343-sasa'. If the IdP sends it, and the SP can map it to
>a local attribute, then shibboleth communication between the IdP and SP
>should work regardless of the fact that the 'name' is meaningless.

All names are meaningless in that sense. And yes, that's all true, but
having done so, you'd have an invalid SAML attribute because the
NameFormat is set by default in Shibboleth's encoders to the URN constant
that tells the consumer the attribute name is a URI. Shibboleth, unlike
most sloppy software, pays attention to that when it maps attributes.

If you want to name attributes using non-URI strings with no expectation
of interop, then you'd use the NameFormat constant for what's called the
"basic" name format.

>The use of an OID, where available, I assume basically simplifies this
>process in that both the IdP and SP use specific OIDs for specific
>attributes. That is, if the SP wants the EPPN attribute, then the IdP
>sends it with the OID of 1.3.6.1.4.1.5923.1.1.1.6. The SP expects that
>OID to be used because it is well-defined for the EPPN attribute.

The OIDs are used for all of those reasons and because the most common
access protocol, LDAP, uses OIDs itself, and already has a lot of defined
attributes that have those names. Using OIDs means it's possible to assume
what a SAML attribute name should be even if there isn't any explicit rule
somewhere telling you. It avoids arguments, or at least provides people
with the ammunition to have the argument when people who don't care about
technical precision just make things up.

-- Scott