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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: type for SubjectCategory


I believe it was not the intention of the XACML TC to change the
type of SubjectCategory from xs:string to xs:anyURI, and that
this change was made by mistake.

I propose that this change be considered an erratum against XACML
1.0, and that the schema be changed back to make the type for
SubjectCategory be xs:string for XACML 1.1.

Anne Anderson

On 24 June, Satoshi Hada writes: Re: [xacml] Minutes for XACML TC Focus Group 19 June 2003
 > From: Satoshi Hada <SATOSHIH@jp.ibm.com>
 > To: Seth Proctor <Seth.Proctor@sun.com>
 > Subject: Re: [xacml] Minutes for XACML TC Focus Group 19 June 2003
 > Date: Tue, 24 Jun 2003 13:04:04 +0900
 > 
 > >> Why do we want to use string-equality to compare two URIs? If
 > >> we're just supposed to do string-equality, then why not define the two
 > >> parameters as strings to stay consistent?
 > 
 > I have the same concern.
 > 
 > Satoshi Hada
 > IBM Tokyo Research Laboratory 
 > mailto:satoshih@jp.ibm.com
 > 
 > 
 > 
 > 
 > Seth Proctor <Seth.Proctor@Sun.COM>
 > 2003/06/23 23:26
 >  
 >         To:     Satoshi Hada/Japan/IBM@IBMJP
 >         cc:     Anne.Anderson@Sun.COM, XACML TC 
 > <xacml@lists.oasis-open.org>
 >         Subject:        Re: [xacml] Minutes for XACML TC Focus Group 19 
 > June 2003
 > 
 >  
 > 
 > Satoshi - I haven't been following the conversation around this erata
 > element closely, so thanks for bringing up these issues...
 > 
 > 
 > > >> string-equality or uri equality for the subject category
 > > >> Proposal: not an errata, leave as is:
 > > >> string-equality. URI-equality implies URL-equality and this could
 > > >> get very complicated because URL can be url-encoded. Besides,
 > > >> this does not cover URN what subject attribute really is.
 > 
 > I'm very confused by this decision. As I recall, the category used to be
 > a String, but got changed to a URI. I suspect the real problem is that
 > the text in SubjectAttributeDesignator just didn't get updated at the
 > same time. Why do we want to use string-equality to compare two URIs? If
 > we're just supposed to do string-equality, then why not define the two
 > parameters as strings to stay consistent?
 > 
 > > It seems to me that
 > > SUN's implementation uses URI-equality
 > > rather than string-equality for subject-category comparison:
 > 
 > Good catch. You're probably right that given the current language in the
 > spec, the two URIs should be turned into strings and then equality
 > should be done that way. Most of the time the current mechanism will
 > behave the same way, but there are some corner cases in there. When I
 > changed from strings to URIs I probably assumed that the equality check
 > had changed as well. I'll make that fix as soon as this issue gets
 > sorted out. Thanks.
 > 
 > > Maybe, the specification document should define the precise meaning of
 > > "string-equality".
 > 
 > Probably useful, although I think it's supposed to refer to the
 > string-equal operation, which seems pretty clear.
 > 
 > > >> RECOMMENDATION: accept proposal; continue to use string-equality.
 > > >> The type of the XML SubjectCategory attribute is "xs:string".
 > > 
 > > Does this mean the XACML schema will be changed so that
 > > the type of the "SubjectCategory" attribute is xs:string (not xs:anyURI) 
 > ?
 > 
 > That's what I'm wondering too. What's the value in defining two parameters
 > as URIs but then using string-equality to compare them? Does the spec 
 > define
 > how to convert from an anyURI to a string? Does this break the type system
 > in the spec? Where is the value here?
 > 
 > 
 > seth
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692



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