[Re: [xacml] obligations & error conditions] - PROPOSAL

[Bill Parducci <bill.parducci@overxeer.com>]

ok, here is the proposal for the changes to the spec that modify PEP 
behavior to treat incomprehensible obligations as ERROR conditions (vs. 
"Deny"). the discussion for this proposal is encapsulated in the 
discussion thread.

line numbering refers to the 0.8 version of the spec and the text 
provided is meant to replace the corresponding paragraphs in the current 
spec.


line 570:
Therefore, bilateral agreement between a PAP and the PEP that will 
enforce its policies is required for correct interpretation. The PDP 
returns <Obligations> elements for the PEP to discharge. While the 
contents of <Obligations> tags are opaque to the PDP, PEPs MUST 
understand, and be capable of discharging, all obligations associated 
with a given decision if provided; failure to do so MUST act as if the 
PDP returned an ERROR.

line 1538:
[a478]-[a499] The <Obligations> element.  One or more obligations MAY be
associated with a "Permit" or "Deny" authorization decision. The
<Obligations> element contains set of obligations, which are operations
that MUST be discharged by the PEP in conjunction with the associated
authorization decision.

line 1715:
The <Obligations> element contains a set of obligations that MUST be
discharged by the PEP in conjunction with the authorization decision.  If
the PEP does not understand, or cannot disharge, any of the obligations,
then it MUST act as if the PDP returned an ERROR for the authorization
decision value.

line 2977:
The <Result> element represents an authorization decision result for the
resource specified by the ResourceId attribute.  It MAY include a set of
obligations that MUST be discharged by the PEP.  If the PEP does not
understand or cannot discharge an obligation, then it MUST act as if the
PDP returned an ERROR for the authorization decision value.

line 3006:
A list of obligations that MUST be discharged by the PEP.  If the PEP
does not understand or cannot discharge an obligation, then it MUST act as
if the PDP returned an ERROR for the authorization decision value..  See
Section 7.15 for a description of how the set of obligations to be
returned by the PDP is determined.

line 3130:
A PEP SHALL allow access to the resource only if a valid XACML response
of "Permit" is returned by the PDP.  The PEP SHALL deny access to the
resource in all other cases.  An XACML response of "Permit" SHALL be
considered valid only if the PEP understands and can and will discharge
all of the obligations contained in the response.  An XACML response of
"Deny" may also be accompanied by obligations.  In this case, if the PEP
understands the and can discharge the obligations it MUST deny access and
make best efforts to discharge the obligations; otherwise the PEP MUST
treat the decision by the PDP as an ERROR.

 > What if the PDP returns an Indeterminate or NotApplicable?

see below (want to get all the text changes in first ;o)

line 3478:
A PEP that receives a valid XACML response of "Permit" with obligations
SHALL be responsible for discharging all of those obligations.  A PEP
that receives an XACML response of "Deny" with obligations SHALL be
responsible for discharging all of the obligations that it understands
and is capable of discharging. If the PEP cannot understand the
obligations provided by the PDP it must treat the decision by the PDP as
an ERROR.

below:
per the second sentence those will result in a "Deny" as well. this is 
not an 'obligation' issue but rather is what i believe has been the de 
facto solution to the 'default policy' issue that has swirled around 
since the first XACML meeting. what i believe is implied here is that 
while a decision of "Permit" is required for access, this may come about 
implementationally as a result of multiple attempts by the PEP to 
contact a variety of PDPs (PAPs? i always find that line confusing ;o) 
in response to some internal logic.

so, if you were to build a PEP that had the logic of:

ask PDP1 for access control decisions for the door, but ask PDP2 (the 
lenient PDP) for decisions in the event PDP1 said no and it is really 
cold outside

or

rephrase access control decisions to include 'it is really cold' when 
the temperature is below 50 (which invokes a kinder, gentler policy)

or even

ask PDP2 for an access control decisions if PDP1 returns that obligation 
gibberish

and either solution  *ultimately* yielded a "Permit" you are still in 
compliance of the spec even though you received a "Deny", 
"Indeterminate" or "Error" as part of the process.

what can't happen--and what it is i think we are trying to say here--is 
that unless *something* tells you to "Permit" and you *fully* understand 
  that message then you *cannot* allow access. this is not a 'skew to 
deny' in the policy evaluation, but rather the default behavior of any 
system that is conformant, and is done to ensure that there is some 
level of determinism at the point of *application* of a decision.

we need to have this for the simple reason that we must have some sort 
of baseline vocabulary from which to work. in this case "Permit" = grant 
access and *any* other result is a flavor of != grant access (a 
'normally open' relay on the old circuit board ;o)

b