Re: [xacml] Obligations in Rules?

[Erik Rissanen <erik@axiomatics.com>]

Thanks, see inline.

bill parducci wrote:
>> a. The mechanism will be the exact same thing at the low technical 
>> level in the PDP, so it's implementation overhead to have them both.
>
> 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.

>> b. As I think Hal said on the previous call, if we have two 
>> mechanisms, then it's going to be really hard for us to tell people 
>> when to use which of the two mechanisms because the end result will 
>> be the same regardless which one is used, and there is going to be a 
>> huge gray area between what is a genuine obligation and what is an 
>> informational obligation.
>
> If it is hard to define the use of two discretely defined mechanisms, 
> then I suggest it is impossible to describe the use of a polymorphic 
> junk drawer in any way that will be portable.

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.

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.

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

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.

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

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.

>> 3. The question then is, as you say, should we reconsider the term 
>> "obligation". For me personally I don't mind the name since it's the 
>> semantics which matter. Also, if we change it, people will wonder 
>> what the difference to 2.0 is. It also means a bit more code for 
>> implementations which support both 2.0 and 3.0, but I suppose that 
>> this is no big deal.
>
> I think it is very dangerous to take the position that the meaning of 
> the nomenclature is unimportant. The TC wrestled with the term 
> Obligations for weeks in an attempt to be precise about what this 
> instrument is designed for. Relying solely upon semantics will allow 
> us to solve the problem for a discrete implementation but I fear that 
> attempting to use this across implementations will require a very 
> "white box" approach to interoperability.

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.

regards,
Erik