[Odrl-version2] Prohibitions - the saga continues...Reply to Alapan

[Alapan Arnab]

Hi,
Sorry -  I should have reread my email carefully .... copy and paste
always goes wrong. [3] should have read x E HPS & x !E H -> !pH

Anyway, the idea I am trying to get to:
The actions that need to be controlled (in any way) must be controlled
through a pre-defined set of permissions (permission set) (in ODRL 1.1,
the standard data dictionary was the standard permission set). For
example, for a music store, the permission set could be : [open, play,
remix, read]. Thus, the music store _chooses_ to control only those
permissions. Thus a license using that permission set can only control
those permissions. In such a license, the permission to "watch" has no
meaning and can be seen to be unregulated. The DRM controller in such a
case should allow that action (although it has no real meaning).

Now suppose you have two different licenses using different permission
sets that cover a common data file. The DRM controller can be setup to
only allow an action if both licenses allow that action. Thus, the only
times an action would be allowed is:
1) the action is unregulated by both licenses
2) the action is regulated and allowed by both licenses

My question is - given that the permission set is always finite, can
there be a scenario where a prohibition is explicitly required?

Regards
Alapan 
On Mon, 2006-02-13 at 22:12 -0500, Vicky Weissman wrote:
> Hi ,
> 
> On Feb 10, Vicky Weissman said:
> -------------------------------
> ... 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...
> 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). 
> 
> On Feb 13, Alapan Arnab replied:
> --------------------------------
> 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]).
> 
> Vicky Weissman, replying:
> ---------------------------
> I don't understand your notation.  In particular, I don't see why rule 1
> doesn't contradict rule 3 (and, similarly, why rule 4 doesn't contradict rule
> 6).  My best guess is that, for each DRM controller, you're maintaining two
> sets of information.  A permission is granted if it is in the controller's
> permission set and in the agreement; a permission is denied if it is in the
> controller's permission set and not in the agreement; and it is unregulated
> if it is not in the permission set nor in the agreement.  If this is the
> case, then you're essentially capturing prohibitions explicitly (as the
> difference between 2 sets), and you might as well do it in the standard way;
> that is, with permissions and prohibitions, instead of with permissions and a
> superset of regulated actions.
> 
> Regardless of your specific work-around, I do think that, for the example I
> gave, we want to distinguish forbidden actions from unregulated ones.
> (Having both permissions and prohibitions is, I believe, the most common way
> to do this.)  To clarify my thinking, suppose that Alice wants to access the
> clinical database directly and, to get access, she presents an agreement
> agr_H from the hospital that says "Alice may query the database" and she
> presents an agreement agr_R from the research institute that says "Alice may
> access the database directly".  Should Alice be given access?  If ODRL
> includes prohibitions, then agr_H does not object to Alice accessing the
> database and, as a result, I think the request should be granted.  If ODRL
> does not include prohibitions, then we can't tell whether the hospital does
> not object, in which case access should be granted, or the hospital forbids
> the action, in which case H and R contradict one another and some "default"
> action should be done (e.g., contact H and R so they can work out the
> disagreement, or give Alice access to a perturbed version of the database). 
> 
> -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