OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]