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] Updated working drafts posted


Paul,

The proposed decision combining algorithms do not short circuit. I agree 
that short circuiting would be dangerous.

The current combining algorithms which are proposed do make sense for a 
PEP. There are two of them, suitable for a deny and permit biased PEPs 
respectively.

The first one is "all-must-be-permit"

1.    If at least one individual decision is an Indeterminate, then the 
combined decision is Indeterminate.
2.    If all individual decisions are Permit, then the combined decision 
is Permit.
3.    Otherwise the combined decision is Deny.

This algorithm reflects the policy writer's intent on a deny biased PEP, 
with the exception that in some cases access to one resource may be 
denied (through the PEP bias) because of an error on another resource. I 
don't think that is a major concern in most cases.

The "all-must-be-deny" is the converse of the former algorithm and is 
suitable for a permit biased PEP.

So I think we should keep this functionality. It will be a useful 
optimization compared to a full decision list and it does not violate 
the policy author's intent (except in case of an error, but that is safe 
in most cases).

I will add the text about obligations, fix the numbering of the steps in 
the second algorithm and post an updated working draft in a moment. We 
can discuss this issue on the call.

Best regards,
Erik



On 2009-12-16 18:41, Tyson, Paul H wrote:
>
>
>    
>> -----Original Message-----
>> From: bill parducci [mailto:bill@parducci.net]
>> Sent: Wednesday, December 16, 2009 09:59
>> To: Tyson, Paul H
>> Cc: Erik Rissanen; xacml
>> Subject: Re: [xacml] Updated working drafts posted
>>
>>
>> It seems counterintuitive that Obligations would effectively
>> be dropped as this would be in variance with what the Author
>> intended when writing the Policy. If we are going to punt on
>> Obligation combination (I agree that it is a monstrous
>> issue), then I suggest that Policies with Obligations not be
>> combinable based on the assumption that the only entity that
>> knows "if Obligations are important" is the Author (and I
>> believe that Obligations are normative as of v3).
>>
>>      
> Now that you mention "author's intent", it is apparent that the general
> decision-combining mechanism that we have proposed is a blatant
> violation.  It allows a PEP to obtain a unitary decision of its own
> choosing over a collection of arbitrary requests, regardless of the
> policy author's intent for each of those requests individually.
>
> We should eliminate the decision-combining-algorithm functionality.  A
> PEP may request a unitary decision, but it should be controlled by the
> specification as follows:
> 	"NotApplicable" if any decision in "NotApplicable"
> 	"Permit" only if all decisions are "Permit"
> 	"Deny" only if all decisions are "Deny"
> 	"Indeterminate" otherwise
>
> Unless the policy author and the PEP developer have agreed on some
> special behavior, it will not, in general, be safe to short-circuit the
> evaluation of multiple requests and return "Deny" on the first "Deny" or
> "Permit" on the first "Permit".  The specification should prevent the
> PDP from issuing any decision that is not explicitly foreseen and
> allowed by the policy author.
>
> Even so, we should still specify that a combined-decision should be
> "Indeterminate" when any decision has Obligation or Advice attached.
> Obligations and Advice differ only in their normative effect on the PEP.
> The policy author expects them both to be attached to the decision
> issued by the PDP.  If the PDP can't do this for a combined decision, it
> should return "Indeterminate" because the author's intent cannot be
> fulfilled.
>
> --Paul
>    



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