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
