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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: Re: [xacml] Obligations in Rules?

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.


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

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