[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] clarifications/questions for worklist items 26, 29 and32
On Wed, 15 Oct 2003, Frank Siebenlist wrote: > TC members, > > I looked through the review and added some comments and clarifications. > > [ 26 discussion snipped ] > > ... > > 29. Policy Authority Delegation > > > > We had a number of questions about this. It needs > > clarification. Issues: > > > > a. Define "domain". What does it correspond to? > > b. Could this be solved using a subject-domain or > > resource-domain attribute that the PEP should include in its > > Request, and that policies could match on? > > > > Wait for Frank to provide clarification before putting on F2F > > agenda. > > > > F2F: not until/unless Frank clarifies, but then possibly > > I have the feeling that all the "delegation" related items will be solved when > we tackle the "right of a subject to administer policy for a certain target". > > I reworded the description in item#29: > > 29. Policy Authority Delegation > The ability to express in a policy rule that a certain authorization > authority is allowed to administer access control policy for a certain target. Isn't this just straightforward application of XACML policy to a "administer access control policy" action for a certain target? Sorry Frank, but I'm having a hard time parsing the following description. > The evaluation for a certain target should probably yield "Indeterminate" or > "Not Applicable" (?) according to the local policy, Why *should* it yeild Indeterminate or Not Applicable? > it should yield "Permit" for the right of an authorization authority to > administer the policy for that target, and either the authorization > query to that authorization authority's PDP should yield "Permit" or the > evaluation of the pushed access control assertion by that authorization > authority should yield "Permit". If the local policy yield either > "Permit" or "Deny", the foreign authorization authority doesn't have to > be considered.(?) Okay now I am afraid, I'm lost. Do you have a specific use case for this one that we can see what your requirements are? Cheers, -Polar
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]