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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: Re: [xacml] Admin & Delg Profile new issues - 3

Hi Hal,

On 22/08/2014 5:01 AM, Hal Lockhart wrote:
Delegating Access Policies only

In section 5, just after Listing 1, the discussion suggests that the only way one can create an Admin policy that only permits the delegate to create Access policies and not Admin policies is the use of Maximum Delegation Depth. This can only work if the Issuer is aware of the number of levels of delegation which will occur prior to encountering the policy in question. (And that that number is constant.)

I don't think that is true. Section 4.11 says the path length is from
the initial node which is being reduced (which I take to be the access
policy) and the policy with the MaxDelegationDepth attribute. So an
administrative policy with MaxDelegationDepth="1" is saying that the
policies it authorizes have to be access policies. The number of levels
of delegation leading to this administrative policy don't matter (except
to those administrative policies in the chain and their settings for

> Further, under the current reduction algorithm, the limitations on enforcement described in section 8.2 also may prevent this approach from working as desired.

I believe it is desirable to be able to create an Admin policy which delegates Access policies only. I can also imagine wanting to allow Admin policies only, but I can't think of a usecase off hand.I would not ordinarily propose such a functional change at this late date, but since the reduction algorithm is under reconsideration, I would like to see this capability added if it can be done easily given whatever is decided about the reduction algorithm.

A MinDelegationDepth attribute could be defined to exclude access policies
at the next level, but I don't think it actually achieves anything. We can't
control who a delegate further delegates to. If we insist that the next level
does not contain access policies then the delegate can get around that by
creating an administrative policy that authorizes an access policy issued by
that delegate (i.e., delegating to themselves).



To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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