From Steven_Rowat at sunshine.net Tue Sep 6 04:45:43 2005 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Reasoning about an Agreement Message-ID: Hi, About Vickie's suggestions, Susanne wrote: >But I like the idea of >restricting on the action level, i.e. the permission "play" may not be >included in permission and prohibition. I agree. Although, even if this is instituted, it still may be necessary to have an app that checks for conflicts, because there may be overlaps among the fields covered by different actions. (No example of such an overlap springs immediately to mind; perhaps none will exist; but this needs to be checked carefully I think.) steven From vickyw at cs.cornell.edu Tue Sep 6 06:04:45 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 9 Message-ID: <772EF7E386FEDF4FA6E11A9DA703A4D25E6FB7@EXCHVS1.cs.cornell.edu> 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 I've never have a good intuitive understanding of the containers. If I remember correctly, the original model allowed , , and containers, where is an abbreviation for inclusive-or and is an abbreviation for exclusive-or. Suppose that X = "watch the movie twice at medium resolution", Y = "watch the movie once at high resolution", and Microsoft gives the user permission X permission Y. I think this means that the user can watch the movie three times, twice at medium resolution and once at high resolution. The user can also choose to do some partial combination of these actions, such as watching the movie once at high and once at medium. So far so good. Now suppose Microsoft gives the user permission X permission Y. This is more troubling. One interpretation is that the user can choose whether to do X or to do Y, but cannot do both. But, if this were the case, then how is different from ? Another possibility, is that Microsoft promises to give the user permission X Y, but won't commit to which. This might make sense. Maybe Microsoft's player has limited bandwidth so, when the user tries to play the movie, MS will either show it in high res (after which the user has no more permissions to exercise) or MS will show it in medium res but let the user watch it a second time at medium if the user so desires. Of course, this also seems like an rather than an , but its hard to believe a contract would say "we'll let you watch the movie once at high, twice at medium, or three times (once at high, twice at medium), depending on our mood". The bottom line is that I don't understand the intuitive meaning behind the container, at least with respect to permissions. Finally, suppose Microsoft gives me permission X permission Y. Now, the interpretations that I tried to give to make sense here. Unfortunately, there's more than one interpretation to choose from. The alternatives (1) and (2) that Renato gives in his email suggest that the intended meaning of permission X permission Y is that the *user* can choose whether to exercise X or Y. If you go with alternative (1), the user makes her choice before committing to the agreement and, if you go with alternative (2), the choice is made when the user first exercises a relevant permission. Obviously, I can't tell you which you want, and I'm not sure you don't want both. In fact, I wouldn't be surprised if you want three flavors of . In the first, the user picks an option (in the example, the user would pick between X and Y) before committing to an agreement. In the second, the user picks an option when she wants to execute one of the relevant permissions. In the third, the owner/manager of the asset picks an option at the time of execution, probably based on the current environment (e.g., system load). Note: there's no reason to have the owner make a decision at the time of the offer, since in this scenario, the owner could simply tailor the offer to her preference (in the example, the owner might offer x or might offer y, but wouldn't create an offer that had the two permissions xor-ed). In summary, I'd keep the container and see no reason why it shouldn't be the default. I'd remove the container, because I don't understand it (lets not think about what that says about me :). And, for maximum flexibility, I'd replace the container by 3 flavors of , which amounts to allowing an offer to be an of offers, a permission to be an of permissions or an of permissions. Note that I'm assuming the is the user's choice unless otherwise specified. 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. I like your examples. I think the first example shows that the container makes intuitive sense for some entities (in particular, constraints). This suggests that, to determine which containers should be in ODRL, we need to consider each entity individually. Also, if ODRL includes for constraints, I think the document should note that the is essentially an abbreviation. As you point out, we don't need to make the statement but, by using , we can capture the idea in a shorter statement that is arguably easier to read. The second example, together with the first, highlights that we need to be careful with and . Notice that in the first example, you talk about an "or container", meaning inclusive-or. (I'm assuming a staff member who is also a student and consults for Rolling Stone can copy a). In the second example, you again talk about "or", but here mean an exclusive-or. (I'm assuming I can't both do unlimited printing and make a backup.) > (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? 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. I think you're assuming that the value of no_copies is known at the time of the request. If this is the case, then the na?ve algorithm that I suggested should work just fine. More generally, if we assume all possibly relevant facts are known at the time of evaluation, then I think the algorithm gives the intuitively correct answer. But suppose the value of no_copies is not known. Then I think a na?ve DRM controller will not grant the permission, thus giving an intuitively incorrect response, because neither (no_copies < 5) nor (no_copies >= 5) individually evaluates to true. -Vicky From aarnab at cs.uct.ac.za Tue Sep 6 18:29:09 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 9 In-Reply-To: <772EF7E386FEDF4FA6E11A9DA703A4D25E6FB7@EXCHVS1.cs.cornell.edu> References: <772EF7E386FEDF4FA6E11A9DA703A4D25E6FB7@EXCHVS1.cs.cornell.edu> Message-ID: <1125995349.10113.21.camel@iduna> > The second example, together with the first, highlights that we need to be > careful with and . Notice that in the first example, you talk > about an "or container", meaning inclusive-or. (I'm assuming a staff member > who is also a student and consults for Rolling Stone can copy a). In the > second example, you again talk about "or", but here mean an exclusive-or. > (I'm assuming I can't both do unlimited printing and make a backup.) > I did not consider the case of vs and I agree that it does make sense to consider that application. In the example above, I had meant an situation. In this case, it makes sense to have all three logical operators, and interpret them as defined by traditional boolean algebra. > > 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. > > > I think you're assuming that the value of no_copies is known at the time of > the request. If this is the case, then the na?ve algorithm that I suggested > should work just fine. More generally, if we assume all possibly relevant > facts are known at the time of evaluation, then I think the algorithm gives > the intuitively correct answer. But suppose the value of no_copies is not > known. Then I think a na?ve DRM controller will not grant the permission, > thus giving an intuitively incorrect response, because neither (no_copies < > 5) nor (no_copies >= 5) individually evaluates to true. >From an implementation point of view, surely the value of no_copies is known to the DRM controller (as it is a required function of a controller to keep track of state), and if it is not known (maybe because this is the first time the license has been used for example), then a default value (0 in this case) should be used? 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 From Steven_Rowat at sunshine.net Wed Sep 7 02:46:03 2005 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] OT: Micropayments for digital downloads introduced by Paypal Message-ID: Hi, This not directly ODRL 2 related, but since it pertains to the sale of digital material on the Internet it may be of interest to others on this list; I found it so. Paypal has just (Aug 31) introduced a new micropayments pricing system intended for digital downloads, such as music. See: http://www.shareholder.com/paypal/releaseDetail.cfm?ReleaseID=171765&Category=US The new pricing is 5% and 5 cents per transaction. This may be a watershed change, since the previous was 2% and 30 cents. The new system means the abililty to sell digital items for as little as ... 15 cents? 10 cents? - and still be making a good profit margin. It looks like the Internet is ripe for ODRL. I hope not overripe. :-) steven rowat From renato at odrl.net Wed Sep 7 14:31:17 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 9 In-Reply-To: <772EF7E386FEDF4FA6E11A9DA703A4D25E6FB7@EXCHVS1.cs.cornell.edu> References: <772EF7E386FEDF4FA6E11A9DA703A4D25E6FB7@EXCHVS1.cs.cornell.edu> Message-ID: On 6 Sep 2005, at 06:04, Vicky Weissman wrote: > The bottom line is that I don't understand the intuitive meaning > behind the container, at least with respect to permissions. Vicky - you are correct. does not make too much difference for permissions but does for constraints. > The alternatives (1) and (2) that Renato gives in his email suggest > that the > intended meaning of permission X permission Y is that the > *user* can > choose whether to exercise X or Y. If you have an Agreement with an in it, then we have assumed that the end user party will make the decision. For example, Vicky assigns the following to me: I then choose to , then I cannot . > In summary, I'd keep the container and see no reason why it > shouldn't > be the default. Yes, and it is the default. > I'd remove the container, because I don't understand it > (lets not think about what that says about me :). And, for maximum > flexibility, I'd replace the container by 3 flavors of , > which > amounts to allowing an offer to be an of offers, a permission > to be an > of permissions or an of permissions. > Note that > I'm assuming the is the user's choice unless otherwise > specified. Interesting. We will need to see how to model this (in UML) and if this is giving too many options (= harder to implement!) Cheers Renato Iannella ODRL Initiative http://odrl.net From vickyw at cs.cornell.edu Fri Sep 9 00:24:32 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 10, Issue 2 Message-ID: <772EF7E386FEDF4FA6E11A9DA703A4D25E6FC6@EXCHVS1.cs.cornell.edu> Hi all, Just a quick note in response to Alapan's. Alapan writes: From an implementation point of view, surely the value of no_copies [an environment fact] is known to the DRM controller (as it is a required function of a controller to keep track of state), and if it is not known (maybe because this is the first time the license has been used for example), then a default value (0 in this case) should be used? In response, I don't know what the design criteria is for the DRM controller. Is this written somewhere and, if so, could you point me to it? If the controller really does keep track of the entire state, then we should be able to assume that the environment is known and a fairly na?ve algorithm should be sufficient to evaluate queries, such as may Alice copy file f. Put another way, how I would recommend we evaluate queries, such as may Alice copy file f, depends on whether we assume the complete state is known (or, at least, all relevant facts about the state). So could someone tell me definitively if we're making this assumption? I can't speak with confidence on whether the assumption should be made but, for what its worth, here are the pros/cons that I see. A benefit of having the entire state accessible to the controller is, as I've already mentioned, that it substantially simplifies the task of answering queries. One disadvantage is that the controller has to keep track of the state, which increases its overhead. We could address this issue by having the user submit a request along with all relevant facts needed to get the permission (think SPKI/SDSI). This is good, because the controller doesn't have to store the information, and this is bad because the user needs to know which documents to submit, the user needs to have these documents (possibly getting them from third parties, there could be privacy issues here), and there might be more of a chance for forgery if the user holds the credentials. This approach also restricts us to a world where a fact about the environment can only add to a users set of permissions. For example, few people will submit a credential saying "I have a history of not paying my bill". Obviously, we could have a split approach where the user keeps some facts as credentials and others are stored with the controller; thereby, reducing, though not eliminating, the overhead. Another concern has to do with the robustness of the system. Suppose the controller is keeping track of the state, but for some reason this information is unavailable at the time a request is made (maybe the network is sluggish, maybe there's a denial of service attack under way, maybe there's a reason to believe part of the database has been corrupted,...), then we'd like the controller to function as well as possible. A similar argument holds for the poor customer whose system is infected with a nasty virus that destroys some of her credentials. Now, if we don't depend on the state being available, the controller might work better (and, at least, will not work less well) in these, hopefully atypical, circumstances. Of course, it's not clear how much better, so maybe this shouldn't be a significant concern. -Vicky