[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]