Apr 22, 2004
Rigo Wenning, W3C/ERCIM Sophia Antipolis, France
DRM and the Web
ODRL has chosen not to go with one side or the other side, and it has to keep with that in order to have success.
Expectations
The EC IST says that the lack of DRM is a roadblock to the information society. Yet, by contrast, iTunes works - so is the lack of DRM really a roadblock? Industry says piracy is the reason for bad business - but perhaps it is bad product. So set the tone - perhaps those first ones are not really the problem.
I don't want to talk about pseudo-issues, like piracy. I want to talk about real issues, like privacy. Also, does DRM integrate well with other products? Reuters, for example, has shied away from DRM because of lock-in. The big vendors came to the table and said, oh we have this great version. But six months later they came out with the next version, and the first would not work. So they shy away from solutions that are not interoperable. They want to be able to change their DRM scheme.
The War is Still Going On
We have heavy lobbying with every government in the world to preserve the ancient business model, the old business model, where they have tangible good and they sell you tangible goods, and if you want two at a time, you have to buy another one. They want to move this model into the digital arena, but enhancing it to make a bit more money.
By crying parisite for years, they have created an erosion of the exceptions to copyright, including the prohibitions of circumvention mechanisms. Also, there is peer to peer, with an innovation circle of about six months. But it is becoming more sophisticated and more closed, because of broken content. Now there is signed content, from people you trust. But signature and trust is nothing more than metadata in a P2P system, and DRM is nothing more than metadata.
As long as the war is going on, there is fear, uncertainty, doubt. What works today may not work tomorrow - it depends on who gets power. They only way out is to use application semantics, say, 'I have my business model, it works this way.' It doesn't really clash with the law, but it sort of ignores it. This sets us up for conflict.
ODRL?
What about ODRL? It is a framework, that expresses semantics. It is not tied to a particular application. But that doesn't mean it does something useful (it doesn't mean it says something meaningful). In the presence of uncertain semantics, you get uncertainty, but a framework doesn't give you semantics. You need a provide; you need to attach meaning to the terms. Perhaps in this workshop you might want to start talking about application profiles and use cases, give model source code, model workflows to users.
I have to be severe with Renato - missing semantics! There are missing semantics in ODRL. For example, it is missing the logical NOT! True, NOT can be expresses with AND plus OR, but it gets more complicated. For example: try to encode this sentence in ODRL: "You can do whatever you want with my work, but if you make money, I want 15 percent." That gets to one mega of DRM to specify that.
The problem is, in ODRL, any right that is not granted is forbidden, and you can't say NOT NOT to say yes. In fact, the more constraints, the simpler the expression in ODRL. What is needed is some sort of wildcard. Creative Commons is very simple.
The Web
We have to work with both sides in the war. Interoperability with MPEG-21 (XrML), interoperability with Creative Commons. Creative Commons is one side in the war - what they offer is what they think are 'normal protections'. Somebody has to sit down and write XSLT to translate ODRL into MPEG-21 and CC.
It is still difficult to integrate any sort of DRM into HTML. It would need some sort of binding mechanism (like PPP) to define the scope of what it is trying to express. It would bind DRM to HTTP (URI).
ID Issues
One of the splits at the W3C DRM workshop was the identification of objects. Is DOI still active? Can you distinguish between objects? DOI has done a registration system, and you have to pay money, and they provide you with an identifier which identifies other representations of the same object.
Privacy
Privacy was a big issue in the W3C DRM workship, especially in the area of enforcement. It has shifted after September 11. We have shifted, from frivacy as a business issue to provacy as an anti-government issue. Privacy may be solved if you can use P2P with DRM - but then the engines have to figure out the right semantics.
We have done that for the web service part. In this area, we have developed a generic PPP attribute that you can mix in with the XML. It would allow ODRL to just plug privacy in.
Web services is the modern word for remote procedure control, which was invented in the early 80s. At W3C we see that the human interface of the web is done, more or less, and now we want to do machine interface - web services and the semantic web. You will need DRM for this - you ask whether a system can provide the services you want.
WSDL and SOAP have a specific error mechanism that could be used. If you don't understand something, you have to throw away the request (architecture level security). This could be used for DRM.
ODRL and Web Services
ODRL is not a defining protocol but contains a binding - you may want to use this as a starting point for integration into web services.
DRM and P2P
They sound like natural enemies. But it isn't. You are playing with psychology here. It's like a minefield - one wrong step and you're blown away. Today in this war you have those opposite camps that don't talk to each other, they just shoot at each other. It's very hard to start talking, about, like, DRM in Peer to Peer members.
ODRL and P2P
So keep away from good/bad paradigms. They bring you to one side of the wall, which is one side in this war. That's what we said three years ago about the library thing. Give the people the opportunity to do the right thing, the profile of how to do the right thing. ODRL is much more fine-grained than Creative Commons. But you have to lower the barrier, have much lighter constraints.
DRM and Exceptions
We don't talk about library privileges any more today because we are talking about an industry going after schoolchildren in the schoolyard. We are losing our history. When I was a schoolchild we would exchange casettes in the schoolyard. We are losing this. There is no such system for MP3s. We have to find a solution to that.
I hope for a revision to ODRL.
http://www.w3.org/Talks/2004/04-odrl
Comments
--------
Gustaf Neumann: There are other frameworks that express the things ODRL is missing. For example, RDF. There is a very high overlap, with a very strong community.
Wenning: The fact that you talk about semantic web identifies you as academic. When you ask what is the XML is a tree structure, RDF is a graph structure. You can mix languages together much more easily than in XML. There's still work ahead - when you talk about inference schemas, there is a whole community. There is no standardized inference language. So, there is room for integration - in PPP we have provided an RDF integration. So people speak in angle brackets - you take the work and you put angle brackets around it. They think they understand what that means. So we have shown how to do PPP in RDF.
Lars Gunnarson: You talked about covering both sides in the war, and about the minefield. Technically, it's possible to find solutions. But in a minefield, this might t=not be feasible because of patents, so you might not be able to use it.
Wenning: W3C has killed every patent so far. The idea of claiming a patent, to write a rights language - put it to the test. It means, only we can create DRM, nobody else. We can't work like that. You have to find the position of ODRL in all that. You have to find the needs, and decent solutions to those needs. How can you provide that with out being this make-money task monster. This isn't seeing the movie before it is released - the piracy is becoming professionalized. Microsoft got big because they were copied like hell. In the 80s, everybody had a copy of Word. You have to adjust the business model. You have to think of how to make a viable business model where money can flow. People want to do the right thing but they can't.
Suzanne Guth: The NOT. Creative Commons had an opposite solution? How was it solved in other languages?
Wenning: This is the central sentence: a permission that is not specified in any rights expression language is not granted. Today, we know that this is just crap.
Ianela: But they just have a term, 'you cannot redistribute'. It's not a NOT.
Wenning: That's why ODRL needs a wildcard.
Guth: You were talking about use cases. The use case that is most obvious is access control. 'You may access something or you may not access something if...' How do you do access control if you do not have the explicit rights.
Wenning: Right. I know this trap, I was in it six years ago. The natural aggregate status of information is 'flow', not 'halt' but flow. I look at this building, I can see it. Access control, making an obstacle to this flow, is something articifial. We have some law, some copyright or patents. Access control - once I give it out I can't get it back again. But there are many many ways of access control.
Oyvind Vestivik: If you turn this around, then you would have lots of exception statements, you would have to code every one of them.
Wenning: But that is the natural way of things. You would have to specify every exception in the law, as a default. It is a lot of markup that is just default. In copyright, you have a very good situation, since the Berne convention exists since 1988, and even the U.S. has joined. It is quite unified.
Beumann: It was like this. It is changing. There are many new laws now.
Wenning: Yes, if you look at the details, you get lost. But if you look at the big principles, they are almost everywhere the same. The type of it. In privacu, I have seen. some 60 or 70 models of privacy protection. You can't.
Guth: In ODRL, you need a not, but this NOT would have to be met by whatever is processing this language.
Wenning: How to map the NOT to access control - it becomes the wildcard.
-------------
A Pervasive Application Rights Management Architecture (PARMA) Based ODRL
Ivana Dusparic
In pervasive computing - such as in mbile phones - applications are only occasionally connected. Current DRM applications for mobile computing are not flexible enough. For example, there is no pay-per-use, no feature-based model. Also, in DRM we check the user's rights before - but with applications, we check the rights during the use.
Traditional application rights management - some standards already exist. Eg., a rights server exists, there are, say, 20 licenses. When someone uses the application, the license is obtained, and it is returned when the application is no longer used. The call to the license server is inserted into the application code. That's really cumbersome, difficult to maintain, and requires knowledge of the API and programming knowledge as well.
There is a standard that is proposed that does this, XSLM, but it has not really been adopted so far. And it is fairly old, proposed in 2001, so if it was going to be adopted it would already have been. And this didn't propose any soilution to the feature-based model we are trying to implement. Also, we can't assume connectivity, so our system cannot be connection-based.
Insetad, we opted to use a rights expression language. The current system that's used in mobile phones is OMA DRM 1.0/2.0, which works fine for content these days. However, it does not do the job for feature limited systems. ODRL, which is a broader specification, had a couple of features we needed, such as integration with payment, and the notion of parties involved in payment. There is a central vendor server, and we also wanted to support enterprise licensing, so in between there is a server hosted by the enterprise, so we wanted to specify who these users were.
We extended ODRL to implement the feature-based system that we needed. I won't detail exactly what we added, but we needed to add RightsType, which is based on the user, the device, whether it is pay-per-use (real-time or audit-based, time-limited, feature-limited, named user). The audit-based model doesn';t require connection to the server, but the use of the application is stored on the device. We needed to specify the data that needs to be saved to be reported back later.
(Discusion of the distinction between Objected Oriented Programming and Aspect Oriented Programming (AOP): Basically, AOP adds rights management code into the original code without modifying the original source code. Thus, the original source code does not need to be available.)
An enforcement architecture was also created. When licencing code specifying an aspect interrupts execution of the code, it makes a call to this container, which in turn describes the user's rights - what they are allowed to execute. It authenticates the user, and if we are auditing, it interacts with secure storage (to save use information). We are using only the 'execute' permission from ODRL. The majority of license check is done in this container, though from time to time it connects with the server (the enterprise server or the vendor server). These servers use WSDL interfaces.
----
Interoperability between ODRL and MPEG-21 REL
Jaime Delgado, et.al.http://dmag.upf.edu
We are talking about multimedia content - audio, video, whatever, on which we handle the digital rights issues. We need to look at identification, description, coding and business models that imply different ways of distribution. Once we consider DRM in this context, we deal with different aspects: protection, such as copy protection or watermarking, information representation such as metadata and rules, and the negotiation of the rights, agreements, and how to express contracts, and finally, control. In one word: the management of digital rights.
What we are focusing on is standardization - that is, information representation. As you know, there are different languages - such as ODRL and MPEG-REL - and there are other languages and parallel initiatives. Taking all this into account, we will focus on ODRL and MPEG-REL.
MPEG has a long history for the encoding of sudio and visual information. Then MPEG-7 is metadata, and MPEG-21, which is digital rights. There are 16 parts open on MPEG-21 (every meeting there are new parts added - you are putting in everything you know). The main parts: parts 4 (IP management), 5 (rights expression language), and 6 (rights data dictionary). There is a need for an architecture that clarifies all the parts of the standard. It would be in part 4, which is now only at the requirements stage, or in part 10 (Digital Item Processing).
We are interested mainly in Part 5. Four elements: Principal, Right, Resource, Condition. The basic MPEG-REG element is the license, which contains one or more grants, and the license issuer, who gives the grants. MPEG-21 REL levels include the Core schema, extension, and multimedia extension. The rights are not really defined in the REL itself, but in a dictionary associated with the REL (Part 6). This system (RDD) includes a set of attributes with definitions. It is a complex structure with a lot of rights and a lot of relationships. This doesn't mean that the semnantics are established - you can have external meaning determined by external organizations.
The ODRL has three elements: right, party, asset.
Similarities: both are XML, both conform to Stefick's axiomatic principles of rights modelling.
Differences: different syntax and elements. ODRL is simpler; MPEG-REL has many options. And MPEG-REL works with an independent rights element dictionary.
(chart of equivalencies) - see slides
Strategy for Interoperability: transforming ODRL into MPEG-REL, or vice versa. This is the transfer of one XML document into an other. The is the only thing you have to do. So we 'just' need a language to transform.
There are two approaches: one is to use a program in C or Java, or to use an XSLT. We use XSLT. It is oriented to XML interaction, it is simpler than developing a program in C or Java, it is well-equipped for this purpose.
So we have to develop the XSLT. (transformation example from presentation).
We have implemented some tools based on this principle: first, a license creator, and second, a schema checker. So we have tools that work in MPEG-21 and in ODRL. These can be used to develop DRM-based applications. The information is generated by a web form, a servlet checks against the schema, and the license is generated.
Future work will be the adaptation of tools in MPEG-21 to ODRL, especially in the ontology part. This is useful for developing complex applications, where you need to get the semantics of something. We are developing mechanisms for license interpretation, with reference to the data dictionary. The tools will determine whether you can do what you are asking - you can play, not play, and so on.
Also, we developed some time ago in the IPR domain an ontology - working, not at the syntactic approach but at the semantic approach. It describes OPR contracts, actors, creations, rights, etc.. It has different views - a statuc view and a dynamic view.
(Diagram of IPROnto from presentation: static, dynamic)
The next step is standards-based o ntologies - why not formalize using semantic web mechanisms?
Comment: I am surprised that the XSLT is only one page. Is the expression correct, that the two are speaking about the same thing, but only have syntactical problems.
Reply: To have the application ruinning, you have to supply use case specifications. In an actual application, these would be much more complex. This is only to show that in a basic case, it works very simply.
Comment: attempt to map LOM to RDF using XSLT failed miserably. Why do you think this will work here?
Reply: This is different; the conceptual structures are the same. If you are talking about RDF then the concepts are not the same.
Comment: So it is ridulous to try it with RDF?
Reply: Exactly.
Wenning: No no no. This is just at the syntactical level. But if we can provide its own schema language in XML. XML is in a tree structure. RDF is a graph structure. You can use the graph to produce a tree (not the other way around). That's why RDF is a superset of XML, semantically. When you fail to transform XML to RDF, this is not a failure of the concept.
Comment: Did you find ODRL expressions that could not be transformed? Because if not, then the two langauges are equivalent, which would be a very deep result.
Wenning: I cannot confirm this.
Ianella: Undoubtably you will find features in ODRL not in REL - for example, inheritance. So you could not do a transformation. Perhaps in REL there is another way to do it. So it's pretty clear that there will be some transforms that can't be done.
Roth: did you use the ontology to make the mapping?
Reply: No.
Roth: So the mapping only works for very simple models. We tried to find a general data model behind the two languages. ODRL <=> data model <=> REL. But I doubt that you can have more than simple license from one language to the other.
Comment: that is always the case. The mapping has to be semantic. English to French, for example. If you don't have that, it is impossible to map one to the other.
Comment: what do you do in a case where you find that there is not an equivalent in the other language? Do you cut it off?
Roth: We talked about this yesterday. We need standardization in terms. A standard vocabulary for descriptions of learning resources. We do not have a standard vocabulary for permissions. We need an independent organization for terms that you can use in one language or the other.
Delgado: This is the approach of the data dictionary.
Roth: They are doing this approach, where they are trying to define a common vocabulary.
Wenning: I am really wondering how MPEG wll develop the data dictionary. They are near the wall there - there is nothing to plug it into. The decisions made here are completely opaque. Like in the translation you do here - the decisions you made are not visible to the user. Without that, there is no comprehension of others.
Delgado: when you use the work 'you' I am not implying someone. We have not participated in the specification of the standard. We are working on the standard as it is.
----------
Oyvind Vestavik, Norweigan University of Technology and Science
REAP: A System for Rights Management in Digital Libraries
The challenge for digital libraries: traditional libraries have served as society's common memory, maintaining information and making it available for users. The internet is doing much the same thing, but creates a challenge, because users must judge whether it is trustworthy, and it is not maintained.
We want to combine these: ease of access, credibility and maintenance. Here is where DRM comes into play. Traditionally, information has been placed in books, which has protected information, because you can only make so many copies. Such protection is not in place for digital materials.
REAP is access control, granting or denying access to right over material published on a server. It is not aimed at rights management over the entire lifespan of digital material - for example, it does not support accumulation of rights - it is just focused on the library as a server and the client who access the material.
What is REAP? A model, a rights expression language, which is a profile of ODRL, and it is prototype software - a set of servlets running on Tomcat used to grant or deny access to material. It is not a production solution, but it does create a step toward creating more adequate solutions.
(Diagram from presentation)
The Alexandria Digital Library is a distribution of software that can be used to create a node. To such a node you can connect a client. You can use the client to search for information, which is distributed to the local node. The local middleware collects all the search results and presents an access report. This contains information about how to retrieve material that is stored in REAP.
Using this architecture, you can create an agreement, retrieve the material, and create a ticket to access material specified in the agreement.
The rights language is, as mentioned, a profile of ODRL. As an alternative, we could use full ODRL with software that understands and acts on all conditions allowed in ODRL. The advantage of ODRL is that people are familiar with it, and rights expressions accumulated in a value chain can be used. The advantage of using a profile is that the profile can be targeted to a specific application.
The rights expression language only supports usage rights (not re-usage rights), that is, display, print, play, execute. For simplicity, I have cut out the entire security model. I don't support revoking of rights - once an offer is made, it is there forever. And there are no utility constructs - don;t support containers, expression linking and inheritance. So now the language is quite simple, limited to paying for access to rights.
Another change is to use a custom identifier scheme, called reapid, instead of DOI. I am not interested in specifying the location of the material, because that is contained in our system. Inside my software there is a quite simple translation mechanism which translates ID to location.
One problem is that the system writes to an agreement after the agreement is made, to, for example, to record the uses or executions of a specific resource. This should not have been recorded in the agreement, it should be recorded in the user's profile or something.
Limitations: there is no support for re-negotiation of agreements. There is no control over material after it is delivered to users. It assumes material is contained in a single file. The user cannot influence the rights being offered, so using terms like 'offer' and 'agreement' are a bit misleading. There is nothing stopping providers from making offers that violate the rights of users (but this is not a property of the system). And it limits the possibilities for users to challenge copyight.
Although REAP issues, I think we have shown that digital materials can be published without violating (owners' rights).
Comment: Downes: Interoperability?
Reply: Access the system using the URL that I talked about. There is very little support for interoperability.
Ianella: No room for negotiation? I liked the ideal of a user saying, "What about...?"
Reply: Yeah, but is it possible. Every time it was requested, they would have to go in and negotiate with a customer.
Ianella: Comment: well, when teo humans negotiate these rights, there is give and take.
Reply: It would at least provide a more flexible solution. But if you add this flexibility, you add a lot more complexity.
Luoma: There is eBXML that does this
Ianella: We don't have to do this in ODRL.
Wenning: We abandoned this in PPP, it gets so complicated.
Reply: If you look at digital libraries, you have larger agreements. I think librarians would be reluctant to hand over the negotiation to automatic systems anyways.
Luoma: people familiar with ODRL can create agreements.
Reply: People who are providing material. Maybe 15 people, now.
Luoma: could you put the ODRL in a form where non-experts could create offers.
Reply: Yes, with a tool.
Ruth: there are tools that have been developed.
---
Flexible DRM: Real-life ODRL Implementations
VirtusosMedia, the Netherlands
We protect rights-owners business, with a focus on multimedia, open standards, multiple platforms, our own small-footprint payers, providing complete end-to-end protection.
Three solutions: multimedia protection for Bouwbox Digital, protection for VirTunes, set-top box for Virtiq Technology.
Bouwbox: is a subscription-based service, content is offline (eg., CD-ROM or DVD), with online retrieval of permissions and offline payback. It retrieves statistical data which is returned to the provider to see which of the movies are most popular. The system is ready for online content if the bandwidth is available.
VirTunes: contract with the Buma/Stemra societies, online content, no subscriptions.
Virtiq: Combined DRM and secure payments, both subscription based and 'impulse' based, online retrieval of permissions, streaming or recorded playback.
We had a subscription based system, but we wanted to move to impulse based, but our DRM couldn't cope with it. We also wanted music downloads where people didn't have a difficult contract, just a download that could be played easily. Criteria: Flexible, connectable, extendable, multiple contact areas.
Uses a broker: content is added to the system, information is provided to the broker. The broker contacts the playback device, then the content is streamed and downloaded to the system.
The rights expression describes permission to playback content, where and when, decryption info, payment, and statistics information. This system defines a new entity - contract - such that the content is combined with the contract and obtains a personalized agreement. This system is more natural and easier to maintain.
Why ODRL? The basic idea is the same. We looked at XrML, which looked rather more complex than this, and we wanted the ability to add more parties to the structure, not just the producer and consumer. Also, it is open, and therefore may allow more applications. It is easily extendable. And it gives us a faster time to market.
Wenning: Did you implement right of first sale?
Reply: if you actually bought it you are streaming it. Also: licensing. You have your license in your secure container on your PC.
Dahlem: How much of ODRL have you used.
Reply: well, not printing... We have tried to limit subsets.
Gunnarson: How do you let users preview before you buy.
Reply: we set up a website, you download our player, you click on a link.
Wenning: if you do it this way, you own both the server side and the client side.
Reply: one of the requests we get from our customers is that they want their own player. The protocol we use is proprietary, but the language we use is ODRL. It's not completely open, I agree.
Wenning: There were so many attempts to own both parts of it, since 1997 or so... That's why I've so critical of people playing both ends.
Reply: I don't see how you could go around this.
Wenning: When you stream media, do you stream MPG, do you stream Ogg, how do you protect it.
Reply: because it's encrypted.
Vestavik: It's a question of first sale dogma, and what constitutes a copy. There is a difference between streaming version and content version, which is how nice I am to the content provider.
Downes: Who are clients
The content providers.
Why choose this model
Well, do you have a problem
Yes, I wouldn't use it
Wenning: that's what I was getting at with question about API
Reply: we are looking at it, but there is not really an incentive within our company.
-----
Mariemma YagueWe focused on flexibility and extensibility, we wanted to cretate a general framework, a scalable platform where rights enforcement involves an access decision subject to intellectual property rights.
Current access control methods are not appropriate for DRM because normally they apply to locations instead of resources. For this reason the first thing we focused on is a new access control scheme that is fully distributed and scalable. When a new resources is added, the policy is automatically applied.
A DRM system must also deal with digital content protection. One mechanism converts unprotected content into protected content. We achieve extensibility and scalibility by the separation of responsibilities. It is interoperable, with an access control scheme. Also, we have what we call 'persistent protection'.
Security considerations can be met is we can ensure that the software running the content is protected (trusted). The DRM system using distriubuted access control is based on semantics - 'Semantic Access Control' (SAC) using a set of metadata models. There is a mechanism for the semantic application of a PMI.
(Diagram from presentation)
The system converts content into 'protected content object', which may be freely distributed without protection. This provides robust protection against attack. The second component is the semantic integration, which describes the certificates issued by the external entity. This specifies the access criteria and enables the semantic validation of the policies.
The semantic access control (SAC) is increasingly abstract, separating the location of policies and resources. We have different data models at the different levels of the semantic web.
For the mobile content objects, the client must have the policy in a secure compartment in the client machine (in a coprocessor, in a smart card).
For example: e-news. We selected this application because we have many elements each with a low value. We can establish access conditions, for example, you can see this news three times. If you don't pay, the only information you get is the contract.
We have implemented this in different areas. It supports pay-per-use and pay-per-acquisition. The access control is based on the semantics of the resources and not the location. There are access controls for each piece of information. No subscription or identification is needed.
Future work: we will expand the permission language, to include new DRM functions in the EC-Gate infrastructure.
Comments
Wenning: It's like before, you own both parts of it. You make your proprietary protocols, and then you can move mountains. The problem with such protocols is that you don't have an installed base. But 99 percent of solutions have failed because people don't have a smart card with them.
Reply: this new language was created because our approach is very different from the preceding. We used XML instead of RDF because we needed the inference steps, we looked for an inference engine for RDF and (in 2001) we didn't find one, so I had to do it myself.
Hockx-Yu: are you familiar with Shibboleth? Grants access based on attributes rather than identity.
Reply: the use of attribute certificate is not new. The difference is in the semantics: we have semantically described all the components of an access control system.
Hockx-Yu: the point I'm trying to make is that Shibboleth is a completely open system. I was just wondering if yoiu had heard of it.
Comment: what do you mean by semantic access control, and how is it new?
Reply: the fundamental is semantics, expressed using metadata. We have defined XML schemas expressing properties of resources: the type of resource, everything that could influence the access control criteria. You can see which properties this object has, and decide which policy is going to be applied to the resource.
Wenning: you can have a resource that has different properties, depending on how your preferences are set. This is the concept of resource rather than file location.
Reply: Right, it's the dynamic application of policies to resources. We get a higher level of protection. We make the access control criteria based on properties. For the type of content that fulfil this condition, have these properties, you have to apply this policy.
Comment: There is substantially nothing in access control that I do not know. This approach was described in a paper two years ago. What is the new thing that you are doing?
---A Proposal for the Evolution of the ODRL Model
Susanne Guth, The Vienna University of Economics and Business Administration
Motivation: from the beginning was to somehow process ODRL instance or rights expression language instances in general. The main application of rights expression or process will be probably in access control. If a person has over 1000 resources there must be some access sontrol. We wnated to do it with ODRL. We did a prototype ODRL rights expression language interpreter, and we wanted to express common business terms in access control.
We ended up finding some shortcomings of ODRL. We have the three main elements: party, permission, asset. Some party has a permission on some asset. Then, in ODRL, we have something that is able to narrow the permission: condition, constraint, requirement. For example, the permission could be 'play' and the constraint would be 'five times'. Then there is another element, the rightsholder, and when you have this element, you can have royalties and agreements.
Usually a contract defines rights and duties for the cointract parties. You can define rights and duties for the consumer, but you can't do this for the selling party. The consumer has a duty to pay five Euros, for example, but what about the vendor? Someone may assume that the vendor has the duty to deliver the content, but it can't be specified.
Additionally, there is also a distinction between the rights-holder and the consider. But what if you want to express, say, a barter? There is no monetary transaction, but there are permissions exchanged.
The third point is that you cannot constrain requirements. For example, if the requirement is that you pay five Euros, you cannot constrain it, for example, that the payment must be made by next week. This is a common condition.
Another point is that the term 'permission' in ODRL is very different from that in the access control community. It is only an operation that can be performed. But in the access control community, it is a combination of operation and asset. Usually what you need for your system is the constraint on the permission, that is, on the total operation-object.
Finally, gthere are the three different types of condition in ODRL, but every condition could be formulated as a constraint. So we do not really need the condition element in ODRL.
We have a proposed information model. You still have the permission that is related to the content party, but it consists of operation-object. Duties exist, but may be applied to any party. And constraints can be assigned to permissions as to duties. We do not have the condition element any more. The 'requirement' element is a new element that has been added. Contracts have rights and duties, and we tried to model this here.
Proposed Changes:
New duty element: replaces the requirements element and allows for constraint.
Revision of the permission element: operation, object and beneficiary element added, as well as the granto attribute.
New constraint element: the condition and constrain element have been consolidated.
The rightsholder element has been removed. Royalties are now presented by the permission and duty elements.
Downes: why join operation-objects?
Reply: Why do you need this?
Downes: You apply the description of the rights in the description of the object, not in the rights.
Wenning: this is the question of the binding. It is the trickiest area. I don't think this is the solution. It doesn't apply to use cases like dynamic application of permissions.
Reply: you can give permissions to an object that is only defined by its role.
Ianella: you talking about what is the final thing that is generated. One minute before, it can be unspecified.
Wenning: but if you can transform it, you can't sign it. You can't have something that says it's on the HTML page. It's on the HTML page it is applied.
Ianella: in an HTML file, you can link to a third file. But you can't link to any other.
---------The OPERA Project: Interoperability of Digital Rights Management (DRM Technologiez)
Andreas Deppe, T-Systems, Germany
The opera project doesn't deal particularly with rights expression languages, it has a wider view. You have domains: the content owner domain, and you have the Enduser domain. What opera is doing is we try to focus different views of license management. If you look at B2B, for example, you have different views of managing for a shopkeeper. It is not possible to manage all these views in one system. You need many things, more than you can need in one end-user device.
Principles: for the vendor, make it as flexible (or complicated) as possible, put everything you can imagine into a right slanguage. But for the user, make it as simple as possible.
So we wanted to take a jump back and take a global view of things. The Opera project does not use any DRM language, because it wasn't the focus of the project. We started by gathering requirements from platform operators, from users, and content providers. With this gathering, we see that there are deep differences in opinion.
For example, for platform providers, there is the need to display different content types, for example, DRM-enabled Adobe PDF, etc. Then, of course, I need a multi-client and multi-system infrastructure, because I want to do content syndication. There is a need for different access models, accessibility and usability.
From the view of content providers, their reaction was not enthusiastic. Their problem was in getting their content on our platform. They wanted open systems, secure decoding and decryption, scalable protection, so that more valuable content is more protected. They want DRM to work in disconnected enviroments, multiplatform and multi business models.
End users wanted ease of use, a transparent and visible system. For example, if something stops playing after three times, the user is disappointed unless it was very clear ahead of time that this purchase was limited. If you made a perfect system, with strong encryption, if the user knew the user probably wouldn't buy it. We have lots of requests for DRM systems that end users understand. Moreover, users require simple business model, protection of privacy, a fast and reliable system, and something that runs on standard hardware.
After knowing all that, if you look at existing DRM systems, we are not very satisfied, because there is no system that satisfies this. There is no global license system available (contrary to belief, the Microsoft system is not global). DRM systems are only compatible with themselves (and sometimes, not even that - see Microsoft again). The handling is not transparent to the user, there are no open systems, and no DRM is available for all content types.
The mission is clear: we need to address the requirements from all three points of view, using an open DRM architecture. Content providers need a powerful and independent platform; they don't want to bind their content with the company that is providing the DRM system. Operators want to be able to handle different media types; it is too expensive to set up a new DRM or CMS for each media system. And users want to get content that is easy to handle on normal devices.
Microsoft, Real: the license is 'stored' in the player and bound to the hardware. But this means I cannot transport the content from one device to another. For example, if I buy content, why does it only play on my computer and not on my stereo? OMA: the license is stored in a secure part of the device, however, the OMA DRM is made (only) for mobile devices. There is a break in this DRM system.
Opera is trying to create a new single license that is delivered for every usage. We generate 'metalicenses'. We go to different DRM systems and say, generate this license, generate that license. It's basically like putting something between the license and the player.
The benefit of Opera is based on two conceptual approaches: first, the license is independent of the DRM system, and it is independent of the device. To do this, Opera directly integrates major DRM systems and uses the already available DRM frameworks.
Features:
- User-bound licneses: usage rules are independent of the end devices. This provides security for the content provider, ease of use for the user.
- Separation of rights from content: allows the use of every type of content the underlying DRM system is intended to support. This allows content providers and end users to use arbitrary DRM systems.
- Support for multiple devices: PC, set-yop box, PDA.
