Re: [xacml-comment] What is "URI equality" ?

[Erik Rissanen <erik@axiomatics.com>]

Hi Steven, Rich,

I remember that we discussed uri equality for the anyURI-equals 
function. If I recall correctly, in XACML 2.0 it referenced a draft 
specification of XPath 2.0, which defined a uri equals function. For 
XACML 3.0 we updated all XPath 2.0 references to the final W3C 
recommendation. However, the final recommendation had dropped the uri 
equality function. So what we did was to look back at the XPath draft 
and we copied in the definition from there into the XACML 3.0 spec. 
Hence the anyURI-equals function says "if the values of the two 
arguments are equal on a codepoint-by-codepoint basis".

We did not notice though that there are other cases where URIs are 
compared, not just the equals function. We should have updated the other 
similarly. The very least, good implementation advice would be to use 
the same definition as for the anyURI-equals function for the other URI 
equality tests.

Best regards,
Erik

On 2011-10-27 08:32, Steven Legg wrote:
> Hi Rich,
>
> Thanks for the prompt reply.
>
> RFC 3986 doesn't so much define URI equality as leave it to
> applications to decide how thoroughly they want to compare URIs.
> Since XACML is mute on the issue that effectively makes URI
> equality in XACML implementation defined. Perhaps that should
> be acknowledged in the spec ? Or at least a mention that it's
> not the same thing as anyURI-equal.
>
> Regards,
> Steven
>
> On 27/10/2011 3:06 AM, rich levinson wrote:
> > Hi Steven,
> >
> > "URI equality" is defined in the URI specification RFC 3986:
> > "Uniform Resource Identifier (URI): Generic Syntax"
> > http://tools.ietf.org/html/rfc3986
> > which in section 6, goes into detail as to what is involved:
> > http://tools.ietf.org/html/rfc3986#section-6
> >
> > The bottom line is that there is no accepted unambiguous way
> > to determine absolutely that 2 URIs are "equal", and the
> > objective has been reduced to:
> >
> >     "Therefore, comparison methods are designed to
> >     minimize false negatives
> >     while strictly avoiding false positives. "
> >     http://tools.ietf.org/html/rfc3986#section-6.1
> >
> > In other words (I interpret this to mean),
> >
> >   * a determination of "equivalent" should, in general,
> >     be considered to be "accepted as absolutely true",
> >   * while a determination of "non-equivalent" should,
> >     in general, be considered to be accepted as "true",
> >     but, with the qualification that further investigation
> >     may under some circumstances find that the result
> >     may be "equivalent" when those additional
> >     circumstances are included in the evaluation.
> >
> > Note that the core spec refers to the August 1998 version:
> > "Uniform Resource Identifiers (URI): Generic Syntax"
> > http://tools.ietf.org/html/rfc2396
> > which elaborates less on this issue but does say in section 6:
> >
> >     "In general, the rules for equivalence
> >     and definition of a normal form, if any,
> >     are scheme dependent."
> >
> > -> XACML 3.0 core spec should be updated to refer to RFC3986,
> > which has "obsoleted" RFC2396.
> >
> > Thanks,
> > Rich
> >
> >
> > On 10/25/2011 7:36 PM, Steven Legg wrote:
> > > Sections 5.29 and 7.3.4 of the Committee Specification 1 XACMLv3 core
> > > specification define the matching of Category, AttributeId and DataType
> > > XML attributes according to "URI equality". I've always assumed that
> > > URI equality was the same as the matching performed by the
> > > urn:oasis:names:tc:xacml:1.0:function:anyURI-equal function, but I 
> > > can't
> > > find anything in the specification to justify that assumption since
> > > "URI equality" is not defined anywhere. It would help if the 
> > > specification
> > > clarified what "URI equality" actually means.
> > >
> > > Similarly, there is also a reference to undefined "string equality"
> > > matching in section 5.24.
> > >
> > > Regards,
> > > Steven