Re: [xacml] 7.7 Obligations

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

Polar Humenn wrote:
> I didn't say anything about SAML.

"Polar Humenn wrote: [...] Are you going to call an application PEP compliant? Who would care?"

a large portion of SAML is based upon remote authorization decision requests, so by questioning PEP <--> PDP interaction you are making statements that imply lack of value in the better part of the SAML spec.
 
> I am not arguing that. But the question is something that permits access
> with an obligation has more power over somebody who permits plain access
> without any obligations. This forces you to ask all PDPs for and combine
> their obligations.

this assumes that you are going to have multiple PDPs protecting the same resource and that these PDPs would not be configured similarly (an operational issue in my mind). even if that were the case (it seems unlikely to me) i can also turn this argument around and say that if there are multiple PEPs protecting a resource i can get greater access to the one that doesn't support obligations becasue the PDP will return DIFFERENT RESULTS to it.

> Not really. The PDP has a clue about what obligations it will emit. If the
> PEP states its understandable obligations either by configuration or by
> RequestContext input, the PDP makes decision about whether to Permit with
> obligations or a Deny. This can be stated in a standard answer when
> converting the result of a rule/policy combining algorthim to a PDP
> Result.

and the protocol for a PEP to 'state its understandable obligations' is? are you proposing an extension to the XACML context? if part of the XACML spec, how do you differentiate syntactically between PEPs that support one type of obligation over another? (e.g. encrypt: 3-DES vs. blowfish vs. ?) if not in the XACML lexicon, is this now a configuration constraint that now must be reffered to by the spec? 

> However, this way everything is specified, and furthermore, the answer
> returned from a PDP can go through compiliance tests for that feature,
> yielding MORE ASSURANCE to the Process, Methods, and Products.

not sure how you come to this conclusion: conformance is now more difficult for the reasons stated above. rather than taking the position:

"if you don't understand the decision, effectively DENY--ALL PEPs behave the SAME"

and proposing:

"develop a methodology by which PEPs can communicate to to PDPs their innate ability to understand potential decision parameters so that the PDPs can filter the requests using one or more algorithms -- in or out of the xacml specification (further extensions to the spec or out-of-band configuration options)--thereby creating DIFFERENT outputs based upon the capabilities of the PEP" 

you are adding a tremndous amount of complexity.

b