Combining Obligations - was Re: ... - action on ambiguity wrt set of returned Obligations, Advice

[Steven Legg <steven.legg@viewds.com>]

Hi David,

On 21/03/2013 9:53 PM, David Chadwick wrote:
> On 20/03/2013 23:51, William Parducci wrote:
> > [David Chadwick]
> > > > I think we need to take the discussion up one level initially,
> > > > and ask what does it mean for different policies to permit (or
> > > > deny) access providing its specific obligations are fulfilled,
> > > > regardless of any other policies decisions or obligations?
> > > >
> > > > Surely this only has meaning if the combining rule says it does.
> > > > So if the combining rule is permit overrides, and one policy
> > > > grants access without any obligations, then all other policies
> > > > granting access with obligations are irrelevant.
> >
> > [Steven Legg]
> > > Or maybe the writer of the policy without obligations was supposed
> > > to add those obligations but neglected to do so.
>
> It is impossible to build a policy based system that tries to second
> guess what policy the author meant to write, or should have written,
> rather than what he actually wrote. So this is surely out of scope.

I'm not trying to second guess the policy author. You're saying that if
an applicable policy grants access with no obligations and is combined
by permit-overrides, then the omission of obligations is always intentional.
I'm saying that it might be intentional, but for the obligations I've
seen discussed, it is more likely to be an error of omission. If anything,
you're second guessing the policy author by always taking the omission as
intentional. By introducing the OAA I aim to remove the doubt. The typical
delegate doesn't need to add obligations that are a matter of overall company
policy because those obligations are added by the OAA as required. Thus those
delegates can't create an error of omission with respect to those obligations.
If there are exceptional situations in which the obligations are not used,
then that is explicitly captured in the way the OA policies are written.

You might say that I've replaced errors of omission with errors of
commission (returning an obligation when it wasn't needed), but for the
obligations I've seen discussed, this is the fail-safe error to commit.
For example, encrypting something that didn't need to be encrypted is
better than failing to encrypt something that should have been encrypted.

Regards,
Steven

> One of the motivations for me building the OAA was the realization
> > > that the people creating access policies are not necessarily the
> > > people who care about the obligations,
>
> then you are talking about a different type of system to the one I was
> talking about. Yours appears to be a dual system, an access control
> system and an obligation enforcement system. Whilst the latter is based
> on the results of the former it is essentially independent from it.
>
>  From the rest of this message, we seem to be moving into the topic of usage control rather than simple (?)
> access control.
>
> regards
>
> David
>
>   especially in an environment where delegation is in use. For example,
> > > auditors care about obligations for auditing and logging, but
> > > project leaders setting access controls for their project's
> > > resources are far removed from those cares. Enabling the decoupling
> > > of obligation processing from decision processing using the OAA
> > > means that the auditors can determine when the obligations they
> > > care about are returned without having to rely on delegates to
> > > know, or do, anything about those obligations.
> >
> >
> > Agreed. This also makes management of the Obligations definitions,
> > etc. much more practical.
> >
> >
> > [David Chadwick]
> > > > Each policy is not working in isolation (if it were there would
> > > > not be an issue) but one might consider that all policies are
> > > > competing with each other for their decision to be the most
> > > > important one.
> >
> > [Steven Legg]
> > > Or cooperating. What you're talking about is obligations that
> > > depend not only on what access is granted/denied, but also on how
> > > that access is granted/denied, i.e., the reason for the decision.
> > > Since obligations can be about anything, we are going to find that
> > > some only depend on the "what" and some depend on the "what" and
> > > the "how", though the use cases I've encountered so far only depend
> > > on the "what". Fortunately, I can handle both with the OAA.
> >
> > I believe that using Obligations for QoS would involve the "how" (or
> > the "who" to be more precise), as would anything that generally
> > involved "parameterized decisions". For example, Subject requests
> > access to (abstract) Resource and Permit is granted with an
> > Obligation that references explicit instance of Resource, where
> > Obligation is based upon Subject (role, group) and/or Context
> > attributes (date, load, availability, etc.)
> >
> > b