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

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

On Sun, 10 Feb 2002, Scott Cantor wrote:

> > 1. To join the attribute's name and governing namespace into a single
> >     URI-based string
>
> I'm in favor of #1, because after working through various examples and
> syntax experiments within our project, I've become convinced that
> identifying attributes with URI (most likely URN) strings is going to
> be the least confusing to deal with. If we have to populate two
> potential SAML attributes, we'll have to arbitrarily decide without
> any real justification how or whether to separate the URI. So I guess
> this would get us off the hook. ;-)

I agree with the motivation here, since as Irving points out if we leave
too many degrees of freedom here it's system deployers (such as Scott and
me with our Shib hats on) who suffer by having too much stuff to decide
(someone once said "like having an arm with 7 elbows").  But I have an
example below that leads me to think that keeping attr-namespace and
attr-name distinct would be a good thing.  The summary of the rambling
below is this:  if we were starting with a clean sheet in defining SAML
attributes then it would be easy to make them all be nice well-structured
URIs, but I think the spirit of SAML is to be able to transmit stuff that
has been previously defined in other technologies, and for that a two-part
AttributeDesignator will be useful.

The example is the one Stephen asked for:  how existing X.500-style
attributes (actually attribute types) should be represented as SAML
attributes.  Here's how that might work.

There's lots of X.500-style schema out there in lots of directories, and
IMHO it would be attractive (1) to be able to use this stuff directly as
SAML attributes without having to redefine it all in XML schema, and (2)
to unambiguously represent any given X.500-style attribute type with a
SAML AttributeDesignator.  DSMLv2 has existing schema that should do this,
including:

  <xsd:simpleType name="AttributeDescriptionValue">
    <xsd:restriction base="xsd:string">
      <xsd:pattern
value="((([0-2](\.[0-9]+)+)|([a-zA-Z]+([a-zA-Z0-9]|[-])*))(;([a-zA-Z0-9]|[-])+)*)"/>
    </xsd:restriction>
  </xsd:simpleType>

where AttributeDescriptionValue is DSML-speak for SAML AttributeDesignator
or X.500 attribute type.  The big pattern is (I think) intended to allow
attribute types to be indicated either by name (like "commonName") or
stringified OID (like "1.3.6.1.4.1.1466.101.120.14").  (And for those not
keeping score at home, I believe the current thinking in LDAP-land is that
putting attributes names on the wire was a mistake, so going forward only
a well-defined set of global names, like CN, will be sent, and all other
attributes will be labelled with their OIDs on the wire.)  So, for SAML,
we might say that the preferred representation of X.500-style attribute
types would be:

  AttributeNamespace=<some URI indicating "X.500-style attribute type">
  AttributeName=<the name or OID of the attribute type>

It would certainly be possible to glue these together into a single
string, but separating them just seems cleaner, and permits re-use of an
already-defined DSML type.  This is probably a case of, as Irving wrote:

> (3) Use the attribute namespace to determine what area of policy
> applies, and then do all further processing based on name only

which I think will be a useful thing to do.  There may be other attribute
spaces out there that similarly could be imported.

So, I'm inclined to think that attr-name and attr-namespace should stay
separate.

 - RL "Bob"