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 MaxDelegationDepth). > 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). Regards, Steven Hal --------------------------------------------------------------------- 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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php