[Odrl-version2] Prohibitions - the saga continues...
Alapan Arnab
aarnab at cs.uct.ac.za
Mon Feb 13 19:21:07 EST 2006
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
More information about the Odrl-version2
mailing list