From renato at odrl.net Tue Aug 2 17:04:02 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Requirement Analysis In-Reply-To: <1122543010.6827.117.camel@netwalker.cs.uct.ac.za> References: <1122543010.6827.117.camel@netwalker.cs.uct.ac.za> Message-ID: <1b4b3826ad6d0ac345cf8ef1cf4953b5@odrl.net> On 28 Jul 2005, at 19:30, Alapan Arnab wrote: > > After discussions at the ODRL workshop, Susanne asked me to do some > sort of an analysis of the v2 model to see if it fits with my project > needs. At the moment, my main focus is on negotiation of usage rights > and thus I have identified possible changes to the ODRL model (I think > section 3.2 could be the most interesting change in this regard). I > have also gone through the requirements document and looked for > requirements that I think are not fully met by the model, although I > could be wrong in my interpretation. Alapan - thanks for the analysis - great work and raise some interesting options. I was wondering if it maybe more useful to define a "rights protocol" which outlines the request/response/deny/accept/etc actions that one would like to do in a transactions. Then these can become the "headers" and ODRL the "body" of a SOAP message? Cheers... Renato Iannella National ICT Australia (NICTA) From aarnab at cs.uct.ac.za Fri Aug 5 01:15:08 2005 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Requirement Analysis Message-ID: <1123168508.6841.31.camel@netwalker.cs.uct.ac.za> > Alapan - thanks for the analysis - great work and raise some > interesting options. > > I was wondering if it maybe more useful to define a "rights protocol" > which outlines the > request/response/deny/accept/etc actions that one would like to do in a > transactions. > Assuming a super-distribution environment, the flow of messages should look something like: C : Consumer R : Rights Holder RightsX: A set of rights X //The controller requests rights for some protected digital object. At this moment, the consumer would not know of any options available C->R: Request(Object_ID) //The rights holder responds with a set of offers for various license types. In ODRL 1.1 this would be simple as there was only one license type. However, for the proposed model, there could be offers for Statements, Agreements or Tickets. R -> C : Offer(Agreement{Rights_A}, Statement{Rights_X}, Ticket{Rights_Y}, Agreement{Rights_Z}) >From here on, a negotiation can take place as described in my earlier attachment, i.e. C -> R : Offer(Agreement{Rights_A}, Reject), Request(Statement{Rights_B}) R -> C : Request(Statement{Rights_B}, Reject), Offer(Ticket{Rights_C}) C -> R : Offer(Ticket{Rights_C}, Accept) R -> C : Rights{Ticket(Rights_C)} > Then these can become the "headers" and ODRL the "body" of a SOAP > message? > Yes, the alternative is to instead of putting any negotiation in ODRL license, do negotiation in header. In that case, the ''offer'' construct would not belong in ODRL also. But my main issue with such a move is that it could create problems with interoperability as different implementers will start using different language in the headers for request, accept, deny etc. Also, while the preferred implementation for would be SOAP, there is no restrictions on using other mechanisms such as RPC. If a system wants to support multiple communication protocols, it will also have to deal with multiple headers etc. If everything is in the language itself, communication layer will only deal with the communication and not what the communication is intended for. Anyway, as I stated earlier, there are basically two approaches; and we need to agree on one. Cheers, Alapan ________________________________________________________________________ Alapan Arnab Data Networks Architecture (DNA) Group 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/ ---------- "You must always believe that you can be the best, but you must never believe you have achieved it". Juan Manuel Fangio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20050804/fbe6cbcf/attachment.html From Michael.Goulish at contractor.thomson.com Fri Aug 19 04:47:27 2005 From: Michael.Goulish at contractor.thomson.com (Michael.Goulish@contractor.thomson.com) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Any guess when 2.0 might be posted? Message-ID: <8879951C280FB64993EF76F04BBEB52101EEAC10@TLUSMIFHMBX01.ERF.THOMSON.COM> ...and ... is there any pre-release version of 2.0 that I could get, if I promise not to start building code for it? Thanks! --------------------------------------- Michael Goulish . From renato at odrl.net Fri Aug 19 10:50:09 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Any guess when 2.0 might be posted? In-Reply-To: <8879951C280FB64993EF76F04BBEB52101EEAC10@TLUSMIFHMBX01.ERF.THOMSON.COM> References: <8879951C280FB64993EF76F04BBEB52101EEAC10@TLUSMIFHMBX01.ERF.THOMSON.COM> Message-ID: On 19 Aug 2005, at 04:47, wrote: > ...and ... is there any pre-release version of 2.0 that I could > get, if I promise not to start building code for it? > Hi Michael - we don't have a definite timetable yet. However, we are looking for volunteers who can develop an XML binding for the model (which could be a good test to see if it raises other issues...) Cheers Renato Iannella ODRL Initiative http://odrl.net From Michael.Goulish at contractor.thomson.com Sat Aug 20 05:50:18 2005 From: Michael.Goulish at contractor.thomson.com (Michael.Goulish@contractor.thomson.com) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Any guess when 2.0 might be posted? Message-ID: <8879951C280FB64993EF76F04BBEB52101EEAC17@TLUSMIFHMBX01.ERF.THOMSON.COM> > However, we are looking for volunteers who can develop an XML binding > for the model ... Sign me up. How do I start? ------------------------------ Mick . From aarnab at cs.uct.ac.za Sun Aug 21 18:37:26 2005 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Any guess when 2.0 might be posted? In-Reply-To: References: <8879951C280FB64993EF76F04BBEB52101EEAC10@TLUSMIFHMBX01.ERF.THOMSON.COM> Message-ID: <1124613446.32309.6.camel@netwalker.cs.uct.ac.za> I will volunteer to do atleast part of the binding ... On Fri, 2005-08-19 at 10:50 +1000, Renato Iannella wrote: > On 19 Aug 2005, at 04:47, > wrote: > > > ...and ... is there any pre-release version of 2.0 that I could > > get, if I promise not to start building code for it? > > > > Hi Michael - we don't have a definite timetable yet. > > However, we are looking for volunteers who can develop an XML binding > for the model (which could > be a good test to see if it raises other issues...) > > Cheers > > Renato Iannella > ODRL Initiative > http://odrl.net > > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 ________________________________________________________________________ Alapan Arnab Data Networks Architecture (DNA) Group 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/ ---------- "You must always believe that you can be the best, but you must never believe you have achieved it". Juan Manuel Fangio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20050821/a408fba4/attachment.html From renato at odrl.net Fri Aug 26 15:37:35 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Any guess when 2.0 might be posted? In-Reply-To: <8879951C280FB64993EF76F04BBEB52101EEAC17@TLUSMIFHMBX01.ERF.THOMSON.COM> References: <8879951C280FB64993EF76F04BBEB52101EEAC17@TLUSMIFHMBX01.ERF.THOMSON.COM> Message-ID: <9A3BFFE6-A698-44C4-9863-9ECD37A9720A@odrl.net> On 20 Aug 2005, at 05:50, wrote: >> However, we are looking for volunteers who can develop an XML binding >> for the model ... >> > > Sign me up. How do I start? Mick - best option is to write up a document (use one of the ODRL templates [1]) and describe how the current V2 Model can be encoded using XML Schema. This may also highlight some issues back in the model that may need to be cleared up. Alapan has also volunteered to help. (Thanks guys!) Cheers Renato Iannella ODRL Initiative http://odrl.net [1] From orri at octalis.com Fri Aug 26 17:32:41 2005 From: orri at octalis.com (Xavier Orri) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Any guess when 2.0 might be posted? In-Reply-To: <9A3BFFE6-A698-44C4-9863-9ECD37A9720A@odrl.net> References: <8879951C280FB64993EF76F04BBEB52101EEAC17@TLUSMIFHMBX01.ERF.THOMSON.COM> <9A3BFFE6-A698-44C4-9863-9ECD37A9720A@odrl.net> Message-ID: <430EC599.9030608@octalis.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I was missing for a long period! Just know I don't have to much time but I would like to help you in the schema, document, whatever . Cheers Renato Iannella wrote: > > On 20 Aug 2005, at 05:50, > wrote: > >>> However, we are looking for volunteers who can develop an XML binding >>> for the model ... >>> >> >> Sign me up. How do I start? > > > > Mick - best option is to write up a document (use one of the ODRL > templates [1]) > and describe how the current V2 Model can be encoded using XML Schema. > This may also > highlight some issues back in the model that may need to be cleared up. > > Alapan has also volunteered to help. > > (Thanks guys!) > > Cheers > > Renato Iannella > ODRL Initiative > http://odrl.net > > [1] > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 - -- +--------------------------------------------------------------------+ | Xavier Orri | mailto:orri@octalis.com | | Octalis S.A. | Tf: + 32 (0)10 45 81 99 | | 2A Avenue Albert Einstein | GSM: + 32 (0)497 45 68 03 | | 1348 Louvain-la-Neuve, Belgium | Fax: + 32 (0)10 45 57 29 | | URL: http://www.octalis.com | +--------------------------------------------------------------------+ +---------------------------- DISCLAIMER ----------------------------+ | "This e-mail and any attachments thereto may contain information | | which is confidential and/or protected by intellectual property | | rights and are intended for the sole use of the recipient(s) named | | above. Any use of the information contained herein (including, but | | not limited to, total or partial reproduction, communication or | | distribution in any form) by persons other than the designated | | recipient(s) is prohibited. If you have received this e-mail in | | error, please notify the sender either by telephone or by e-mail | | and delete the material from any computer. | | Thank you for your cooperation." | +--------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDDsWYF75q8CD+EqURAoGSAKCYhFqKw3B6OMPzLwF7phe+qZcmzQCfcCD5 nOlW46x7GCP3seyURuOzo+I= =BO0J -----END PGP SIGNATURE----- From renato at odrl.net Fri Aug 26 17:38:05 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Any guess when 2.0 might be posted? In-Reply-To: <430EC599.9030608@octalis.com> References: <8879951C280FB64993EF76F04BBEB52101EEAC17@TLUSMIFHMBX01.ERF.THOMSON.COM> <9A3BFFE6-A698-44C4-9863-9ECD37A9720A@odrl.net> <430EC599.9030608@octalis.com> Message-ID: On 26 Aug 2005, at 17:32, Xavier Orri wrote: > I was missing for a long period! Just know I don't have to much > time but > I would like to help you in the schema, document, whatever . Great to hear from you Xavier! Looks like we have a good team to move the XML bindings forward. Cheers Renato Iannella ODRL Initiative http://odrl.net From vickyw at cs.cornell.edu Sat Aug 27 01:24:51 2005 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Reasoning about an Agreement Message-ID: <772EF7E386FEDF4FA6E11A9DA703A4D25E6F69@EXCHVS1.cs.cornell.edu> Hello, A few months ago, I told Renato that I would try to address the question "how do we determine whether an action is permitted/forbidden by an agreement". I'm sorry it has taken me so long to do this. To start the discussion, consider an agreement A that does not include a prohibition or duty. We can rewrite the agreement as a set S of statements, each of the form "if constraints c1, ..., cn hold then user u may do action a to asset s" (e.g., if Alice has made less than 5 copies of file f and today's date is before Aug, 31, 2005, then Alice may make a backup of f). For brevity, I'll write these statements as "c1 AND... AND cn => Perm(u, a, s)". The Model Semantics doc (dated May 16, 2005) seems to say that two statements in S can only differ on their action element. In other words, every statement in S includes the same constraints, user, and asset. This doesn't make sense to me, so I'm going to assume the statements can refer to different constraints, users, and assets. If I'm wrong, then I've simply answered the question for a more general problem. (As an aside, I think different statements in S can have different constraints if you modify the existing model so that constraints can be in "and" and "or" containers.) Suppose we want to determine if the statements in S imply that Alice is permitted to copy a file f. A na?ve approach, call it ProcN, is to find the set T of statements that are in S and have the form "c1 AND... AND cn => Perm(Alice, copy, f)". For each t in T, check if the constraints hold. (I'm assuming constraint checking is fairly straightforward. If the constraint includes a status element, the check should be trivial; otherwise, I imagine a database query of some sort would determine if the constraint held.) If all of the constraints in a t in T hold, then we say Alice is permitted to copy file f; otherwise, we say the permission is not explicitly granted by A. That's the obvious approach. What could go wrong? One problem is that we need to be a bit careful about encoding S from A. Suppose that A gives a group g permission to do an action a to an asset s provided that the forEachMember constraint holds. This means that every member of g may do a to s. So we want S to include Perm(u, a, s) for every member u of g, rather than "forEachMember => Perm(g, a, s)". If g is a large group or its members are not known, then we can use variables and modify ProcN accordingly. Another problem is that ProcN might not give the intuitively correct answer if S contains two statements whose constraints, roughly speaking, cancel out. For example, suppose S includes the statements "if Alice has made less than 5 copies of h, she is permitted to copy f" and "if Alice has made at least 5 copies of h, she is permitted to copy f". Then we should conclude that Alice may copy f, even if we don't know how many times she's copied h. (This is because we know she either copied h less than 5 times or at least 5 times and, in either case, she's allowed to copy f.) This is not the answer produced by the na?ve algorithm. Joe Halpern and I have outlined an alternative approach in "Using First-order Logic to Reason about Policies". The conference version is online and the journal version, which is significantly better, is almost done (please ping me if you want an almost-finished copy). If you want to consider the approach seriously, but don't want to wade through a paper written for logicians, I can summarize the paper by giving pseudocode for answering queries and a few restrictions that guarantee the algorithm is relatively efficient. (I need to think a bit about how to do this for ODRL, but I'm fairly confident that I can.) Alternatively, we could decide that the 2 statements alone do not imply that Alice may copy f. In general, we could define an agreement so that a permission is granted only if it follows from a single statement. If we do this, then the naive strategy for answering queries will give the correct answer according to the definition, but I don't think it gives the intuitively correct answer. A similar option is the one taken by XACML; each statement is considered individually but the parties decide how to interpret the results (e.g., a permission could be granted if it follows from a single statement, if it follows from at least 3 statements,...) We can easily modify the above discussion for agreements that have Prohibitions, rather than Permissions. But what if an agreement has both? Then we need to handle inconsistencies; that is, when a user is both permitted and forbidden to do an action to an asset. Probably the easiest solution is to restrict agreements so this can't happen. Alapan recommended an approach in this category by suggesting that agreements are redefined so that an agreement cannot have both a Permissions and a Prohibitions entity. That will work, but it seems a bit drastic. Alternatively, we could require that the same action name does not appear in both the Permission and the Prohibition. Another option is to require that, if the same action name appears in both, then the corresponding constraints cannot simultaneously hold. For example, an agreement A could say "Alice may copy f if she has made less than 5 copies of f" and "Alice may not copy f if she has made at least 5 copies of f", because Alice cannot satisfy both constraints simultaneously. It should be fairly easy to build an app that checks if an agreement might be inconsistent and warns the parties accordingly. Best, Vicky From Susanne.Guth at gmx.net Sun Aug 28 19:02:03 2005 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: =?ISO-8859-1?Q?Re:_[Odrl-version2]_Reasoning_about_an_Agreement?= References: <772EF7E386FEDF4FA6E11A9DA703A4D25E6F69@EXCHVS1.cs.cornell.edu> Message-ID: <9123.1125219723@www25.gmx.net> Hi Vicki! First of all, thanks for going into this. > > To start the discussion, consider an agreement A that does not include a > prohibition or duty. We can rewrite the agreement as a set S of > statements, > each of the form "if constraints c1, ..., cn hold then user u may do > action a > to asset s" (e.g., if Alice has made less than 5 copies of file f and > today's > date is before Aug, 31, 2005, then Alice may make a backup of f). For > brevity, I'll write these statements as "c1 AND... AND cn => Perm(u, a, > s)". YES! That's what is how REL statements are actually transmitted into code. See: "S.Guth, G. Neumann, M. Strembeck: Experiences with the Enforcement of Access Rights Extracted from ODRL-based Digital Contracts. In Workshop-Proceedings of the ACM Workshop on Digital Rights Management, Washington D.C./USA, Oktober 2003. [pdf, ps, BibTex]" WE used role based access control software to formulate the ODRL statement as an access control statement in software objects. > The Model Semantics doc (dated May 16, 2005) seems to say that two > statements > in S can only differ on their action element. In other words, every > statement in S includes the same constraints, user, and asset. This > doesn't > make sense to me, so I'm going to assume the statements can refer to > different constraints, users, and assets. If I'm wrong, then I've simply > answered the question for a more general problem. (As an aside, I think > different statements in S can have different constraints if you modify the > existing model so that constraints can be in "and" and "or" containers.) Vicky. Where do you read that that two statements can only differ on their action element? That is not the case. Only every constraint is exclusively related to an asset (not two assets) and exclusively related to one action (two actions in one constraint are not possible). A constraint is becoming a duty, permission, or prohibition as soon as it is related to a particular person. Vicky. We thought about this "and" "or" expressiveness in our model in Lissabon but did not really find a nice solution. Any proposals? > > Suppose we want to determine if the statements in S imply that Alice is > permitted to copy a file f. A na?ve approach, call it ProcN, is to find > the > set T of statements that are in S and have the form "c1 AND... AND cn => > Perm(Alice, copy, f)". For each t in T, check if the constraints hold. > (I'm > assuming constraint checking is fairly straightforward. If the constraint > includes a status element, the check should be trivial; otherwise, I > imagine > a database query of some sort would determine if the constraint held.) If > all of the constraints in a t in T hold, then we say Alice is permitted to > copy file f; otherwise, we say the permission is not explicitly granted by > A. > > That's the obvious approach. What could go wrong? One problem is that we > need to be a bit careful about encoding S from A. Suppose that A gives a > group g permission to do an action a to an asset s provided that the > forEachMember constraint holds. This means that every member of g may do > a > to s. So we want S to include Perm(u, a, s) for every member u of g, > rather > than "forEachMember => Perm(g, a, s)". If g is a large group or its > members > are not known, then we can use variables and modify ProcN accordingly. I do not really understand the problem here can you state it in more detail? However, of course we can not develop all S if the members of a group are not known. We have to assume are members are know. Which would also be the case in a real implementation. > Another problem is that ProcN might not give the intuitively correct > answer > if S contains two statements whose constraints, roughly speaking, cancel > out. > For example, suppose S includes the statements "if Alice has made less > than 5 > copies of h, she is permitted to copy f" and "if Alice has made at least 5 > copies of h, she is permitted to copy f". Then we should conclude that > Alice > may copy f, even if we don't know how many times she's copied h. (This is > because we know she either copied h less than 5 times or at least 5 times > and, in either case, she's allowed to copy f.) This is not the answer > produced by the na?ve algorithm. Joe Halpern and I have outlined an > alternative approach in "Using First-order Logic to Reason about > Policies". > The conference version is online and the journal version, which is > significantly better, is almost done (please ping me if you want an > almost-finished copy). If you want to consider the approach seriously, > but > don't want to wade through a paper written for logicians, I can summarize > the > paper by giving pseudocode for answering queries and a few restrictions > that > guarantee the algorithm is relatively efficient. (I need to think a bit > about how to do this for ODRL, but I'm fairly confident that I can.) Please do if you find time. > Alternatively, we could decide that the 2 statements alone do not imply > that > Alice may copy f. In general, we could define an agreement so that a > permission is granted only if it follows from a single statement. If we > do > this, then the naive strategy for answering queries will give the correct > answer according to the definition, but I don't think it gives the > intuitively correct answer. A similar option is the one taken by XACML; > each > statement is considered individually but the parties decide how to > interpret > the results (e.g., a permission could be granted if it follows from a > single > statement, if it follows from at least 3 statements,...) That seems to be a good approach: Do I undestand that correctly: In our case above, in case the rule is "permissions are granted if it follows from a single statement" then the permission is granted. Then a second iteration may start with the rule "permissions are gratned if it follows from 3 statements." then the permission would be denied. After, the second iteration we have an indicator for statements whose constraints cancel out. The interpretation process of each individual party might decide how to deal in these cases...no? > We can easily modify the above discussion for agreements that have > Prohibitions, rather than Permissions. But what if an agreement has both? > Then we need to handle inconsistencies; that is, when a user is both > permitted and forbidden to do an action to an asset. Probably the easiest > solution is to restrict agreements so this can't happen. Alapan > recommended > an approach in this category by suggesting that agreements are redefined > so > that an agreement cannot have both a Permissions and a Prohibitions > entity. > That will work, but it seems a bit drastic. Alternatively, we could > require > that the same action name does not appear in both the Permission and the > Prohibition. Another option is to require that, if the same action name > appears in both, then the corresponding constraints cannot simultaneously > hold. For example, an agreement A could say "Alice may copy f if she has > made less than 5 copies of f" and "Alice may not copy f if she has made at > least 5 copies of f", because Alice cannot satisfy both constraints > simultaneously. It should be fairly easy to build an app that checks if > an > agreement might be inconsistent and warns the parties accordingly. Thanks for your proposals here. We need Permissions and Prohibitions in one Agreement, simply to express the CC licenses. But I like the idea of restricting on the action level, i.e. the permission "play" may not be included in permission and prohibition. Any other comments of the ODRL interest list people? So long Susanne -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse f?r Mail, Message, More +++ From Susanne.Guth at gmx.net Sun Aug 28 19:02:03 2005 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: =?ISO-8859-1?Q?Re:_[Odrl-version2]_Reasoning_about_an_Agreement?= References: <772EF7E386FEDF4FA6E11A9DA703A4D25E6F69@EXCHVS1.cs.cornell.edu> Message-ID: <9123.1125219723@www25.gmx.net> Hi Vicki! First of all, thanks for going into this. > > To start the discussion, consider an agreement A that does not include a > prohibition or duty. We can rewrite the agreement as a set S of > statements, > each of the form "if constraints c1, ..., cn hold then user u may do > action a > to asset s" (e.g., if Alice has made less than 5 copies of file f and > today's > date is before Aug, 31, 2005, then Alice may make a backup of f). For > brevity, I'll write these statements as "c1 AND... AND cn => Perm(u, a, > s)". YES! That's what is how REL statements are actually transmitted into code. See: "S.Guth, G. Neumann, M. Strembeck: Experiences with the Enforcement of Access Rights Extracted from ODRL-based Digital Contracts. In Workshop-Proceedings of the ACM Workshop on Digital Rights Management, Washington D.C./USA, Oktober 2003. [pdf, ps, BibTex]" WE used role based access control software to formulate the ODRL statement as an access control statement in software objects. > The Model Semantics doc (dated May 16, 2005) seems to say that two > statements > in S can only differ on their action element. In other words, every > statement in S includes the same constraints, user, and asset. This > doesn't > make sense to me, so I'm going to assume the statements can refer to > different constraints, users, and assets. If I'm wrong, then I've simply > answered the question for a more general problem. (As an aside, I think > different statements in S can have different constraints if you modify the > existing model so that constraints can be in "and" and "or" containers.) Vicky. Where do you read that that two statements can only differ on their action element? That is not the case. Only every constraint is exclusively related to an asset (not two assets) and exclusively related to one action (two actions in one constraint are not possible). A constraint is becoming a duty, permission, or prohibition as soon as it is related to a particular person. Vicky. We thought about this "and" "or" expressiveness in our model in Lissabon but did not really find a nice solution. Any proposals? > > Suppose we want to determine if the statements in S imply that Alice is > permitted to copy a file f. A na?ve approach, call it ProcN, is to find > the > set T of statements that are in S and have the form "c1 AND... AND cn => > Perm(Alice, copy, f)". For each t in T, check if the constraints hold. > (I'm > assuming constraint checking is fairly straightforward. If the constraint > includes a status element, the check should be trivial; otherwise, I > imagine > a database query of some sort would determine if the constraint held.) If > all of the constraints in a t in T hold, then we say Alice is permitted to > copy file f; otherwise, we say the permission is not explicitly granted by > A. > > That's the obvious approach. What could go wrong? One problem is that we > need to be a bit careful about encoding S from A. Suppose that A gives a > group g permission to do an action a to an asset s provided that the > forEachMember constraint holds. This means that every member of g may do > a > to s. So we want S to include Perm(u, a, s) for every member u of g, > rather > than "forEachMember => Perm(g, a, s)". If g is a large group or its > members > are not known, then we can use variables and modify ProcN accordingly. I do not really understand the problem here can you state it in more detail? However, of course we can not develop all S if the members of a group are not known. We have to assume are members are know. Which would also be the case in a real implementation. > Another problem is that ProcN might not give the intuitively correct > answer > if S contains two statements whose constraints, roughly speaking, cancel > out. > For example, suppose S includes the statements "if Alice has made less > than 5 > copies of h, she is permitted to copy f" and "if Alice has made at least 5 > copies of h, she is permitted to copy f". Then we should conclude that > Alice > may copy f, even if we don't know how many times she's copied h. (This is > because we know she either copied h less than 5 times or at least 5 times > and, in either case, she's allowed to copy f.) This is not the answer > produced by the na?ve algorithm. Joe Halpern and I have outlined an > alternative approach in "Using First-order Logic to Reason about > Policies". > The conference version is online and the journal version, which is > significantly better, is almost done (please ping me if you want an > almost-finished copy). If you want to consider the approach seriously, > but > don't want to wade through a paper written for logicians, I can summarize > the > paper by giving pseudocode for answering queries and a few restrictions > that > guarantee the algorithm is relatively efficient. (I need to think a bit > about how to do this for ODRL, but I'm fairly confident that I can.) Please do if you find time. > Alternatively, we could decide that the 2 statements alone do not imply > that > Alice may copy f. In general, we could define an agreement so that a > permission is granted only if it follows from a single statement. If we > do > this, then the naive strategy for answering queries will give the correct > answer according to the definition, but I don't think it gives the > intuitively correct answer. A similar option is the one taken by XACML; > each > statement is considered individually but the parties decide how to > interpret > the results (e.g., a permission could be granted if it follows from a > single > statement, if it follows from at least 3 statements,...) That seems to be a good approach: Do I undestand that correctly: In our case above, in case the rule is "permissions are granted if it follows from a single statement" then the permission is granted. Then a second iteration may start with the rule "permissions are gratned if it follows from 3 statements." then the permission would be denied. After, the second iteration we have an indicator for statements whose constraints cancel out. The interpretation process of each individual party might decide how to deal in these cases...no? > We can easily modify the above discussion for agreements that have > Prohibitions, rather than Permissions. But what if an agreement has both? > Then we need to handle inconsistencies; that is, when a user is both > permitted and forbidden to do an action to an asset. Probably the easiest > solution is to restrict agreements so this can't happen. Alapan > recommended > an approach in this category by suggesting that agreements are redefined > so > that an agreement cannot have both a Permissions and a Prohibitions > entity. > That will work, but it seems a bit drastic. Alternatively, we could > require > that the same action name does not appear in both the Permission and the > Prohibition. Another option is to require that, if the same action name > appears in both, then the corresponding constraints cannot simultaneously > hold. For example, an agreement A could say "Alice may copy f if she has > made less than 5 copies of f" and "Alice may not copy f if she has made at > least 5 copies of f", because Alice cannot satisfy both constraints > simultaneously. It should be fairly easy to build an app that checks if > an > agreement might be inconsistent and warns the parties accordingly. Thanks for your proposals here. We need Permissions and Prohibitions in one Agreement, simply to express the CC licenses. But I like the idea of restricting on the action level, i.e. the permission "play" may not be included in permission and prohibition. Any other comments of the ODRL interest list people? So long Susanne -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse f?r Mail, Message, More +++ From vickyw at cs.cornell.edu Mon Aug 29 22:58:38 2005 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 9, Issue 7 Message-ID: <772EF7E386FEDF4FA6E11A9DA703A4D25E6F71@EXCHVS1.cs.cornell.edu> Hi Susanne, Thanks for the feedback. Having read your comments, I suspect I'm a little rusty on the language. Sorry for the mistakes. Please let me know if this is correct: an agreement between an owner po and a user pu about an asset a can be captured by a set of statements S = {s1, ..., sm}, where each s is of the form \forall x (MemberOf(x, pu) AND c1 AND....AND cn => Perm(x, act, a)), each c is a constraint and act is an action. Two elements of S can differ on the constraints and the action, but not on a or pu. Yes? If so, the problem that I mentioned with ForEachMember doesn't exist, but we have to tweak the na?ve algorithm slightly. We let T be the set of statements in S with x replaced by Alice. We thought about this "and" "or" expressiveness in our model in Lissabon but did not really find a nice solution. Any proposals? Can you give some examples of what you'd want to do with the "and" and "or" constraint containers? Do you remember which solutions were proposed and what people didn't like about them? We have to assume our members are known. Which would also be the case in a real implementation. Suppose that the Cornell library signs an agreement with the ACM. The agreement is that any member of the Cornell community (student, faculty, or staff) can print any ACM article up to 5 times. Could such an agreement be written in ODRL? If the answer is yes, what happens to next year's incoming class? At the time the agreement was made, they were not members of the Cornell community nor were their identities known, but intuitively they should be able to make copies once they join Cornell. With this example in mind, I think membership should be determined at the time a request is made (e.g., when Alice asks to copy an ACM article) and not assumed to be known when the agreement is signed. What do you think? (paraphrasing and polishing a bit) Consider the statements "if Alice has made less than 5 copies of h, she is permitted to copy f" and "if Alice has made at least 5 copies of h, she is permitted to copy f". Should we conclude that Alice may copy f, even if we do not know how many times she copied h? The intuitive answer (at least to me) is that Alice may copy f because either she has made fewer than 5 copies of h, in which case the first statement implies the permission, or she has made at least 5 copies, in which case the second statement implies permission. An alternative is to say that a permission is granted iff it follows from a single statement, in which case Alice may not necessarily copy f because neither statement alone gives her permission. Two slight modifications to the alternative approach are (1) assume that all relevant environment facts are known, in which case we know how many times Alice copied h and we can conclude either from the first or second statement alone that she may copy f and (2) allow the application (i.e., the parties in the agreement) to define when a permission follows from a set of statements based on whether it follows from each statement individually. That seems to be a good approach [alternative approach + 2]: Do I understand that correctly: In our case above, in case the rule is "permissions are granted if it follows from a single statement" then the permission is granted. Then a second iteration may start with the rule "permissions are granted if it follows from 3 statements." then the permission would be denied. After, the second iteration we have an indicator for statements whose constraints cancel out. The interpretation process of each individual party might decide how to deal in these cases...no? I didn't understand your response, so I suspect we're not together. Hopefully, my rewrite above helped. Let me reiterate the key points here. Suppose we say that a set S of statements imply a permission p iff there is an s in S such that s implies p. Then, according to the definition, the statements "if Alice has made less than 5 copies of h, she is permitted to copy f" and "if Alice has made at least 5 copies of h, she is permitted to copy f" do not imply that Alice my copy f. The permission doesn't follow from the first statement, because Alice might have made more than 4 copies, and the permission doesn't follow from the second statement, because Alice might have made less than 5 copies. In general, I don't see how we could efficiently detect statements whose constraints "cancel out" based on whether the statements individually imply a permission. I would like to create an algorithm that can be used to determine whether a set of ODRL licenses imply a permission, but I might not get to this for awhile because of other commitments. Is there a particular date by which you need to have this for it to be considered for the new release or should I just get to it as soon as possible? Best, Vicky From renato at odrl.net Tue Aug 30 13:24:38 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 9, Issue 7 In-Reply-To: <772EF7E386FEDF4FA6E11A9DA703A4D25E6F71@EXCHVS1.cs.cornell.edu> References: <772EF7E386FEDF4FA6E11A9DA703A4D25E6F71@EXCHVS1.cs.cornell.edu> Message-ID: <9561ADE3-8C1B-4035-A998-903C1EF5EF18@odrl.net> On 29 Aug 2005, at 22:58, Vicky Weissman wrote: > Can you give some examples of what you'd want to do with the "and" > and "or" > constraint containers? Do you remember which solutions were > proposed and > what people didn't like about them? > > > > In V1.1, we had an explicit XML container mechanism that allowed you to say that you have Permission X Y (not both) - by default, all Permissions were and-ed. This container was a bit messy. There seems to be 3 alternatives: 1 - Put all the options into separate Offers 2 - Link the alternate Permissions as Prohibitions - that is - You are Permitted to do X and Y, but you are Prohibited to do X if you have done Y (and vice versa) 3 - Keep the structure in the V2 model > Suppose that the Cornell library signs an agreement with the ACM. The > agreement is that any member of the Cornell community (student, > faculty, or > staff) can print any ACM article up to 5 times. Could such an > agreement be > written in ODRL? If the answer is yes, what happens to next year's > incoming > class? At the time the agreement was made, they were not members > of the > Cornell community nor were their identities known, but intuitively > they > should be able to make copies once they join Cornell. With this > example in > mind, I think membership should be determined at the time a request > is made > (e.g., when Alice asks to copy an ACM article) and not assumed to > be known > when the agreement is signed. What do you think? > > > > Yes. This is were a REL and an access control language differ. A REL should express the policy (ie any member of Cornell), and a "system" needs to dynamically check the access credentials to ensure the Policy is Ok. > I would like to create an algorithm that can be used to determine > whether a > set of ODRL licenses imply a permission, but I might not get to > this for > awhile because of other commitments. Is there a particular date by > which you > need to have this for it to be considered for the new release or > should I > just get to it as soon as possible? > > > > Whenever you can Vicky! Cheers Renato Iannella ODRL Initiative http://odrl.net From aarnab at cs.uct.ac.za Tue Aug 30 02:48:02 2005 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 9, Issue 7 In-Reply-To: <772EF7E386FEDF4FA6E11A9DA703A4D25E6F71@EXCHVS1.cs.cornell.edu> References: <772EF7E386FEDF4FA6E11A9DA703A4D25E6F71@EXCHVS1.cs.cornell.edu> Message-ID: <1125334082.1346.34.camel@iduna> > > We thought about this "and" "or" expressiveness in our model in Lissabon but > did not really find a nice solution. Any proposals? > > Can you give some examples of what you'd want to do with the "and" and "or" > constraint containers? Do you remember which solutions were proposed and > what people didn't like about them? > IIRC, I was one of the proponents for and & or containers. The example I gave used credentials as an example, but should be possible to craft other examples. Credentials could be part of the data dictionary as a constraint. Take a piece of music - the rights holders may allow for unlimited reproductions of the music if the user is: a) A student at University of Cape Town (UCT) b) An academic staff member at UCT c) A journalist from Rolling Stones Magazine using the notation you used earlier, this can be stated as: \forall x ( MemberOf(x, pu) AND Credential ((rolling_stone_magazine & journalist) || (UCT & (student || staff))) => Perm(x, copy, a)) Yes, this can be simplified to a statement using just one container, but using both an and and an or container would be more useful. Containers could also be used to define choices in rights - you can either have unlimited printing of an e-book or make a backup of the e-book once. > > We have to assume our members are known. Which would also be the case in a > real implementation. > > Suppose that the Cornell library signs an agreement with the ACM. The > agreement is that any member of the Cornell community (student, faculty, or > staff) can print any ACM article up to 5 times. Could such an agreement be > written in ODRL? If the answer is yes, what happens to next year's incoming > class? At the time the agreement was made, they were not members of the > Cornell community nor were their identities known, but intuitively they > should be able to make copies once they join Cornell. With this example in > mind, I think membership should be determined at the time a request is made > (e.g., when Alice asks to copy an ACM article) and not assumed to be known > when the agreement is signed. What do you think? > This is a scenario dependent on the ID manager rather than the DRM system itself. This scenario could easily be dealt with credentials for example - the license can be used by anyone who presents a valid credential from Cornell. However, for this to work, the DRM controller itself needs to be able to handle credentials. > (paraphrasing and polishing a bit) > Consider the statements "if Alice has made less than 5 copies of h, she is > permitted to copy f" and "if Alice has made at least 5 copies of h, she is > permitted to copy f". Should we conclude that Alice may copy f, even if we > do not know how many times she copied h? The intuitive answer (at least to > me) is that Alice may copy f because either she has made fewer than 5 copies > of h, in which case the first statement implies the permission, or she has > made at least 5 copies, in which case the second statement implies > permission. An alternative is to say that a permission is granted iff it > follows from a single statement, in which case Alice may not necessarily copy > f because neither statement alone gives her permission. Two slight > modifications to the alternative approach are (1) assume that all relevant > environment facts are known, in which case we know how many times Alice > copied h and we can conclude either from the first or second statement alone > that she may copy f and (2) allow the application (i.e., the parties in the > agreement) to define when a permission follows from a set of statements based > on whether it follows from each statement individually. > > That seems to be a good approach [alternative approach + 2]: Do I understand > that correctly: In our case above, in case the rule is "permissions are > granted if it follows from a single statement" then the permission is > granted. Then a second iteration may start with the rule "permissions are > granted if it follows from 3 statements." then the permission would be > denied. After, the second iteration we have an indicator for statements > whose constraints cancel out. The interpretation process of each individual > party might decide how to deal in these cases...no? > > I didn't understand your response, so I suspect we're not together. > Hopefully, my rewrite above helped. Let me reiterate the key points here. > Suppose we say that a set S of statements imply a permission p iff there is > an s in S such that s implies p. Then, according to the definition, the > statements "if Alice has made less than 5 copies of h, she is permitted to > copy f" and "if Alice has made at least 5 copies of h, she is permitted to > copy f" do not imply that Alice my copy f. The permission doesn't follow > from the first statement, because Alice might have made more than 4 copies, > and the permission doesn't follow from the second statement, because Alice > might have made less than 5 copies. In general, I don't see how we could > efficiently detect statements whose constraints "cancel out" based on whether > the statements individually imply a permission. > Surely, the state of no_copies must be checked at the implementation level - i.e. at the DRM controller, the license is translated to: if ((no_copies < 5) || (no_copies >= 5)) then copy f; A smart compiler could condense this down to always true; but I would not expect such features from a DRM controller. From a DRM controller, it should check the state of no_copies and then allow copy f. Hope these comments have some use. 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/ ---------- "You must always believe that you can be the best, but you must never believe you have achieved it". Juan Manuel Fangio