OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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"/>

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

(1) Represent policy directly in terms of AttributeDesignators, so no
further processing is necessary

(2) Maintain a mapping table from AttributeDesignators to internal attribute

(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"/>
        <any namespace="##any" minOccurs="0" processContents="lax">

I may not have the XML Schema exactly right, but the intention is to allow:


<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>
	  <!-- ... -->

The empty form of attribute would be used in samlp:AttributeQuery, like:

                saml:Name="cn=Irving Reid,o=baltimore.com">
    <saml:Attribute saml:Name="urn:canadianstage.ca:productions:role"/>

 - 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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC