[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] A15 & A23: Attribute Values
OK found this. I am not completely clear as to the change to be made to the schema or to core however. I assume that this means that 1) no change to the spec is required 2) only change to core is the addition of a note to explain the useage I have added the following explanatory note in AttributeValue: If the data content of an AttributeValue element is of a XML Schema simple type (e.g. interger, string, etc) the data type MAY be declared explicitly by means of an xsi:type declaration in the <AttributeValue> element. If the attribute value contains structured data the necessary data elements may be defined in an extension schema introduced by means of the xmlns= mechanism. This is not completely clear, but the only way to make it clearer would be to introduce some examples, which hitherto we have not done in the core document. I suggest we revisit this in the committee last call. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Chris McLaren [mailto:chris.mclaren@ieee.org] > 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. > 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> >
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC