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

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

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

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

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.
cmclaren@netegrity.com   chris.mclaren@ieee.org

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

Powered by eList eXpress LLC