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] Re: Call for Obligations


> Anil Saldhana wrote:
>
>> I understand that obligation means obligation. :)
>> Anil Saldhana wrote:
>>> My use cases in mind are the following(please correct me wherever  
>>> my understanding is wrong):
>>> a) Legitimate authorization request arrives at the PEP. PEP  
>>> invokes the PDP. PDP comes back with 'PERMIT' and a set of  
>>> obligations. PEP is unable to fulfill 1 or more obligations. PEP  
>>> issues an error. What happened to the legitimate request?
>>> b) PDP issues a 'PERMIT' with a logging obligation. PEP does not  
>>> want to log because performance considerations have been put  
>>> forward and logging is low priority for the PEP. PEP issues an  
>>> error.
>>>
>>> These are the use cases that I feel that obligations can have an  
>>> optional tag such that PEP can be spec compliant in ignoring them.

On Apr 4, 2007, at 8:06 AM, Anne Anderson wrote:
> The semantics of a particular Obligation are completely between the  
> Policy Administration Point and the PEP.  The PAP could define a  
> particular Obligation "TryToLog" as meaning: "Make a best effort to  
> log, but it is not an error if unable to do so".
>
> Anne
>

Exactly. Although this does introduce an interesting possibility for  
an Obligation Category attribute. My first thought is to address this  
using the "timing" behavior we talked about briefly on the call. For  
example, there could be three flavors: (1) synchronous--as part of  
the access mechanism itself; (2) asynchronous--affected at some later  
time, if not implemented an Error is thrown; (3) superfluous--a "best  
effort" action, no Error is thrown if not carried out (and timing  
would always be async).

OK, we can work on the naming :) but I think the concept is  
interesting...

b




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