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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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

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

Hi Steven,

See inline.

On 2011-10-28 07:52, Steven Legg wrote:

Hi Rich,

On 28/10/2011 1:43 AM, rich levinson wrote:
Hi Erik,

I tried to explain the situation in my first email response to Steven.

This is a high level view of my reading of the spec, section 6:

To go into further detail would require detailed analysis of
that section, which might be useful, but probably not before
there was at least agreement on the high level concepts.

The fact is that it is not true that: "Two URIs are either
equal or inequal, given a comparison function".

This is only true for a concrete comparison function. What
the spec says is that there is basically an iterative process of
finer detailed comparisons that narrows the uncertainty gap
at greater expense of processing resources. And that it is
a lot easier to narrow the gap on the equality side than on
the non-equality side, as a practical matter.

Which side doesn't matter given the "deny" effect and the "not" function.
Both of these turn a false negative into a false positive (and vice versa).
Any inaccuracy is potentially a bad thing, but closing the gap involves
increasing cost in both implementation and execution. So the question
is how much is good enough ?

I agree with Erik that codepoint-by-codepoint comparison (which is
RFC 3986's simplest and least accurate option) works fine for things
like Category, AttributeId, DataType, FunctionId and so on because
their values are generally provided by a piece of code somewhere and
it is easy for implementors to get them right. I think the more serious
source of potential problems is with XACML attribute values of the
anyURI data-type because these values are much more likely to have
been entered by a human, either in a PAP interface or indirectly via
an authorization request sent by a PEP, and so more likely to be

It seems wrong-headed to me to demand a higher quality in the comparison
of URIs in XML attributes (e.g., AttributeId) than for the comparison
of anyURI values in XACML attribute values. They should be the same
quality, whatever that is determined to be.

No, I think it is fine to demand different qualities of these functions since they solve two different problems.

1. How do we identify XACML language items, such as functions, attributes, categories, obligations, and so on.

2. How to work with attribute value data which contains URIs, which are used by other system components doing different forms of comparisons than simple codepoint-by-codepoint?

The solution to the second problem is going to be much more complex than the for the first one. Just look at the history of different URL based attacks on web servers. We should not carry over the complexity of the second problem into the solution of the first problem.

If codepoint-by-codepoint comparison has been found to be good enough
for values of the anyURI data-type, then it ought to be good enough
for URI identifiers. That doesn't mean normalization is ignored. It
means it is a responsibility of PAPs and PEPs rather than PDPs.

I think the actual situation is that the XACML TC has not given thought yet to a comprehensive URI feature set for solving the second problem from above, rather than that we have decided that codepoint-by-codepoint is going to be good enough for everybody in all cases.

But I do agree with you that in practice it's probably better to do canonicalization of these types of URIs outside of the XACML policy, and instead in the PAP, PEP and PIPs.

Best regards,



On 10/27/2011 9:46 AM, Erik Rissanen wrote:
Hi Rich,

Two URIs are either equal or inequal, given a comparison function, so I don't understand what you mean by
one of them being ambiguous and the other unambiguous.

I did not read up on this RFC, but I would guess the issue there is that since the URI schemes are
extensible, unknown URI schemes are opaque to a comparison function.

The codepoint-by-codepoint comparison works simply for the normal URN and HTTP schemes, provided the strings are normalized (already required by the spec) and you don't use certain characters like white spaces in your identifiers. Since identifiers are chosen by the TC or implementors, it should be possible
to easily avoid any practical problems.

Best regards,

On 2011-10-27 14:53, rich levinson wrote:
Hi Steven and Erik,

I think the 3986 spec is not quite as bleak as Steven's last email.
Basically, what I believe it says is that you can determine "equality"
unambiguously. However, the same cannot be said for "inequality".
i.e. if your Policy depends on 2 URI's being equal, then you should
be OK. However, there may be cases where they are found to be
"unequal", but, in fact, could later be proved to be equal.

Also, I recommend fixing the 3.0 core spec to refer to 3986 in the
3 places 2396 is ref'd, which is in the list of refs, plus 2 other
places that you can find searching for "2396".

Also, we should make explicit the meaning of "equal" and "unequal"
in the spec by basically repeating the salient points from 3986
(as usual, all above is "imo").


On 10/27/2011 5:13 AM, Erik Rissanen wrote:
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,

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.


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"
which in section 6, goes into detail as to what is involved:

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. "

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"
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.


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.


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