Next in thread →
Next in month →
Re: [xacml-comment] What is "URI equality" ?
Hi Erik,
I agree that the spec should specify a least common denominator
comparison
function that works for all URIs, which I think the
codepoint-by-codepoint
soln ref'd in 3.0 probably does (I looked at the details in the XF
reference,
however, even there it seemed there was room for ambiguity, in the
sense
that "strength of the collation" must be specified:
http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#collations
).
I also agree that the "identifier" case is different from the
"resource being
identified", however I think that "AttributeId" falls more in the
resource
case than the "identifier" case. The reason is that enterprises and
other
organizations, will be defining AttributeIds as part of vocabulary
defns
for domain-specific attributes. These AttributeId's will not be able
to
be controlled in the manner of URI's that are part of the XACML std.
I also agree that ultimately what's needed is "a set of dedicated
URI
functions to be used in policies", but I think that is beyond the
scope
of the current 3.0 effort.
My suggestion is to fix the 3 refs to rfc2396 and have them updated
to
rfc3986, which we already did in the hier profile.
Also we might want to consider adding a phrase or sentence in A.3.1
under
string-equals and anyURI-equal that acknowledges this as a least
common
denominator soln, which some application domains may want to enhance
with "higher strength comparisons or preliminary normalizations"
that
reduce the false negatives, as described in rfc3986.
The reason I suggest both string and anyURI is that in section
A.3.13 the
anyURI-match, first converts the URI to a string then does the
string match.
All I am recommending is that we indicate that what we are doing is
intended
as a first level soln for URIs w some fairly well defined
characteristics, but that
we are aware that there are situations where extra work may be
needed to
bring the URIs into a manageable form.
Without dragging the spec into the details I think we can make the
point that,
as described in rfc3986, that
"comparison methods are designed"
to be:
"strictly avoiding false positives"
but, to only:
"minimize false negatives".
i.e. just some indicator that we know about the issue and refer
implementers
to the refs XF and 3986.
Thanks,
Rich
On 10/28/2011 4:43 AM, Erik Rissanen wrote:
Hi
Rich,
Yes that is what I meant when I said "give a comparison function".
;-) Anyway, I think we are in agreement. Thanks for the
clarification.
So the issue is that since XACML needs to define a concrete
comparison function which works for all URI (or limit the set of
allowed URIs), we need to pick something simple.
codepoint-by-codepoint is a workable solution.
Of course, this would not give the same results as other
comparison functions out there, which might be performing encoding
of white space characters, canonicalization of file system paths,
etc. But we have no need for such things since we only use the
URIs as identifiers.
Note that the identifier issue is different from the case where
the resource being protected is described by a URI. In that case
you probably need to do all that, canonicalization, etc, but that
is a different problem which needs to be solved with a set of
dedicated URI functions to be used in policies. Let's not mix in
these issues into the simple issue us needing unique identifiers
for items in the language.
Best regards,
Erik
On 2011-10-27 16:43, rich levinson wrote:
Hi Erik,
I tried to explain the situation in my first email response to
Steven.
http://lists.oasis-open.org/archives/xacml-comment/201110/msg00001.html
This is a high level view of my reading of the spec, section 6:
http://tools.ietf.org/html/rfc3986#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.
Thanks,
Rich
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,
Erik
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").
Thanks,
Rich
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,
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
Next in thread →
Next in month →