OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [saml-dev] Re: [security-services] Why use name-value pairs formodeling attributes?

(Note that the first example below should look more like this:


The <AttributeDesignator> element is for use in queries where the value 
is unknown and therefore the <AttributeValue> element is not supplied; 
the <Attribute> element extends the designator type by adding the value 

Also, this suggested format would not be well-formed XML:


This is because tags can't contain the funky characters allowed in URIs.)

We went back and forth on different ways to represent this information. 
  Our goals were to allow for appropriate flexibility in providing 
attribute information, while allowing interoperability and 
standardization at the same time.  The invention of the "attribute 
namespace" notion seemed to give us that, and the elements we provided 
give several hooks for extension.

There are a number of other ways we could have done it; one would be (a 
well-formed version of) the one apparently suggested by Joseph:


I don't know if we really considered this option seriously.  I think we 
wanted the basic framework to be in native SAML elements, on the 
principle of maximum understandability of the instance.  (Note that it's 
possible to achieve something like this effect using SAML 1.0, using 
substitution groups.  The <finance:CreditRating> element could be 
declared as a substitution for the <saml:Attribute> head element, and 
would have to be a specialization of AttributeType.  This means it would 
still have to have AttributeName and AttributeNamespace attributes, but 
it could fix values for these so they wouldn't have to appear in the 

Another design choice we might have made involves the use of the dreaded 
"QName in content" idiom.  We tried to avoid this in our early design 
work, which is why we didn't in fact use it for attributes and actions, 
but we couldn't avoid it when it came to xsi:type specialization and 
SOAP-style statuses:


We should probably consider what our true stance is on "QNames in 
content", since currently we're inconsistent and this doesn't offer a 
lot of guidance as to future design.

			*		*		*

By the way, the minutes from F2F #3 are here:


There are some notes in there that are indeed relevant to the topic of 
designing the attribute markup and how to query attributes, although the 
querying discussion was at a pretty high level.


Mishra, Prateek wrote:
> Sometime ago (Aug 26), Joseph Reagle had asked me the question (the text 
> is mine):
> ----- Why do SAML attribute statements include an AttributeType which 
> models the           
> ---- relationship between an namespace-qualified attribute name and XML 
> value as a triple?
> ---- Why not express this information as an XML fragment? The latter is 
> the more standard ------ treatment anyway.
> In other words, instead of:
> <Attribute>
>   <AttributeDesignator 
> AttributeNamespace="http://www.finance.org/V1"; AttributeName="CreditRating"/>
>   <AttributeValue>Good</AttributeValue>
> </Attribute>
> use:
> http://www.finance.org/V1:CreditRatingGood</CreditRating>  
> I recall considerable discussion around this topic around F2F#3 (BTW, 
> are the minutes still available someplace in the Oasis web site?). My 
> recollection is that we chose this treatment primarily to unify the 
> syntax of attributes and attribute queries. This was based on a 
> consensus to avoid use of a general XML query language.
> The corresponding attribute query has the form:
> <AttributeQuery>
>    <AttributeDesignator 
> AttributeNamespace="http://www.finance.org/V1"; AttributeName="Credit"/>
> </AttributeQuery>
> which has fairly obvious syntax and semantics.
> Maybe other SAML-ers other aspects of this discussion. Retrieving the 
> minutes would also be helpful.
> - prateek mishra

Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC