Re: [xacml-comment] Multiple Decision Requests During Reduction

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

Hi Erik,

On 30/06/2011 11:20 PM, Erik Rissanen wrote:
> Steven,
>
> The delegated prefix is a reserved category, being in the oasis namespace, which is not something you are
> allowed to use for any other purpose than the delegation processing.

... or for composing policies in a PAP. So PDPs, PAPs and policies can
use it, and perhaps other components too, but apparently PEPs can't.

Calling the prefix "reserved" tells the reader almost nothing about how
it can and can't be used, and by itself is inadequate specification.
If PEPs aren't allowed to use the delegated prefix in access requests,
then the standard should say so.

 > And mixing non-delegated categories and
> delegated categories is not consistent with the definitions for how delegation works, so I would say it is
> already disallowed.

I would say it is not consistent with the expected use of delegation, but
that doesn't automatically make it disallowed. Apart from the issue of
duplicated categories, the outcome would be deterministic.

Regards,
Steven

>
> Best regards,
> Erik
>
>
> On 2011-06-29 19:27, Steven Legg wrote:
>>
>> 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
>>
>>
>
>