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

Yes, I see you are right. I misread the text. I have always thought of depth as a loop prevention control.

I don't see admin-only as being that useful. I will close the issue.


> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@viewds.com]
> Sent: Thursday, August 21, 2014 8:14 PM
> To: Hal Lockhart; xacml@lists.oasis-open.org
> 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 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
> >

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