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

[Hal Lockhart <hal.lockhart@oracle.com>]

Actually I never put this issue in the wiki, so I won't now.

Hal

> -----Original Message-----
> From: Hal Lockhart
> Sent: Tuesday, September 02, 2014 3:13 PM
> To: Steven Legg; xacml@lists.oasis-open.org
> 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.
> 
> Hal
> 
> 
> > -----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
> > >
> >
> 
> ---------------------------------------------------------------------
> 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
>