[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] A15 & A23: Attribute Values
In my message (subject:"RE: [security-services] Validation of simple attribute value fails?" of December 19, 2001) I am reply to Scott's note that having AttributeValue defined in schema as a set of anys, rather than simply an any (which could be a set, naturally), causes simple types to fail validation. Here I note that the schema should be changed to replace the current definition of AttributeValue with one that is types as an any, not a sequence of anys. In a meesage of the same title, later in the day, Eve agrees. C. > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Wednesday, January 09, 2002 7:11 PM > To: Chris McLaren; 'oasis sstc' > 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> > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC