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