RE: [security-services] A Modest Proposal about Attribute Names

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

(Just bouncing the rubble here, as we agreed to leave the definition as is
on the call, but maybe some text below will be useful for the spec.)

On Tue, 12 Feb 2002, Hallam-Baker, Phillip wrote:

> The most obvious way to represent X.500 attributes would be to use the
> OID URN:
>
> namespace=OID:12.3.42.3.42.1.1.1
>
> There is no need for a name in this instance.

OK, I was going to bring this up.  Indeed all proper X.500-style attribute
types are identified by OIDs.  A unitary SAML AttributeDesignator (as
Irving proposed) could hold use the OID URN namespace, ala

  <saml:Attribute
   saml:Name="urn:oid:2.5.4.3">RL "Bob" Morgan</saml:Attribute>

which unambiguously indicates what the attribute type is (ie,
"commmonName" in this case).  OIDs can of course refer to many other kinds
of things, including, possibly, objects that are not X.500-style attribute
types but are still used as SAML attributes.  Again, I think it will be
common for SAML deployments to deal with many attribute spaces from
distinct technologies and it would be helpful to implementations to
indicate what kind of attribute-technology an attribute is, rather than,
say, in the above case having to grovel through a large set of
attribute-type repositories looking for an OID match.

And I'm sure the DSML definition of AttributeDescriptionValue to include
attribute names as well as OIDs was meant to accomodate how existing LDAP
implmentations work, ie that they'll use names by default.  So saying
"always use OIDs" would make (a little) more work for those plugging in
LDAP directories as attribute sources.

> I will do some research to find out the current status of the OID URI,
> if the toplevel scheme did not go through the URN scheme must have.

It's defined in RFC 3061, which is an Informational RFC.  So it has no
standard status per se, but it doesn't have to, seems to me, if people
just agree to use it.

 - RL "Bob"