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

["Eve L. Maler" <eve.maler@sun.com>]

Some comments:

At 01:26 PM 2/8/02 -0500, Irving Reid wrote:
>I've been thinking about this for a while, and half-seriously brought it up
>on a conference call a week or two ago; Eve's (related) comments about
>NameIdentifier finally got me to react...
>
>A long time ago, at a F2F far, far away, we decided that attributes needed
>to be qualified in some way. The issue is that an assertion that says
>"Irving has role 'Hamlet'" is qualitatively different from an assertion that
>says "Irving has role 'Software Architect'".

I'm not sure that this example teases out the reason to qualify attribute 
names with attribute namespaces.  A better example would be "Irving has 
role 'Architect' as defined by 'The Software Co.'" vs. "Irving has role 
'Architect' as defined by 'Acme Architects'".

>At the F2F we discussed whether to specify attribute names as URIs, or to
>add an extra piece of XML data to specify the namespace. After not too much
>discussion, we decided on the current format:
>
><element name="AttributeDesignator" type="saml:AttributeDesignatorType"/>
><complexType name="AttributeDesignatorType">
>     <attribute name="AttributeName" type="string"/>
>     <attribute name="AttributeNamespace" type="anyURI"/>
></complexType>
>
>If I recall correctly, the reason we decided on the two-part format, with
>separate XML attributes for name and namespace, was so that implementations
>wouldn't need a URI parser in order to pull apart the attribute designator.
>
>As I see it, there are three ways that an implementation could use attribute
>designators:
>
>(1) Represent policy directly in terms of AttributeDesignators, so no
>further processing is necessary
>
>(2) Maintain a mapping table from AttributeDesignators to internal attribute
>names
>
>(3) Use the attribute namespace to determine what area of policy applies,
>and then do all further processing based on name only
>
>Nearly orthogonal (like, maybe a 70 degree angle) is the issue of deciding
>which attributes to accept from which authorities:
>
>(a) Keep a list of specific attributes acceptable from the authority
>
>(b) Treat the authority as authoritative for all attributes within a
>namespace (or list of namespaces)
>
>Of these approaches, (1), (2), and (a) all work perfectly well with URIs,
>since they never need to be disassembled. (3) and (b) require some form of
>parsing or wildcard processing.

As a colleague of mine says, "I can't disagree with your analysis" (which 
means I tried :-), but I'm just not sure how I feel about merging the name 
and the namespace.  At the least, we had better be consistent when it comes 
to action namespaces too.


>On the other hand, we've seen quite a bit of discussion over the
>AttributeNamespace attribute and how it is intended to be interpreted; I'm
>sure we'll have lots more questions raised when the outside world starts
>looking at our spec.

This is true, but I wonder if it's safer to allow for both pieces of 
information, especially considering that currently (yikes!) both attributes 
are optional.  I can see AttributeName being required and 
AttributeNamespace being optional, with a SHOULD or MUST in the conformance 
spec about identifying which attribute namespaces are supported.

>Even more important, in my opinion, is that the added
>XML elements cost us time and money. Processing time is a small factor, but
>more important is the extra time it will take developers to understand our
>naming scheme, code it correctly (as far as they can figure out), and then
>fix it so that it actually interoperates.

This is a mostly orthogonal argument, I think.  Most of the reduction in 
bulk seen below is from getting rid of AttributeValue and not from getting 
rid of an attribute.

>So, my Modest Proposal is to drastically simplify our Attribute structure:
>
><element name="Attribute" type="saml:AttributeType"/>
><complexType name="AttributeType">
>     <attribute name="Name" type="AnyURI"/>
>     <sequence>
>         <any namespace="##any" minOccurs="0" processContents="lax">
>     <sequence>
></complexType>
>
>I may not have the XML Schema exactly right,

(it looks accurate to me)

>but the intention is to allow:
>
><saml:Attribute
>saml:Name="urn:canadianstage.ca:productions:role">Hamlet</saml:Attribute>
>
><saml:Attribute saml:Name="urn:baltimore.com:employee">
>     <blme:Employee xmlns:blme="urn:baltimore.com:XML:HR:employee">
>         <blme:ID>123 456 789</blme:ID>
>         <blme:GN>Irving</blme:GN>
>         <blme:SN>Reid</blme:SN>
>           <!-- ... -->
>     </blme:Employee>
></saml:Attribute>

I thought we had decided, and re-decided, and re-re-decided, to change the 
way <AttributeValue> works such that it has a type of anyType rather than 
containing ##other.  If the <AttributeValue> element is removed entirely, 
this option goes away.  As a reminder to folks, here's how the instance 
would look with the modified <AttributeValue>:

   <saml:AttributeValue xsi:type="my:valueType">
     <blme:ID>123 456 789</blme:ID>
     <blme:GN>Irving</blme:GN>
     <blme:SN>Reid</blme:SN>
   </saml:AttributeValue>

>The empty form of attribute would be used in samlp:AttributeQuery, like:
>
><samlp:AttributeQuery
>          RequestID="1"
>          MajorVersion="1"
>          MinorVersion="0"
>          IssueInstant="2002-02-08T16:00:00.000Z">
>     <saml:Subject>
>         <saml:NameIdentifier
>                 saml:SecurityDomain="baltimore.com"
>                 saml:Name="cn=Irving Reid,o=baltimore.com">
>     </saml:Subject>
>     <saml:Attribute saml:Name="urn:canadianstage.ca:productions:role"/>
></samlp:AttributeQuery>

I'm not crazy about using the same parent element, <Attribute> in this 
case, for provision of both the value-ful and value-free versions.  It 
seems cleaner from the perspective of data binding not to conflate them.

In short, I think there are several proposals here:

1. To join the attribute's name and governing namespace into a single
    URI-based string

2. To reduce the syntax to merge <Attribute> and <AttributeDesignator>

3. To reduce the syntax to get rid of <AttributeValue> and just put
    content in <Attribute> directly.

I'm not sure about #1, but my intuition says to leave it alone.  I'm not in 
favor of #2 and #3.

         Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com