Re: [xacml] Discussion summary and revised post-condition proposal

[bill parducci <bill@parducci.net>]

> I have some questions on the post conditions w.r.t compose the policies,
> especially with the GRANT/DENY semantics that MUST be performed by the PEP
> in the "provided that" clause, which Michiharu-san lays out below.
> 
> What should the PDP result be if the PDP cannot determine that the PEP can
> fulfill the "provisions" on a policy? Say a policy evaluates to "Permit
> provided that p1,...,pn" which, according to the semantics in the summary
> below a PEP that could not fulfill any of p1,...,pn would change this
> result to "Deny". This "change" is performed by the PEP. However, what if
> we have two policies, each with provisions that are composed by the PDP.
> 
> If policy A is composed with another policy B, the PDP must know exactly
> what the PEP can enforce, because according to the operational semantics
> outlined below, the PEP can "change" the policy A evaluation from "Permit"
> to "Deny", which may effect the out come of the composition of Policy A and
> B, say if the combinator were to mean "all policies MUST Permit".


the term 'MUST' should no longer be in the definition. the solution that 
we have come up with is that the PDP is unconcerned with the PEPs 
ability to perform obilgations/provisions/post-conditions (we need to 
decide on what to call these buggers!) therefore, the PDP consults 
obligations after reaching a resolution on the request, and only then to 
provide the obligations upon with the decision is provided.

i think that this slipped by:

/*
One of the problems with the term 'post-condition' is that it 
technically refers to the *state* of something after an event, not 
something that must be done.
*/

i believe that the appropriate phrase is: 'something that IS EXPECTED TO 
be done.'


> Also another question:
> 
> It seems that the "provisions" are stated on "onTrue" "onFalse", lets say
> in our current proposal from Simon that we are really talking about
> "onPermit"  or "onDeny".
> 
> This means that a policy either evaluates to
> 
> 1. Permit provided that p1,...pn
> 2. Deny provided that q1,...,qm
> 
> Let us say we have a policy with BOTH "onPermit" and "onDeny" provisions.
> 
> If #1 is the case, and the PEP cannot fulfill one of p1,...,pn, then does
> the PEP need to fulfill q1,...,qm?


following from above, this reads:

1. Permit with obligation p1,...pn

2. Deny with obligation q1,...qn


> What does "Deny with ERROR that may need to be handled by the PEP or ERROR

> output to the PEP administration" really mean?


this situation arises when you have 'DENY with obligation' and the 
obligation cannot be met (you obviously can't allow :o) this is handled 
by any 'unfulfillable obligation' generating an ERROR on the PEP (which 
results in an effective DENY, but with the notation of incomplete 
process). that is my understanding.

example:

PEP: request for access to X by Y
PDP: deny, if existing session  for Y
(yeah, i know, it can be written better using allow :o)
PEP: don't understand 'another session'
PEP: access denied
PEP: error

b