Thoughts on Obligations


Let's start with Daniel's suggestion that Obligation "categories" are handled via an attribute:

<obligation kind="async" id="timeout"/>30</obligation>

Extending that to Michiharu's concept of having four discrete categories of Obligation we have the following options for describing an Obligation:

<obligation category="atomic" id="encrypt"/>3DES</obligation>
<obligation category="sequential" id="timeout"/>30</obligation>
<obligation category="async" id="XXXXXXXX"/>ZZZZZZZZ</obligation>
<obligation category="supplemental" id="log"/>/var/log</obligation>
<obligation category="data-processing" id="filter"/>filter1</obligation>

This gives us OligationCategoryClasses which in turn are comprised of ObligationCategoryMembers. I propose that to combine Obligations we must first combine the ObligationCategories, then combine the ObligationCategoryMembers. If we are able to definitively describe the precedence of ObligationCategories and ObligationCategoryMembers, have an Exclusivity definition and there is some "root" policy from which a PDP may draw upon to determine precidence, we should be able to process any combination of Obligations.

DO WE NEED PRECEDENCE FOR ObligationCategories? (if not we need an assumption that Categories CANNOT be exclusive).


Processing occurs normally for the Policy: Targets matched, Rules combined and the corresponding Obligations are gathered. Combination of Obligations occurs by first ordering Categories using the precedence defined by the ObligationCategory combiner then by the precedence defined by the ObligationCategoryMember combiner, in effect creating a two dimensional resolution table.

For example, lets assume that we have three Obligations: encrypt, filter and log.

In this situation:

Let's further assume that:

Finally, we assume:

Suppose we have the following Obligations resulting from a Policy combination (to a result):

  1. ObligationCategory: encrypt
    ObligationCategoryMember: 3DES

  2. ObligationCategory: encrypt
    ObligationCategoryMember: blowfish

  3. ObligationCategory: filter
    ObligationCategoryMember: filter1
    ObligationCategoryMember: filter2
    ObligationCategoryMember: filter3

  4. ObligationCategory: log
    ObligationCategoryMember: file
    ObligationCategoryMember: syslog
    ObligationCategoryMember: db

In tabular form this may be expressed as:














Looking at ObligationCategoryExclusion for encrypt we see that 3DES and blowfish are exclusive and that 3DES has precedence over blowfish. Therefore blowfish is therefore discarded and 3DES is passed in the result.

Looking at ObligationCategoryExclusion for filter we see that filter1 and filter2 are exclusive and that filter2 takes precedence over filter1. Therefore filter2 is discarded and filter2 and filter3 are passed in the result.

Looking at ObligationCategoryExclusion for log we see that there are no exclusions. Therefore file, syslog and db are returned with the result.


From a schema perspective the concepts above are expressed thus in a Root Schema:



It is proposed that PEPs that recieve a decision with an Obligation that is not implementable results in an ERROR condition.


DiscussionOnObligations (last edited 2009-08-12 18:06:39 by localhost)