Multiple Decision Requests During Reduction

[Steven Legg <steven.legg@enitiatives.com.au>]

With regard to Committee Specification 1 of the XACML v3.0 Administration and
Delegation Profile Version 1.0, a consequence of the algorithm in Section 4.5
for generating an administrative request is the possibility of the
administrative request containing two <Attributes> elements with the same
category, where that duplicated category has the prefix
"urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:".

This can only occur if the original access request contained an <Attributes>
element with a category that was the same as the category of another
<Attributes> element in the same request except for the prefixing of
"urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:".
For example, <Attributes> elements for both
"urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" and
"urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:urn:oasis:names:tc:xacml:1.0:subject-category:access-subject".
The algorithm in Section 4.5 would produce two <Attributes> elements with the
latter identifier. According to the Multiple Decision Profile this would be a
request for multiple decisions, though the original request is not.

I don't see anything in the Administration and Delegation Profile to suggest
that multiple decisions is intentional, nor how to deal with this situation if
it arises, nor how to prevent it from arising.

If multiple decisions during reduction is considered desirable, then it needs
a detailed, complete specification in the profile. Assuming multiple decisions
are to be prevented, which is my preference, then there are several possible
solutions of decreasing restrictiveness:

(1) Disallow categories with the delegated prefix (i.e.,
"urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:") in access
requests. However, being able to present an administrative request
to a PDP as the original request is useful for testing purposes.

(2) Disallow requests where some of the categories have the delegated prefix
and some don't, ignoring the delegate and delegation-info categories. This
allows "normal" access requests or "normal" administrative requests to be
presented to the PDP, but not mixed requests where some categories have the
prefix and some don't. I can't think of a use case for mixed requests, but I
can't be sure there never will be a good use case for that.

(3) Disallow requests that have any two categories where one is identical to
the other after the addition of the delegated prefix. This allows mixed requests
except for the ones that would result in multiple decisions during reduction.

(4) When checking if an original request is a request for multiple decisions,
treat a category that has the delegated prefix as equivalent to the category
without the delegated prefix. Thus any pair of categories where one is the
delegated prefix of the other will end up in separate individual decision
requests, neither of which will result in multiple decisions during reduction.
This solution has the advantage that no combination of categories is
disallowed, and it is easy to implement by augmenting the test for category
equivalence when checking for multiple decisions in the original request.

Regards,
Steven