[Odrl-version2] RE: ODRL-Version2 Digest, Vol 12, Issue 4

Alapan Arnab aarnab at cs.uct.ac.za
Tue Jan 17 07:12:18 EST 2006


On Mon, 2006-01-16 at 13:16 -0500, Vicky Weissman wrote:
> <Alapan Arnab>
> A ticket in both models is essentially the same as a ticket for a concert,
> the bus etc - it gives the bearer a set of rights from the rights holder; and
> the bearer is not a defined party (so I could give you my ticket and you will
> have access).
> 
> <Vicky Weissman>
> If that's the case, then a ticket is a contract in which the relevant party
> is "agreement holder", so I still don't see why ODRL has both
> agreements/contracts and tickets, rather than a principal "agreement holder"
> (which I think would be simpler).
> 
Can't really counter that - because I totally agree. Although, to be
fair, the current approach does make implementation easier.
> -----------------
> <Vicky Weissman>
> I'm not sure why a use license cannot both grant some permissions and forbid
> others.
> 
> <Alapan Arnab>
> My problems with the existing model was the fact that it was possible to have
> a license that granted and forbid the same set of permissions. This problem
> is clearly overcome with my approach.
> 
> <Vicky Weissman>
> Whether your approach overcomes the problem depends on how we reason about a
> set of licenses.  If we consider each license independently of the others,
> then I agree that your approach solves the problem.  If we consider the
> licenses as a set, then the problem essentially still exists, since one
> license can permit an action that another forbids.    
> 
Ah - I see what you mean. The next question then should be - how does
license sets work. Assume that Alice has License A, B, and C for the
Object O. In my view, Alice should be able to perform any action
permitted by A, B or C unless a license is explicitly invalidated - i.e.
if C states that B is invalidated, then any rights allowed by B is
ignored. Which leads to a new requirement - there should be a mechanism
to invalidate other licenses - like a revocation list.

I do not see why licenses for a particular object should be evaluated as
a set - because there could be specific reasons for having multiple
licenses (different validity dates for example). 
> ------------------
> <Alapan Arnab>
> The current motto in RELs is - grant only the rights that are mentioned.
> Thus in a prohibition model - it should simply be assign all the rights
> except the ones mentioned. For this reason, there is no need to ever express
> a set of rights that are forbidden.
> 
> <Vicky Weissman>
> If we assume every action that is not explicitly permitted is forbidden, then
> we lose the distinction between what is forbidden and what is unregulated
> (i.e., we force every agreement to regulate every action).  As a result,
> agreements will often contradict one another, even when the intentions of the
> agreements' writers are not in conflict. 
> 
> To illustrate the idea, suppose that Alice's mother says she may have a
> cookie (i.e., issues an agreement giving Alice this right) and Alice's father
> says she may play outside (i.e., issues an agreement giving Alice this
> right).  If I've understood your suggestion correctly, then you would say
> that Alice's mother permits Alice to have a cookie and forbids Alice from
> doing anything else, including playing outside and even breathing; similarly,
> Alice's father permits Alice to play outside and forbids Alice to do anything
> else, including eating a cookie and breathing. So, while the parents agree
> that Alice is not allowed to breath, they disagree over whether she may eat a
> cookie and whether she may play outside.  That is, the agreement issued by
> Alice's mother contradicts the agreement issued by Alice's father (and the
> overall interpretation is just plain silly).  
> 
> It is not clear how we could "fix" the agreements.  Certainly, the agreements
> could be rewritten so that Alice's mother and father both permit eating a
> cookie, playing outside, and breathing (along with all other unobjectionable
> activities).  But what if Alice's mother doesn't care about whether Alice may
> play outside?  Then we're forcing the mother to regulate an action that she
> doesn't care about and, if she permits when the father forbids (or
> vice-versa), we get a conflict.    
Ok - I see your objections. I have been working on a similar problem for
a while and have sort of invented a new concept for rights which I have
been calling "Level 1 vs Level 2 rights". This work has been raised from
a smaller sub project on a OS kernel level DRM. Basically, level 1
rights are core rights that can be enforced on any system, regardless of
OS, hardware etc. I haven't identified all of these rights, but they are
basically quite a few common access rights like - read, modify, and
execute (i.e. very similar to the file permission security). 

Level 2 rights are rights that have specific meaning to the data and
application in question. For example, the concept of a printable page
has meaning in a word processor but has no meaning for wireframe models
for games.

So far what we are working on, is that, level 1 rights are mandatory -
they are either allowed or disallowed. Level 2 rights will be dependent
on the application and the data involved, and should be taken as "rights
holder doesn't really care". Thus - for humans, breathing would be a
level 1 right, while playing outside and eating cookies would be level 2
rights.

Maybe this type of approach will solve this issue - as regardless of
which prohibition model we use, the issues you mention will remain.
> ------------------
> <Vicky Weissman>  
> suppose an agreement says only that Alice may print 5 copies of the report.
> Your suggestion could be equivalent to "if Alice has not made 5 copies, then
> she may print the report and is forbidden to do anything else; otherwise, she
> is forbidden to do any action".  Alternatively, you could mean "if Alice has
> not made 5 copies, then she may print the report and she is forbidden to do
> anything else to the report; otherwise, there is no action that she can do
> legitimately that involves the report".  
> 
> <Alapan Arnab>
> On the examples you mention (with Alice printing) - I am not sure what the
> difference is.
> 
> <Vicky Weissman>
> The first interpretation implies that Alice is forbidden to breath; the
> second implies only that she is forbidden to breath on the report (or do
> anything else *to the report*, other than possibly printing). 
>  
Understood - and although in context I was only thinking of the object
in the digital sense; which is incorrect as ODRL should be usable as a
normal object.
> -------------
> <Alapan Arnab> 
> I would like to read your journal paper. 
> 
> <Vicky Weissman> <grinning>
> The current version can be downloaded from
> http://www.cs.cornell.edu/People/vickyw/tmp/PucellaWeissman.pdf (.ps).
> Comments very welcome (though, for reasons of personal sanity, I probably
> won't put in changes until the paper has come back from review).  
> 
Will have a look - not sure I have time in the near future to comment on
it though.

Regards
Alapan
-- 
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



More information about the Odrl-version2 mailing list