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


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