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