Subject: Issue: Ambiguity in defn of Request wrt Attributes Category
The "issue" here is that it does not appear to me that it specifies
anywhere that a single PDP authorization decision is based on
a set of <Attributes> element each with a different Category and
that there can be at most one <Attributes> element of a specific
Category involved in a single decision.
I have been working under the assumption that this is true for
quite a while now, but recently I have tried to find the supporting
documentation to unambiguously validate that claim, and I have
been unable to do so, leaving me with the conclusion that either
the claim is wrong and that more than one <Attributes> element
of the same Category can be involved in a single decision (which
I believe to be false), or that the documentation should be improved
somewhere to emphasis this fundamental point.
The description in the 3.0 spec says:
"<Attributes> [One to Many]While the text above might lead one to believe that one might
want to consider only including one <Attributes> element
per Category, it says nothing definitive one way or the other.
I am well aware that the multi-decision profile uses multiple
<Attributes> elements of the same Category as the basis for
generating a cross-product to generate "Individual Decision
Requests", where in section 2.3.3 it states:
"For each combination of repeated <Attributes> elements,Again, this text is useful wrt providing the ContextHandler w the
info it needs to generate multiple decision requests, however,
it does not imply that this is a requirement from the PDP side.
For example, what would happen if someone submitted a
Request with two <Attributes> elements, each for a different
Target resource, but both with the same Category, namely:
"urn:oasis:names:tc:xacml:3.0:attribute-category:resource"?Would this be a request for which the user was asking for access
to both resources at the same time? Or would this be an error
if the multi-profile was not supported?
I don't believe questions like this can be answered w the info in
the specs as they currently exist. (unless, of course, I have missed
something, which is entirely possible :) )