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

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

I suggest we revisit this in the committee last call.


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
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