OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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
   (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 :)



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]