Shibboleth Developers

["Scott Cantor" <>]

Hi,

I think this recent SAML posting from Chris McLaren is a useful
description of how SAML views attributes and their values, and might
help ground our work a bit.

What we need to do is define the attributes we need (their name and
namespace) and then decide what the value syntax needs to be. If the
values can be expressed with simple schema types, the xsi:type mechanism
could be used to specify to the SHAR's validator what the attribute
value looks like. If not, we will define an extension schema and pull
that in during validation.

The job of the attribute plugins at the AA is to provide my code with
the XML content that goes *inside* the AttributeValue element. That
content is essentially a set of child DOM nodes (which can themselves
have children, but that's opaque to me).

For example, if a simple string is needed, then the plugin returns a
DocumentFragment node containing a single text node containing the
string value. If an element we define containing a string and an XML
attribute is needed, then the plugin returns a DocumentFragment node
containing an element node. The element node would then contain a text
node and an attribute node, but to my code, it's just the direct
children of the DocumentFragment that I have to look at.

What I do is just insert the DocumentFragment into my DOM tree beneath
an AttributeValue element, so I can generate the assertion. The
semantics of the fragment type in DOM are that inserting a fragment into
a tree is like inserting all of its children as siblings, beneath the
insertion point. So any number of children could be used to represent
the attribute's value.

-- Scott

-----Original Message-----
From: Chris McLaren 
[mailto:]
 On Behalf Of Chris
McLaren
Sent: Tuesday, December 04, 2001 2:11 PM
To: 'oasis sstc'
Subject: [security-services] A15 & A23: Attribute Values


A number of suggestions have been made and questions raised with regards
to the use of the <saml:Attribute> element, specifically around how to
communicate the "type" of the contents of the <AttributeValue> element.
I'm going to attempt to answer what I think some of those questions are.

1. How is someone supposed to know what to do with the <AttributeValue>

First, simple, answer: Every <Attribute> has an "AttributeNamespace"
attribute that functions as a context identifier for what's in the
element's <AttributeValue>. This "AttributeNamespace" could identify a
publiclly-available DTD or schema, or could refer to something more
proprietary. Essentially this can be used as the key that tells a SAML
consumer how to interpret the <AttributeValue>. Note that there is no
requirement that the combination of the AttributeName and
AttributeNamespace attributes uniquely identify a type for the data
contained in the value--they MAY, but they are not required to.

For a more generic form of this solution it is noted that there are some
XML specifications that allow generic serialization of objects into XML,
and the AttributeNamespace can be used to identify these specifications.

Second, better, answer: The <AttributeValue> element can have an
"xsi:type" attribute added to it that indentifes the type of the
contents. <AttributeValue> contains an "any" element, which in the
schema definition is assigned the type "xsd:anyType". Since
"xsd:anyType" is the ur-type from which everything in schema is derived,
any other schema type counts as a descendant type, and can thus be used
in xsi:type substitution.

In other words, it is perfectly valid to have an Attribute that looks
like
this:

<Attribute AttributeName="my_name" AttributeNamespace="some_namespace">
        <AttributeValue xsi:type="prefix:SomeType">
                ... contents as defined by the prefix:SomeType
definition in the prefix schema
        </AttributeValue>
</Attribute>

This amounts to using definitions from another schema to define the
contents of your values.

2. What if all my values are just simple types like strings and
integers? Why should I have to pull in another schema for
<AttributeValue> for these simple cases?

You don't have to. You already have "pulled in" the definitions from
schema itself (and probably schema-instance also). You can use these
exactly as in the second answer above. You just use type substitution to
specify what type your value is, and point to the simple types defined
in schema itself. For
example:

<Attribute AttributeName="Department"
AttributeNamespace="some_namespace">
        <AttributeValue xsi:type="xsd:string">
                Engineering
        </AttributeValue>
</Attribute>

3. Why isn't this stuff in the core document?

Does it really belong there? Perhaps a line of the form "If your
attribute values are simple types defined in XML Schema you SHOULD add
xsi:type attributes to the <AttributeValue> element identifying their
type." with an example could be added to the <AttributeValue> section,
with a link to a more complete discussion in non-normative text
somewhere?

--
Chris McLaren, Principal Engineer
B2B Research Group  Netegrity, Inc.

   


------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--