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

[Bill Parducci <bill@parducci.net>]

On Dec 12, 2008, at 12:26 PM, Tyson, Paul H wrote:
> 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?

The Use Cases that spurred the [re]investigation of this functionality  
were reviewed with the TC as noted here (from the 12/4/08 TC minutes):

  Mike Beach from Boeing reviewed his authz Use Cases
   http://projectconcordia.org/images/d/d6/BoeingFineGrainedAuthorization.pdf
   (starting at slide 8)
   The basis of the talk is the ability of XACML to deal with export
   licensing using Obligations or is additional machinery needed?

> 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.

Works for me. We can call it FYI for all I care so long as the spec is  
explicit in what it is used for (refreshingly in this case there is  
absolutely no issue with combination beyond blind aggregation :)

thanks

b