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

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

Pleeeeeeaaassseee!

We are going arround in circles here. The single URI attribute would bring
us almost full circle back to the original proposal in XTASS.

The argument over whether we have one attribute URI or the current structure
has been discussed at length at a face to face. 


At present the spec only allows one name per namespace. Separating the two
ideas would have more relevance if an attribute statement could have
multiple attributes with different names in the same namespace that is
declared only once.

Ie. 

namespace = http:/fred.org/fredness
	name = Alpha
	name = Beta

As it is the two can be combined quite easily:

http:/fred.org/fredness#Alpha

This would indicate some modest schema changes and eliminate one of the
empty elements that Eve hateth so much yea even unto the fifth generation,
etc.



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.

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.



		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: RL 'Bob' Morgan [mailto:rlmorgan@washington.edu]
> Sent: Tuesday, February 12, 2002 3:27 AM
> To: OASIS Security Services TC
> Subject: RE: [security-services] A Modest Proposal about 
> Attribute Names
> 
> 
> 
> 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"
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>

Phillip Hallam-Baker (E-mail).vcf