shibboleth-dev - [security-services] A Modest Proposal about Attribute Names (fwd)
Subject: Shibboleth Developers
List archive
- From: "RL 'Bob' Morgan" <>
- To: Shibboleth Design Team <>
- Subject: [security-services] A Modest Proposal about Attribute Names (fwd)
- Date: Fri, 8 Feb 2002 11:38:52 -0700 (MST)
Eeyow!
So ... I think I agree, but I'm headed off for a long non-laptop-attached
(well, probably) weekend so won't have time to reply today ...
Seems like we should think about our common examples and see whether we'd
have any problems expressing them with this. I don't think so but it's
worth the exercise.
- RL "Bob"
---------- Forwarded message ----------
Date: Fri, 08 Feb 2002 13:26:05 -0500
From: Irving Reid
<>
To:
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 -
------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at
http://archives.internet2.edu/
------------------------------------------------------mace-shib-design--
- [security-services] A Modest Proposal about Attribute Names (fwd), RL 'Bob' Morgan, 02/08/2002
- RE: [security-services] A Modest Proposal about Attribute Names (fwd), Scott Cantor, 02/08/2002
Archive powered by MHonArc 2.6.16.