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

[Scott Cantor <cantor.2@osu.edu>]

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

I'm in favor of #1, because after working through various examples and
syntax experiments within our project, I've become convinced that
identifying attributes with URI (most likely URN) strings is going to be
the least confusing to deal with. If we have to populate two potential
SAML attributes, we'll have to arbitrarily decide without any real
justification how or whether to separate the URI. So I guess this would
get us off the hook. ;-)

As for #3, while it sounds nice in theory, there are problems in
practice when combined with trying to define schema for simple attribute
value types (basically what Eve noted). If you start with a content
model of a single attribute (Name) and a sequence of any elements,
that's complex content.

According to my testing and review of some recent xml-schema-dev
postings, it's legal to derive a new type and restrict the complex
content to simple content, such as xsd:string. Unfortunately, there are
lots of current parsers that break when you do that. Even if it did
work, you end up having to define a new type no matter what, because
setting xsi:type="xsd:string" would never allow the Name attribute in
the Attribute element.

As far as Shibboleth is concerned, we're going to end up with custom
schema types for most attributes anyway, but for those wanting to use
built-in types alone for attribute values, this would make it
impossible.

-- Scott