Re: [xacml] Multiple obligations

[Bill Parducci <bill@parducci.net>]

On Jun 7, 2011, at 6:11 AM, Tyson, Paul H wrote:

> I agree that the core spec should be improved with respect to obligation-combining.
> 
> But I'm not sure now is the time to do it unless we want to delay 3.0 indefinitely.  We don't have any good use cases or requirements around obligation processing (unless there are some from the 2.0 days), so we would spend some time digging up use cases and requirements before we could consider design options.

There is a thread on the wiki that provides enough information to tackle this I believe (http://wiki.oasis-open.org/xacml/ProposalForObligations), however the scope of functional coverage is the is the crux of the problem with Obligations. Any "improved" solution must be able to handle extensions to any Use Case we conceptualize now. Simple examples that have been used in the past are Notify, Filter and Encrypt (http://wiki.oasis-open.org/xacml/DiscussionOnObligations).

> A purely mathematical approach that only considered possible collections of obligations would probably not meet any business needs.  One goal of the design should be to reduce the indeterminacy as much as possible so the policy writer can predict what obligations/advice will be returned from a given request context.

Because Obligations are non-binary decisions I believe the solution to this needs to be referential. In other words, a source external to the Policy/PolicySet is needed that describes not only the precedence of Obligation types, but of Obligation values as well. Further, I believe that we need to complete the work on the the "meta policy" before a complete solution is possible because this seems to be the most logical place to persist/communicate what Obligations are supported by the PDP. This doesn't solve the problem of a federated system unfortunately (unless there was a mechanism to handle unaligned Obligation support amongst PDPs).

> I'm not sure we should tie obligation-combining with policy- or rule-combining, since they are really orthogonal concerns.  An alternative design would be to define obligation-combining algorithms that can be specified by the policy writer.  These algorithms would reduce the set of candidate obligations/advice to an actual return set.  I haven't thought this out completely.

I do not think this is possible. In the past, the unbounded relationship between Policy/PolicySet means that the Policy writer must have awareness of the entire system to ensure the Obligation is applied as desired.

b