[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]