[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] A Modest Proposal about Attribute Names
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'". 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. 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. 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. 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, 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> 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> - irving - ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.
Powered by eList eXpress LLC