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

[Irving Reid <Irving.Reid@baltimore.com>]

> From: Eve L. Maler [mailto:eve.maler@sun.com]
> >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'".

No, these really are two different issues. Scott Cantor talked about your
version in the message
http://lists.oasis-open.org/archives/security-services/200109/msg00047.html.
The qualifier in AttributeDesignator is so that we can tell the difference
between different schemas. Within a single schema, it may still be necessary
to qualify the value.

That said, I think we have too many qualifiers already; I'd rather see us
advise people to use the issuer to qualify values where possible, rather
than pile up yet more elements.

> ...

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

I think the same analysis applies to actions; I'd much rather see us use
anyURI with no separate qualifier.

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

Yes, I noticed that the attributes were optional; if I hadn't been making my
Modest Proposal, I would have suggested that at least the AttributeName, if
not both, be mandatory.

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

No problem; it was probably laziness on my part that led me to oversimplify
the AttributeValue.

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

If there's a good reason to separate them, fine.

> 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

That's my Modest Proposal.

> 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 didn't really intend to propose those two changes; let's pretend I didn't
mention them.

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