Re: [xacml] Obligations in Rules?

[Bill Parducci <bill@parducci.net>]

>> Since neither is required to be supported it is a decision of the  
>> implementer as to what overhead is appropriate.
> Yes, but if there is only one mechanism, then it's less work to  
> implement both uses.

This assumes that one wishes to implement both sets of functionality.  
You can argue that you get both for "free" but that feeds into my  
position that what you really get is an implementation black hole.  
Having this in place as proposed implies that any supporting either  
use supports both (whatever that is).

> What I mean is that if we end up with two mechanisms with the same  
> functionality, where the only difference is the "philosophical"  
> interpretation of the terminology, then it will be difficult to  
> explain to users what belongs in which category. For instance, are  
> the classifications of these clear?

> 1. "For your information,  access was allowed because of Freedom of  
> Information Policy".
>
> 2. "For your information, access was allowed because of Freedom of  
> Information Policy, and also make sure you note this in the logs".
>
> 3. "For your information, access was allowed because of Freedom of  
> Information Policy, and it may mean that you have to do something  
> special because of this".
>
> 4. "For your information,  access was allowed because of Freedom of  
> Information Policy". And the recipient does something special,  
> without telling anyone about it, even though the policy writer did  
> not ask for it when he communicated the meaning of the identifier.
>
> Which of these are information, which are obligations. Could they be  
> both? If we have two mechanisms, I can see users arguing about it on  
> the users list taking different standpoints. :-) And in general, why  
> would someone provide "information" if he did not expect the other  
> party to act on it in some way. So in some sense all information can  
> be seen as "commands" to the recipient.

So what you are saying is that as a TC we cannot sufficiently describe  
a mechanism or mechanisms to differentiate this but it is soluble by  
providing implementers with a magic box that can contain anything-- 
actionable or not--and this is OK? We cannot enforce specific usage of  
the framework, however I think we should avoid design that exacerbates  
non-portable information. I am not concerned if the payload is "clear"  
I am arguing that the context must be where possible. The Use Cases I  
heard seemed quite explicit, common and begged for some sort of  
causality attribute to be returned. This is not ambiguous or  
superfluous in my opinion and I can see many people using it and  
choosing to implement Obligations.

> Yet another aspect is that the architecture of a PDP/PEP implies a  
> trust model where the PDP does not control the resource. This means  
> that in some sense the PDP is ultimately just providing enforcement  
> advice to the PEP, which means that a rock solid genuine obligation  
> in a sense is just advice/information to the PEP since if the PEP  
> does not follow through, the PDP might not be able to do anything  
> about it.

Not entirely true. The intent of an Obligation is that while it's  
ramifications exist outside of the decision/enforcement context that  
should the PEP not be able to fulfill it a systematic error condition  
would be generated. Of course how this works is implementational but  
that doesn't discount the concept that a Policy Writer would  
reasonably expect that an Obligation is carried out and if not there  
are subsequent actions. This is not necessarily the case with  
causality as it is a logical attribute of the decision, not a  
component of it:

Obligation: "PERMIT + DO"
Cause: "DENY + WHY"

> Anyway, maybe it's just me, but I have a hard time seeing a clear  
> difference between information and obligations.
>
> Portability will "not be an issue" as long as users understand the  
> meaning of each individual obligation identifier. (I'm ignoring the  
> complication that each obligation id requires dedicated code, but I  
> don't think that is relevant because if the TC would define the  
> obligation identifier, then it would be portable, and if the TC  
> doesn't, then it's a extension point, and cannot be expected to be  
> portable. And for now I'm not going to open up the discussion if  
> there are any particular obligation ids that the TC should  
> define. ;-))

By channeling increased functionality that is not portable we are  
encouraging the wrong behavior IMO. I make this same argument every  
time we want to add an extension point for the same reasons. Sometimes  
you must bite the bullet and do such things, but because there is  
overlap in mechanics doesn't seem like one of those times.

> What I am saying is that it could be difficult to define in a clear  
> cut way for each individual obligation identifier whether it belongs  
> in the "information" or "obligation" category.

What I am saying is that I don't consider Cause a subset of  
Obligation. It simply isn't. The mechanisms can be identical (in which  
case I would argue that implementation overhead would be quite light),  
but they are fundamentally different.

> But in any case, I can think of a valid reason for a separate  
> "information" mechanism. Currently the PEP must not ignore  
> obligations, and must fail if it sees an obligation id which it  
> doesn't recognize. If it knew that an obligation is information  
> only, then it could safely ignore the "information". If this were  
> the case, then it would really be two different mechanisms with  
> distinct behaviours, beyond the mere "internal interpretation" of  
> the obligation identifier. (The same effect could of course be  
> achieved with a 'MayBeIgnored="true"' in the obligation.)

[side note] a PEP that *accepts* Obligations must behave thus. I could  
be wrong but I seem to recall that a PEP that chooses not to support  
Obligations may ignore them and proceed (one of the places where I  
believe PDP meta data could come in handy ;).

I understand that you can look at this mechanically and say, "If i  
just put all the stuff there isn't an explicit mechanism to handle  
into this field then I can 'extend' the Policy to do whatever I need."  
What I am saying is that I think it is a Bad Idea to encourage it.

> What I am opposed to are two mechanisms with the exact same effect  
> in all respects, except that they are supposed to be used for two  
> different categories of interpretation of the identifier. There must  
> be some explicit difference between them.

I think there clearly are, just maybe not mechanical :)

> No, I am not taking the position that naming does not matter. What I  
> am saying is that in this case the error is not so big, so I can  
> live with it. And changing it might be worse.

Sorry, but "junk drawers" bubble up to the top of my pet peeve list,  
so I have a hard time "living with it" ;)

b