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] Notes from Focus Group 30 June 2005: Discussion of adminpolicy draft 6


Hal Lockhart wrote:

>>ISSUE: Should Administration Policies that grant
>>  permission to issue new Access Policies be distinguished from
>>  those that grant permission to issue new Administration
>>  Policies?  If same policy would never be used for both cases,
>>  it might make policies more understandable if they were given
>>  different names.
>>
>>  Use case for doing both in one policy: Erik may delegate
>>  permission to Hal to make updates to the spec during Erik's
>>  vacation, but Erik may also be happy if Hal further delegates
>>  this permission in case Hal is busy or traveling.
>>    
>>
>
>Eric,
>
>After giving this more thought I have a different concern.
>
>Based on our discussion, it will be possible to define an admin policy which controls the creation of both admin and access policies. As I understand the scheme you have in mind, it will be possible to create policies which are only direct - control the creation of access policies - by omitting the "further delegate" element.
>
>What I am now wondering is what about the third case? Will there be some way to create a policy which is indirect only (applies to admin policies)?
>
>Hal
>  
>

Hal,

Yes, this will be possible if required. You just write a condition that
requires the presence of a "LaterDelegate" element in the request.

/Erik




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