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: 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?


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