RE: [xacml-users] Help on Condition ? <-- Obligations

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

> -----Original Message-----
> From: Bill Parducci [mailto:bill@parducci.net] 
> Sent: Friday, December 12, 2008 12:04
> To: oleg@gryb.info
> Cc: xacml-users@lists.oasis-open.org
> Subject: Re: [xacml-users] Help on Condition ? <-- Obligations
> 
> 
> The position I have taken on the TC is that we should 
> differentiate between Obligations (Decision + ACTION) and 
> Causality (Decision + INFORMATION). The primary reason for 
> this is that Obligations are becoming overloaded to the point 
> that they are a general mechanism for anything not covered in 
> the spec. There is currently a proposal to push Obligations 
> to the Rule level (to solve some causality Use Cases) which I 
> think will only exacerbate the problem.

I agree that putting Obligations on Rules would make things worse.

> 
> My proposal therefore, is that we do not extend Obligations 
> to the Rule level and we introduce a mechanism that is 
> specifically intended for cause/advice responses. This 
> doesn't solve my concern with Obligations but it does provide 
> what I feel is a more precise mechanism for dealing with this 
> aspect of the decision response.

The PolicyIdentifierList feature in 3.0 is a sufficient concession to
the perceived need for cause/advice information in responses.  If you do
much more you're getting outside the access control model.  The question
is, what will (should/must) the PEP do differently depending on the
contents of the Result?  For a simple Decision, the behavior is obvious
and well-specified.  For a Decision+Obligation, the behavior is
well-specified in the spec, but apparently too restrictive for some
people.

> 
> The counter argument to my approach is that users will not be 
> able to easily differentiate between what it "actionable" and 
> what is "informational" so no additional benefit will be had 
> from adding an explicit causal response mechanism (that is 
> very similar to how Obligations work). For the specific case 
> you have below I would answer that "sign" is a verb which 
> makes this an ACTION. Therefore it would be an Obligation. 
> "Show reason of denial" does not require action by the PEP so 
> it would be an Advice (Cause, whatever we decide to call it 
> :). As an Obligation the Policy Writer should be able to 
> expect that the action will transpire and if not some sort of 
> error condition will occur. The latter will not be bound to 
> an explicit action and subsequent processing may or may not 
> act independently from the original decision request/response.
> 
> I would be very interested in hearing what the user community 
> thinks of this.

Isn't "Cause" already addressed by PolicyIdentifierList?  I can see two
other plausible instantiations of "Cause": 1) a natural-language
explanation for each rule; or 2) a reproduction of the logical schema
that implied the decision.  Either of these might be useful while
developing or debugging a XACML system, but are there good use cases for
a production system?  What would you want a PEP to do differently (with
respect to enforcement) if the decision came from Rule1 or from Rule2?

We have a use case that will require logging of certain decisions.  We
could get by with logging just certain decisions (e.g. "Permit"
decisions from a certain policy), but at this point it does not appear
to be a problem to log all decisions.  Technically, we can't use
"Obligation" for this because it has no bearing on whether the resource
is shown to the user or not.  (That is, if for some reason the logging
failed, we wouldn't deny access to the resource.)

I suggest "Message" instead of "Advice", because "Advice" implies at
least a small component of intended behavior for the PEP, and that
behavior is outside the scope of XACML.  "Message", on the other hand,
is neutral with respect to expected behavior.  It would meet everyone's
needs if Message could contain expressions to be evaluated within the
decision context, as well as foreign namespace elements to describe
anything else the policy writer wants the PDP to communicate to the PEP.
That would allow implementors to use application-specific contracts
between PDPs and PEPs without mucking up the XACML model.

--Paul Tyson