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] obligations & error conditions


Polar Humenn wrote:

> Now, after that. I still have this problem with the skew toward Deny
> being acceptable.

it is not that the obligations are skewed towards Deny, but that Errors are 
typically considered reason for not allowing access on most systems.

the text as rewritten (with your edits) simply states that a PEP must treat the 
decision response as an Error if any presented obligation is not understood or 
'dischargable'.

 > If obligations are not understandable by a PEP, then there is something
 > wrong with the "bi-lateral agreement". I think, whether the decision is
 > Permit or Deny, if there are any obligations that are not understandable
 > or not dischargable, it should be considered an error, and the PEP is free
 > to seek alternatives.

agreed: retries, alternate PDP requests, reframing of the question, etc. are all 
acceptable mechanisms for dealing with such a situation. however, i think it is 
fairly well understood that simply allowing access under such [error] conditions 
is counter to developing a deterministically *applied* system (regardless of how 
cold it is ;o)

> For example, Access to opening the freezer door from the inside. "Deny
> with obligation to ring security desk."
> 
> Mary is denied opening the door because her card doesn't work. It's -30
> degrees in the freezer. The phone at the security desk is busy, because
> Bob, the guard, is talking to his mom.
> 
> The PEP following the XACML 2.0 specification, Denies, and declaring a
> "best effort" in contacting the security desk gave up discharging its
> obligation with no consequence.

not really. two things happened:

(1) the PEP did whatever it is configured to do when it receives an error 
condition (log, beep, burp, blink, turn itself off... whatever is necessary to 
raise the awareness that something did not operate properly)

(2) the subject was not granted access to the resource for precisely the same 
reasons why *every* other XACML v2.0 compliant PEP (without the understanding 
and capabilities to discharge the obligations emanating from this PDP for this 
decision) would do the same.

b



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