[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] A Modest Proposal about Attribute Names
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC