Re: [xacml] Obligations in Rules?

[Erik Rissanen <erik@axiomatics.com>]

Thanks Bill,

Yes, I agree that the term is perhaps not the best. Some things I note:

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.

So I think we should make the particular change below.

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:

 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.

 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.

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.

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.

So I am opposed to changing the name, but I could reconsider this if 
convincing enough arguments are presented. :-)

Best regards,
Erik


bill parducci wrote:
> Personally, I think that if we take this step--for the Use Cases I 
> have seen given--we should reconsider the term Obligation. I have been 
> a huge proponent of "more expressive" decisions, but I don't not think 
> it makes sense to extend the definition of what an Obligation is to 
> solve this.  "Reasons for a decision" are informational and have 
> nothing to do with the original intent or definition of an Obligation.
>
> This is not to say that I disagree with the mechanism, I just think 
> that overloading the term Obligation will not benefit interoperability 
> or clarity in the policies.
>
> b
>
> On Dec 10, 2008, at 2:57 AM, Erik Rissanen wrote:
>
>> All,
>>
>> Do we want obligations in rules? I think we should and if the general 
>> opinion is that this is a good idea, could you let me know and I 
>> could post a working draft with this change so review is quicker?
>>
>> In short this change means that the Rule schema would be changed to 
>> this:
>>
>>   <xs:element name="Rule" type="xacml:RuleType"/>
>>   <xs:complexType name="RuleType">
>>       <xs:sequence>
>>           <xs:element ref="xacml:Description" minOccurs="0"/>
>>           <xs:element ref="xacml:Target" minOccurs="0"/>
>>           <xs:element ref="xacml:Condition" minOccurs="0"/>
>>           <xs:element ref="xacml:ObligationExpressions" minOccurs="0"/>
>>       </xs:sequence>
>>       <xs:attribute name="RuleId" type="xs:string" use="required"/>
>>       <xs:attribute name="Effect" type="xacml:EffectType" 
>> use="required"/>
>>   </xs:complexType>
>>
>> Note the new line "ObligationExpressions". (It's obligation 
>> expressions, not obligations only because of the dynamic obligations 
>> change we made last time.)
>>
>> The semantics are the same as for obligations in policies, that is, 
>> if the rule evaluates to a decision with a matching FullfilOn the 
>> obligations are included in the result of that Rule.
>>
>> Note that since a rule has a fixed Effect, either Permit or Deny, it 
>> doesn't make sense to specify an obligation with the other decision 
>> in the FullfilOn, but I don't think we should define a different 
>> schema construct just for the obligation in the rule.
>>
>> The benefit of all this is that if someone has a condition at the 
>> rule level which he would like to associate with an obligation, then 
>> it would not be necessary to wrap the rule inside a policy just to 
>> contain the obligation.
>>
>> Best regards,
>> Erik
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>