Re: [xacml] Obligations in Rules?

[bill parducci <bill@parducci.net>]

> 1. Support for obligations in Rules is relevant even for "genuine"  
> obligations, so this change is really orthogonal to the meaning of  
> the term obligation.

I agree that there is value in more granular control/response. So long  
as we are providing that mechanism in order to actually provide more  
granular obligations.

> 2. I don't think it's a good idea to have two different mechanisms,  
> one for genuine obligations and one for "informational" obligations.  
> The reasons are:

"Informational Obligations" is an oxymoron and as such is an anathema  
to standards definition in my opinion. There are Obligations--things  
which the PEP is compelled to act upon (read: verb)--and there is  
information that may be used in an number of ways (read: adjective).  
So I reject the notion that these are similar. True there is  
similarity in how they would be handled but as Rich pointed out, we  
have much of that in Policies and PolicySets today , yet they remain  
discrete.

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

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

> So I am strongly opposed two different mechanisms.
>
> 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.

> And as a side note, I think informational obligations are a special  
> case of genuine obligations since the interpretation of the  
> obligation is up to the obligation issuer to define, and he could  
> say that doing nothing is valid enforcement of the obligation.

Er, lets discuss the propriety of null actions later :)

b