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

[Alapan Arnab]

Hi,
I don't think prohibitions are necessary at all to handle the scenario
you posted. I will try to give a logical proof why (I have ignored
invalid licenses):

Notation:
E  -> element of
H  -> license agreement from Hospital
R  -> license agreement from Research Institute
HPS-> hospital license permission set
RPS-> research institute permission set
x  -> the permission in question
pH -> permission granted by DRM controller (Hospital)
pR -> permission granted by DRM controller (RI)
pJ -> permission granted by DRM controller (joint data)

&  -> and
!  -> not

Rules:
1. x E HPS & x E H -> pH
2. x !E HPS & x !E H -> pH
3. x E HPS & x E H -> !pH

4. x E RPS & x E R -> pR
5. x !E RPS & x !E R -> pR
6. x E RPS & x E R -> !pR

7. pR & pH -> pJ

>From the above, it is clear, that [7] is satisfied iff ([1] | [2]) &
([4] | [5]).

The situation you describe is correctly handled.

I agree that explicit forbid is not handled, but that can be easily
handled by how x !E RPS is handled (i.e. forbid everything except what
is explicitly permitted). But in my opinion, this is a wrong approach,
and if the license holders need to control a right, that right should be
in the permission set.

Alapan
On Fri, 2006-02-10 at 12:34 -0500, Vicky Weissman wrote:
> <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
> 
> 
> 
>    
> 
> _______________________________________________
> ODRL-Version2 mailing list
> ODRL-Version2 at odrl.net
> http://lists.odrl.net/mailman/listinfo/odrl-version2
-- 
Alapan Arnab
Data Networks Architecture (DNA) Laboratory
Department of Computer Science
University of Cape Town
Rondebosch, 7700
South Africa

Tel: +27 21 650 3127
Web: http://people.cs.uct.ac.za/~aarnab/
Blog: http://idiots-mind.blogspot.com
----------
"You must always believe that you can be the best, but you must never
believe you have achieved it".
Juan Manuel Fangio