[Odrl-version2] Prohibitions - the saga continues...

[Vicky Weissman]

<Alapan Arnab>
After rethinking on the issues discussed recently, I am wondering if there
there is a need for prohibitions in the first place?

<Vicky Weissman>
Most of the contracts (e.g., user agreements, leases) that I've read give
permissions, prohibitions, and obligations.  I figure that the people who
drew up these documents were saying what they felt needed to be said.  So I
think it would be wise for ODRL to include such statements.

>From a technical standpoint, if ODRL does not include prohibitions, then an
ODRL agreement cannot distinguish between what is forbidden and what is
unregulated.  Whether this distinction is important depends on the intended
uses for ODRL.  For example, suppose that ODRL is designed solely for
applications in which a user gets access by presenting an appropriate
agreement, namely one that grants the permission.  Then I'm not sure that the
distinction is important.  But, if we stray just a bit from this model, then
I think we'll want prohibitions.  To see why, consider the following example.


Suppose that a database of clinical information is jointly owned by hospital
H and research institute R.  To get access, an individual needs to present
agreements from both H and R that together imply the permission.  Notice that
we've stepped out of the model I gave in the last paragraph because it's not
enough to present an agreement; you have to give agreements from both H and
R.  Now I think we want prohibitions because we want to detect conflicts
between H and R (e.g., H permits an access that R forbids).  In fact, I think
my earlier suggestion is well-suited to this scenario.  Recall the suggestion
from my Jan 31 mail:

> I suggest we do the following:
> 
> (1) Extend agreements to include prohibitions, where a prohibition 
> says that an action is forbidden if certain conditions hold.
> 
> (2) Extend agreements to include a default, which is either permit or
forbid.
> 
> (3) Say that a set of agreements imply that a request (e.g., may Alice 
> download Season 1 of Lost) should be granted if (a) the agreements 
> together imply the request should be granted or (2) the agreements 
> together do not imply the request should be granted, do not imply the 
> request should be denied, and the default for all agreements is permit.

This approach allows H and R to write agreements that (a) give the conditions
under which access should be permitted and (b) give the conditions under
which access should be denied.  So we can detect if H and R disagree on
certain cases, thereby giving them a chance to resolve the dispute.  In
addition (3) allows H/R to give the default "forbid" so that, if neither
explicitly permits the action, then it's forbidden.   

What's missing from my suggestion is support for statements such as "if H
doesn't explicit give permission, then H forbids".  We could extend
agreements to include such statements, but I think it would be better to make
changes at a higher level; that is, instead of requiring that H and R's
agreements together imply permission, the application could require that H's
agreement(s) implies permission and R's agreement(s) implies permission.
Having the change at this level keeps agreements fairly simple and allows for
more flexibility when combining agreements.  For example, the application
could support voting (e.g., if most of the interested parties grant
permission, then permission is granted).     

In general, I think my suggestion is a good way to handle permissions based
on multiple agreements.  It also works just fine for the simpler case in
which any agreement will suffice (in which case the user presents only the
agreement that is most favorable to her, or the application considers the set
of presented agreements one-by-one).  

-Vicky