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: Re: [security-services] A15 & A23: Attribute Values

Good stuff!  Only a couple of questions:

- We have the opportunity to *require* that <AttributeValue> be supplied 
with an xsi:type.  Do we want to do that, so that attribute values are as 
processable as possible, or should it be enough if someone wants to get 
this information out of the attribute namespace?

- If we don't require xsi:type, then I think it would be nice to have a 
non-normative note explaining briefly how this could be done.  Doesn't have 
to be a SHOULD, to my mind, but doesn't have to throw people over to a 
whole other unnecessary document either.


At 03:11 PM 12/4/01 -0400, Chris McLaren wrote:
>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
>         </AttributeValue>
>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">
>                 Engineering
>         </AttributeValue>
>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
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>

Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com

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

Powered by eList eXpress LLC