Apr 23, 2004
ODRL Vienna - Day 2
OMA Secure Content Delivery for the Mobile World
Willms Buhse, Vice Chair, OMA DRM Working Group and CoreMedia, Germany
OMA started on DRM in 2001 because of market demand for, for example, ring tones, and with Bluetooth coming available. There was a risk of piracy; content producers were eager to make product available but were concerned of security. In general there were mass market phones which did not even support encryption. The solution had to be timely, for mass market phones, and easy to deploy. On the operator side, it was necessary to have a technology that was easy to deploy.
The Open Mobile Alliance has about 370 members, and what's special, it represents the entire value chain. There are about 70 organizations that are looking to standardize DRM - that's probably more than there are DRM providers themselves. So we looked at the mobile environment with an eye to standardizing. We had meetings with about 50 Companies, including content providers, IT companies, and vendors and handset manufacturers.
After about a year we were able to release the first standard, OMA DRM 1.0, which was targeted for light media content. It was a very simple system where you could download the file and the phone knows it cannot forward the file. Later was added combined delivery, which is where ODRL comes into play, adding a rights definition. Finally, a third layer, combined delivery, provides encryption and supports legitimate viral distribution.
In November 2003, there was a 'test fest' (Seattle) to test DRM v1 interoperability. The OMA supports about 16 specifications covering billing, downloads, etc. Engineers came together from the service side and from the handset side, and all the servers test with all the handsets. With regard to DRM, OMA only looks at interoperability; it doesn't look at security, etc. We now have about 70 devices in the marketplace that support OMA DRM.
What's coming for version 2? The feedback we received from the market was to the security requirements; in v1 not even encryption was being used. In order to release premium content they really required more security and the trust model associated with it. More bandwidth was becoming available, and the mobile devices had removable media. The trend was to release full media tracks and high end games.
Two design goals were found. First, it was important to keep the content and trade secrets safe. And it was important to keep the content from leaking during distribution. So we looked at increasing security. So we chose to encrypt the rights object using a device public key. We also had to define explicit trust mechanisms, an authentication system between the device and the content vendor.
These two points required a trust model. But what does this mean? You need an entity with robustness rules. Alternatives: every rights issuer shows their device to every content provider and show its robustness, and specify penalties for failure. But this is a lot of overhead. So we founded the CMLA to create a common trust mechanism, so you don't have to have all those individual relationships.
The system we developed supports secure multicast and unicast streaming, working with 3GPP and 3GPP2 on packet file format for protected streaming. We support a subscription model for content bundles, and we also support gifting. We have to ask, what business models will be successful? Pure download? Probably not - you have to support combinations of content and distribution. People send SMS, why can't they send content? People should be able to see it, and buy it if they like it. So we provide viral marketing and a reward mechanism. If Renato motivated me to buy content, he probably gets free minutes or free beer. This has to be Renato's choice, to participate in the program. But it is a form of super-distribution; it scales way beyond the linear model. This model has led to a 10 to 20-fold revenue increase. But if you want to have a successful form of super-distribution, you need an open standard.
For the end consumer, the benefit is that we allow for advanced content management. Suppose, for example, you buy a new device. Suppose you cannot move your music collection. There was need for storage and backup. It would be easy to move the content, but there is also the possibility of backing up the rights (but if you have stateful rights, you can't back them up, so we left them out). We also support multiple devices - moving content and rights between devices that belong to me. Sharing multiple users between one domain - there is the concept of fair use, and DRM vendors are criticized for not supporting fair use. Think, for example, within a family; it should be possible. It is completely legal to exchange a CD in your private environment. So somehow DRM systems have to refect that. That makes these systems very complex, but now you are talking about content that is not specific to your mobile device. You want to be able to share with different devices. You want to be to export to other copy protection schemes. You want to be able to provide complementary preview.
Steps: th content has to be encrypted and packaged in our content format (DCF). Assign permissions and constraints during transaction. Consumers receive content 'rights' and begin using the application.
Diagram: content provide, and rights issuer. The rights issuer establishes treust with the device. The device browses and downloads content. The content may be shared within a domian. And from this domain, the content may be superdistributed, which establishes trust and gets the rights object delivered. From the rights issuer is the connection to the billing mechanism.
OMA DRM will continue to evolve. Yesterday, we were able to freeze the version 2 DRM standard. It will be released very soon as a final standard. It took us only 1.5 years. So please join us if you are interested in helping define the next steps.
Gunnarson: this is a great tool from a broadcaster's perspective. But is there a means for streaming to have one to n connections?
Reply: yes.
Gunnarson: The viral marketing is very interesting. Suppose somebody is covering an event or recording an event. They want to market this. Do they ring up a bill at a telecom conference, for example? Can they do this without ringing up a bill.
Reply: the standard allows for models like this, but it depends on whether the provider wants to do this. You can simply create an MMS and look and see. You don't need DRM for that. The benefit of the DRM is you can identify the people who are very good at distrinbuting - the super-super-distributors. These are the people the marketers want to get at. Give them content, and they themselves promote it. They can be rock stars, or media stars, for example. I look at music, 70-80 percent I didn't discover myself.
Gunnarson: Privacy?
Reply: there is a threat. But it doesn't just come from DRM - you have to go to a point and download it.
Vestavik: the reward system could be used to transfer the spam problem from email to the phone system. Or just try random numbers and send spam.
Reply: you can do this with SMS today. You just try a bunch of numbers. It's a pure push. But in the viral marketing you look at it and send it on. Also the DRM system is transport mechanism independent - you can use infrared, or use Bluetooth, or something. Some vendors hate Bluetooth - but if you use it for marketing, then you make money not from the content transfer but from the licensing. That's a very powerful model. It's very difficult to make money from the song download. They would have to put up antennas everywhere. But if people distribute music via infrared, then you become basically a DRM provider. DRM should not have billing capabilities with it, but should have a gateway.
Hockx-Yu: How is a domain specified and where is the boundary, and how do you make sure content does not go beyond a domain.
Reply: it's an implementation issue. You need to know which devices belong to the domain. You have to register the device, either with the device itself or with a backup mechanism. There is a registry; it can be a localized registry, where the phone knows the domain. And the content provider limits the number of devices that can be in the domain. There is no law about it, but the number of 7 appears from time to time. As a content provider, you make this decision. But it's certainly not to a million.
Hockx-Yu: Are users looking to pay more to be able to share.
Reply: there is research. People tend to be willing to pay a higher price to be able to share. But as a content provider you have to figure that out. They have to play around. It may vary between content type.
Guth: Did they think about a central repository for rights, to avoid transferring rights from one device to the other.
Reply: Per domain? For the entire world?
Guth: No, I mean per user.
Reply: my former company actually designed something like that, called RightsLocker.
Guth: I know.
Reply: Then why are you asking? *laugh* We wanted to standardize as little as possible, and to allow flexibility in the business model. So we standardize on the handset, but to say you have to have a RightsLocker, you would be imposing that. We didn't standardinze at all the content value chain. That's up to the vendor. This could be standardized, yes, but OMA didn't care about it.
Guth: success factor is that producers of the devics keep the power over the software and the operating system, otherwise you have the same situation as the PC world. Is there a danger from open operating systems?
Reply: it's a huge discussion; it comes from a walled garden concept, where youy couldn't add content. But consumers want more open systems. But that's not in the interest of the operators. If phones open, they lose control, and business opportunities. But it is difficult to keep consumers in a certain domain if they don't want to be there. So it's a tough question; there are a lot of different views.
Guth: Do you think the OMA people stick together for that reason?
Reply: Well OMA exists for interoperability, but this goes into it. The more you can control the end user behaviour, the more you can control the usability and the degree of satisfaction. But if you have a phone that's completely open where you can browse everything, it's a completely different user experience. Same thing applies to ISPs. We have ISPs like Freenet, they're just a bit pipe. They provide the access. Then you have AOL. It tries to keep their users within their domain - they provide music, content, a news agency. For both business concepts there is room; there might be a way for vendors to differentiate themselves. Some go directly to the music vendors; they have the entire value chain. There is room for both concepts, but I don't know where it's going.
Ianella: Has anyone mentioned you can implement OMA on the internet?
Reply: yes you have that, as soon as you talk about having unconnected devices. If you look at operator strategies. There's a big battle around the living room for instances. The service providers want to be a part of that, you transfer your license to your set top box. But the concumer electronics companies, like Phillips, they acquired InterTrust. And Microsoft with MediaCenter.
Question: To get security, you need hardware control. Do you convince them to switch to OMA?
Reply: Those companies don't know themselves. They support the OMA very strongly, Sony is a member, a very strong member, of OMA. Phillips, same thing. At gthe same time they are working on DRM and they are looking at InterTrust. And I'm not sure if that will work in the same way OMA does. There might be a different DRM appearing in the market. And Sony often does things their own way. And people might buy just a Sony camera, and video, etc. But with an open standard, it's really much better.
---------
[Dr.Elma] -project
Eetu Luoma, University of Jyvaskyla, Finland
Case: implementation for creating digital contracts through digital templates.
Most R&D is focused on controlling and tracking content downstream. But this overlooks interests updtream on the content cretion side. We believe that in a digital environment rights and oblications can be and will be negotiated and agreed easily. In addition recognition and contribution of materials may be monitored and enforced more effectively. This will create an increase in contract volumes. There is a need for this information management.
We know there are systems that can control the distribution of digital asserts. These systems associate a parameter file with each asset. There are issues: creating descriptions, this requires special technical skills. Current approaches reflects the way those formal languages express rights in actual contracts, written in natural language. So we have certain needs for methods and administration for the straightforward creation of (legally binding) contracts in the digital environment.
Steps: define a contract template that reflects the way the organizations operate - legal framework, social norms, business admin - or several templates, perhaps one for music, one for text, etc. Three steps to define the template. First, define contract text in natural language, and we mark hot spots fo content-bounded information, such as the asset or parties. Then we define applicable user interface elements to allow the person creating the contract to make selections and inclusions. Then we define connections between contract text and user interface elements.
------------
Nonius:Implementing a DRM Extension to an XML Browser
Olli Pitkanen, Helsinki Institute for Information Technology, Finland
We have implemented a couple of DRM systems in addition to our more academic work in order to better understand DRM systems.
The Nonius demo was started in 2000 and completed just this year. We had several partners and the program was funded by the government. We had both lawyers and engineers. The demo itself was developed by a group of 7 computer science students supervised by me and other researchers. It took about 8 months to make this demo. It is an extension of an XML browser developed at the Helsinki University of Technology, X-Smiles (http://www.x-smiles.org) written in Java that works on multiple platforms.
WE decided to implement a subset of ODRL because it is expressive, well-designed, and open. Because of the limitations of the XML browser, we implemented only about 20 percent of the ODRL features. The browser is open source, and so is the extension, which means that it is probably not possible to develop a secure system in open source, but security was not one of our concerns. The main issue was to study problems related to the implementation of a DRM system.
The example was simple: we built a simple web store from which users could buy digital products, anything that a browser could display. The user was able to download the content file and then buy the certificate in ODRL in order to view the content. But what was not implemented was the security system.
First, we didn't want to modify the browser code too much, so we were limited by the browser features. Then we decided that each asset should be accessible by a URL, local or remote, which points to an XML document that X-Smile can display. The asset is displayed by first opening an offer document that points to the asset itself. Based on this, we implemented the DRM extension.
We tried to enable the user to view the offers and agreements in a human-understandable way. We implemented a set of restrictions, eg. time of validity, restricted individual, restricted software, restricted instance of use, restricted number of uses, restricted accumulated time of use, restricted geographic area, and any combination of these. We implemented only 'view' because this is what X-Smiles supports.
Experiences: we tried to build the system scalable and modular and we believe it worked quite well, but of course we didn't test it thoroughly. The implementation was not secure. Open source introduces several problems. It was hard to secure device ID. Without hardware support, it is difficult or impossible to build a secure DRM system. We believe we overcame most of the browser limitations. A big problem with ODRL is incompatibilities with legal systems; the terms are different, for example. For example, in ODRL you may express permissions to print or save, but laws don't use these terms.
Difficulties: in ODRL, if the software comes across a restriction it doesn't know, it shouldn't allow the action. This proved to be difficult to implement in the architecture. We also found it difficult to merge certificates; it is not technically challenging, but it is semantically challenging. Incremental requirements were difficult to fulfill, for example, in a pay per view, there may be new requirements later which are not accepted by the user, it is difficult to roll back and cancel the payment.
In the ODRL spec, AND was easy, because it is implement, but OR is more challenging, and was not implemented. Any element may be linked inside the document to any other place, so the semantics may depend on the context, so it may be hard to tell what it means. A deeper element may depend on the parent element, so it is necessary to check the parent element. This would be easier with a tree parser, but we did not implent this.
That said, we still found ODRL to be a decent rights expression language, especially in comparison with other rights expression languages.
Ianella: You said there were incompatibilties with the legal system. But we find that hard to solve. We are talking about specific actions, in comparison to very broad terms, like 'fair use'. It's very hard to tell a machine, we are doing fair use today.
Reply: I understand. But if we are trying to translate legal terms, it is quite difficult.
Ianella: The list of things that were difficult, may play a role in version 2.
----------
Discussion: Future Directions for the ODRL Initiative
Ianella: Why:
- It has to be a simple license
- Contrast between tick and contract
Guth: first issue, whether we should focus on contracts or on tickets, or both? Should we be able to express everything that is needed in a contract, as in my talk? Or should we concentrate on tickets only, is that the killer application, or a superset we can extract ticket information from.
van Hardevelde: some of our systems do need contracts. So I would like to have a system that offers both. Maybe some context ID should be mandatory.
Ianella: sometimes people don't use it at all.
Gunnarson: maybe a contract is a used / completed ticket.
Guth: a contract is an agreement between person A and B, and they agree on certain things, and everything they agree on could be derived as a ticket. So he has the ticket to collect my money, I have the ticket to use the music. This is our view of contracts and tickets.
Vestavik: there are different ways of looking at tickets here. A ticket is a way to access the material. Actually executing that right.
Guth: But for this you would have to change your contract, not a good idea. Then the two parties have to sign the contract anew.
Vestavik: I talked about this, I added the execute item, it should be stored in a profile, not in an agreement.
Guth: it's complicated in a profile to determine how many tickets to issue.
Vestavik: well there are constraints that can only be validated at access time. You look and see whether the conditions are fulfilled, and you issue a ticket.
Ianella: state information is another issue. The key point here is that in the agreement model there are no obligations on the rights holder. But I think we want to move to a contract where there are obligations on all parties.
Guth: a really common agreement is a barter, where there is no monetary transaction, and both parties have duties. We found that we needed that expressiveness in the rights language. Basically it's that we do not specify party classes any more.
Pitkanen: Law on contracts?
Guth: the law says the formulation of contracts is formless. Anything you can write down in a contract can be agreed on. To map to a legal language might involve a vocabulary to legal terms.
Vestavik: legal terms are very different internationally.
Guth: there are EU directives. I know that implementations in countries are different.
Pitkanen: freedom of form has been there for some time, and ODRL could be called a contract, but it doesn't mean that just everything can be a contract.
Guth: there is no law that I know of that some thing must be the case to be a legal contract.
Pitkanen: the primary legal requirement for a contract is that the parties have wanted the contract. Contract law covers the contractual relationship between the parties. The question is, do we want an ODRL file to be capable of expressing a contract? Or only just a subset? If a subset, what subset, and what would be the purpose of the subset.
Guth: we are talking about the basic data model, not the dictionary. In the elements, in my view, you can express everything you can in a written language.
Pitkanen: we should empirically test, to see if contracts can be formulated in that way.
Ianella: does anyone violently disagree with moving this way?
Vestivik: well, if you want contracts to be legally binding...
Ianella: that's for the law to deal with. There's no form to say this.
Guth: it's just, do we include the infdormational elements that we need to include?
Luoma: We want to know how the ODRL expressions are used, how information systems are using it. How do I use a formalized contract, in XML format?
Guth: you can use it in different ways. One the one side you can get a license with some rights, get it to your mobile phone, and it enables you (or the software that is running on your device) to play some music.
Luoma: I'm not using the file, the rendering device is using it.
Guth: Yes, so the device can interpret it automatically.
Luoma: well, then can we come up with an expression that rendering devices cannot use? I'm trying to make the point that we should limit the elements to those that rendering devices can use.
Ianella: that might not be in our power.
Inava: for us, introducing duties for both parties is the perfect idea.
Gunnarson: it is helpful to look at the legal side, because there are both sides.
Ianella: I think that we fully expect that as we do the new system that we will be getting feedback.
Downes: there is the question of decidability, can it be known to be satisfied. For example, it's not clear that an automatic system can ensure that a bartering agreement has been met.
Guth: every condition must in some way be able to be checked, for example, there has to be some means of knowing how many times a music file has played. I think it is knowable that someone has uploaded material and met his duty and check this. But these checks must be external, we cannot do it within the rights expression.
Ianella: we can express count, but we can't know count.
Guth: obviously, some duties are hard to verify, but Ivana said, we need duties, and there have been duties in ODRL anyway, they were called requirements before, it's more an information model that is clearer than before.
Strembeck: The duties are more general and the requirements are a subtype of the duties.
Ianella: Next issue. How? The process. We were originally requesting feedback and you would get your logo on the page. It's a very informal system. The host was IPR Systems, but it no longer exists, it ran out of money. I'm taking with me the initiative, but there is the question of hosting the initiative. Some partners, for example Nokia, went off to standards bodies to promote ODRL. But in terms of the specification itself, we had an email list, we asked for discussion, we came up with a version. 1.1 is a couple of years old now, it was submitted to MPEG. There are formal standards groups out there now, we could say, we will put our standard under your group, under your process, they have their methods of doing things, weekly meetings, etc. That gives up some of the informality, the ability to make quick decisions. At this point it is really up to us, as an informal group, but perhaps a but more formal email list, a more formal group. But as we work toward version 2 we may want to form more formal groups looking at different tasks. At the moment we can support email groups and the ODRL website, and obviously we can put up documents. Also we can have liasions with other groups, for example, with OMA, so we can have a formal way we can communicate with OMA, about what we are doing, and they can tell us what they want. Standards groups have a formal liasion between them. If we decide to move to a more formal group, which group? W3C would be difficult. Oasis, ContentGuard and XrML are already there.
Guth: The Learning Technology Subcommittee DREL group, Robin Cover sent them a letter saying this was wrong.
Ianella: yes, anyone can go to Oasis and set up a working group, and the group decides when they are finished. Oasis doesn't have a say over approving the specs, only over the process. It's a much more easy entry process, but in terms of concensus over the whole project. That's why Content Guard went there, to promote their product to another forum. So we could go there, to give us more visibility.
Gunnarson: It seems that Oasis is approving certain things, there is a perception.
Katzenbeisser: so the impact may be bigger, if there is a standards group.
Ianella: We went to IEEE, the DREL, but now the process is that they are evaluating the two languages regarding learning objects, but they won't be recommending one language over another.
Hockx-Yu: NISO is an option.
Ianella: That is a U.S. group, unless we had stronger U.S. representation, we would probably want a more international group. Others?
Comments: CEN, ECMA?
Guth: Do you know how they work?
Comment: No... the last thiong they did was C#, I think...
Comment: ISO...
Downes: They have adopted XrML (MPEG-REL)
Ianella: would people be happier if ODRL moved to a more formal group?
Downes: Yes
Ianella: Right. But in the meantime we can continue with the informal process.
Strembeck: It would be good to have the version 2 and take that to a standards body.
Ianella: In parallel work on version 2 and work toward a standards body.
Comment: most of those bodies will want to have a say in the final document.
Ianella: Right. We would go to them with a draft document, and finalize using their process.
Guth: A more formal process needs more resources, and people to participate, and everybody in this room is a potential part of that formal process.
Ianella: Yesh, cash donations would be great at this point in time.
Gunnarson: Are there EU grants?
Guth: probably yes. The EU is probably ready to give funding for further development.
Ianella: Obviously OMA has adopted ODRL. Obviously it wouldn't be the home of ODRL.
Buhse: Well as a personal stateme nt, the risk is that OMA is targeting a mobile audience, and I don't know what your hope is, but I would hope it's beyond a mobile audience. I personally would favour a place somewhere else, but I don't exclude that.
Ianella: Right. There has been a lot of uptake in the education sector, so there would be a downside. Should we fomalize a relation between OMA and ODRL, there is a process, right?
Buhse: Yes, there is a process. I would have to discuss that with our members. But it really depends on where you're going. I think the relationship we have, your input, is very much appreciated. It also depends which direction the OMA DRM group is taking. We have worked very hard to formalize version 2. But then what?
Guth: The general consensus is that the more formal way is a good way to go. Is it only Stephen saying yes?
Luoma: speaking of formalization, who has a vote?
Buhse: if it were in OMA everybody would have to join OMA to make a contribution, that costs money. So you need to consider this, simply the financial impact. So keep it as a free flowing organization as it has been, more of a volunteer organization.
Guth: I have been working with the IEEE LTSC and nobody close to me is a member of IEEE, so you can sneak in.
Ianella: IETF is free, I don't know about OASIS, etc.
Hockx-Yu: Look into the options first.
Ianella: Right.
Gunnarson: I have done work in recommendations. You look at the thing. There is a difference in whether it is perceived approved. It might be an advantage for the exposure.
Ianella: We could have just taken it to the standards association of Australia, and make it a standard, take it to their national bodies.
Buhse: It's like CEC, they released a report, saying they did not see a need to do something, that's their mindset.
Ianella: We will continue with the informal process, gathing volunteers for work.
Ianella: Next issue: scope. What sort of feature set are we looking at. Can we look at rights more? Look at data dictionaries? Maybe our friends at MPEG-21 Part 6? Then there is the generic context element, or maybe we want to get rid of it. Eg, if it's a learning object you would use LOM, etc. Do we want to look at identity management, bringing us into line, say, with the liberty alliance. Also an issue is the timeline. When would people like to see a version 2?
Downes: There is a need to look at the question of bindings. How does ODRL work with LOM, RSS, DC.?
Ianella: Right, We have done some work in this, but there has not been any reporting back on this. Some part of the scoping or the process is the profile. We could have a LOM working group. That group would specify a profile, publish that, and make it known.
Van Hardeveld: Need to express permissions for superdistribution. What are the parameters of this. Can I do it. On what device? Constraints.
Guth: It's nothing more than having just a normal ticket. Only in this case you have the right to give it away. They (learning groups) said it's very important for us to describe how to aggregate the object.
Luoma: newcomers to ODRL need more guidance to get things going, examples, use cases, example architectures, examples of how to use ODRL.
Ianella: we have a list of projects, but it's pretty out of date.
Luoma: You should include that in 2.0, in the website.
Ianella: Right, a FAQ, etc.
Guth: Nobody has yet mentioned fair use and free use, that came in the discussions a lot. I assume that's a recommendation.
Pitkanan: How about as a specification, it is often stated that DRM wants to restrict end user rights.
Ianella: It's what stephen said, it's not that DRM is stopping you do stuff, it's helping you do stuff.
Luoma: so we should include some statements about fair use, etc.
Ianella: Yes, we should have the vision, the key issues.
Ianella: There are features in 1.1 I've never seen people use, like sequencing, and we want to keep it simple, so we may want to think about removing features that nobody uses, obviously we would want to tell people.
Vestavik: That raises issues of compatibility. If you go to a standardization process you will have to ensure that.
Ianella: How important is that, that you can go to 1.1 from 2? 2 from 1.1? We could pobably do easy transformations between the two. The issue would be, if we took something out, or added something in 2, you would lose information.
Luoma: I wonder whether it's a question of scope. Different manifestations of the ODRL document. Whether an ODRL document can be viewed as a contract, or as Stephen said, a rights model. Should different manifestations of an ODRL document be considered?
Downes: Yes
Luoma: Stephen is using it to come up with rights models. You;re using it to come up with contracts or agreements. Others are using it to come up with licenses.
Ianella: You may have a case where you don't have all the information, when you add the information the character changes. It's about interoperability between two systems. All we say is that if you transform an ODRL document between this machine and this machine, this is what it should look like. If you don't put an identifier in, it's probably not the best for the other system. But if you have a system that creates half a rights file and wait for the web service to provide information, fine. Unless you go to a profile, then now you say this stuff is manditory, here here and here.
Guth: if you are in a certain environment you have to admit to that profile to be in that game.
Ianella: we want to make it vary obvious that we support profiling, that we want profiling, and that you should tell us. And we need a profile manager.
Hockx-Yu: We are developing a potential service, metadata schema registry.
Downes: perhaps it would be useful to specify the different documents, eg., to show how to licnese a website.
Guth: That is like Creative Commons, and we are back to the ROMEO project, it is there already.
Hockx-Yu: Adapting Creative Commons to ODRL.
Buhse: There were three things that we could not get around. First was participation by all value chain members. This is crucil. Make sure that you have this committment from the industry. In the mobile you have a great start. Second to create liasions and make sure there is some consideration. So there is not much room for other standards organizations. The last one is focus and speed. I would consider these as guiding principles for future work.
Gunnarson: Some organizations have been from the U.S., is there any adoption in the U.S.
Ianella: we do have people in the U.S., some digital library projects, but it's obvious there is a European focus on ODRL, but I don't see that as a negative.
Guth: I don't think we are missing American participation, there are people working on it, we're obviously present there as well.
*Break*
Guth: Next issue: what should be the content of ODRL 2.0? In version 1.1 there is the data model, some informal semantics, and we have the XML schemas in there, and I'm pretty sure we need this in there. But when we were talking about RDF, the information model in RDF might be a good idea, serialization, an ontology, and we have the formal semantics of course, should that be in the specification? Are there things that we missed in 1.1?
Ianella: I want to add or highlight the fact that we want to split up the specification into separate documents, stand-alone documents, relation of course, covering the expression model, then bindings to XML or any other syntax you wnated to come up with, a separate document that covers the formal semantics, and couments that say, here's how you work with ODRL for web services, a very modular version 2.0 that would allow other people to come up with bindings, so we have a set. That would make it easier to split the work up, we have subgroups, mini groups. But what else have we missed?
Downes: The NOT and wildcards?
Guth: is the NOT part of the specification or a part of the scope.
Ianella: It should be there somewhere, it has to be somewhere.
Guth: what we need is a statement about general issues. Also the fair use thing, if we do not want to have a syntax on how to do it, we should have a document.
Ianella: Yes, we should have a statement of principles, for example, if the permission is not stated, it is not allowed.
Hockx-Yu: maybe a statement about how ODRL is not supposed to be used?
Ianella: well we want to be more positive.
Guth: It may send people away.
Gunnarson: it was said yesterday, maybe a widecard is better than a not.
Ianella: Yes, we talk about these things at a high level, but they have to be in the document somewhere.
Guth: fair use and NOT and things, these are buzzwords, and people would want us to have an answer somewhere, otherwise people would have to read through the document, so it's a good idea to have a statement.
Gunnarson: a profile or a use case or something.
Ianella: yes, this is like the non-technical part of MPEG-21, we would want to have the same thing, a vision, to let people know where we are heading.
Koppen: what we have learned in implementation is that there are certain things that cannot be specified, so there are best practices. There are certain things, they are not usable. It's not a formal part, but you should not use it. Another thing that comes up often is the security aspect. It was referred to some other party. If somebody asks, but you can say the way of doing that is that you get the rights owners and consumers to the same table and agree on a way of doing that.
Ianella: Yes, we have the security model, but the trust model is something we can't do.
Guth: It's a question I ask, si whether the digital signature, and revoke should be part of the specifictaion.
Koppen: I would say not.
Guth: I was wondering if this isn't something the DRM system would need to regulate, but wouldn't this be in the expression language, that the first part of the license is no longer valid. That's a good discussion point.
Vestavik: Revoke statements should not be part of the permission language, it is not only used to revoke offers, but it is also used to take away rights already contained in the agreement. Conditions on the other hand are known to both parties.
Guth: The same question pops up for the digital signature part. You (Ianella) already said we are re-using a different schema to do this, and that could be included in a license or not. And we could do this with all kinds of metadata schemas, why not attach it to a part of the document, that you could mix different description languages and different name spaces. So whether it would include the digital signature langauges.
Downes: Using external languages is OK, but may involve RDF, which may cause issues. Example, the RSS community. Other alternative is to allow defaults; you allow tags from another langauge to be included.
Vestavik: The question of digital signatures should also be raised with respect to legal agreements, what is the legal status of this, so that they cannot be changed. Having a digital sends a signal that ODRL is intended to create a legally binding contract.
Guth: That is is an issue, we need to have a statement, that there are some instances of ODRL that are intended to be legally binding...
Ianella: but we can't say, you should use digital signatures because that would make it legally binding, we can't say that
Vestavik: But that is the whole point of digital signatures. There should be other encryption techniques, hash values, controlled numbers, and so on.
Ianella: we could keep a list, we can't make a recommendation, but we can have the options, secret passwords, secret brown paper bags, let the community decide.
Vestavik: If you want to have full flexibility for everything then what is the point of having a language?
Guth: That is the point, you can develop anything anywhere. The root structure is licenses or contracts, and what it should be is adaptable. We have two schemas, the expression and the vocabulary. The expression itself is the document, it includes important elements, parties, etc., and how these elements should be described, and what should be added, digital signatures, should be adapted to the environment you are using.
Gunnarson: where it is possible to get wider usage, it is unwise to limit yourself. You want to get exposure, so if you decide something that excludes peopel, you shouldn't do something.
Ianella: put that in the vision statement.
Downes: enable don't require.
Ianella: Describe in the vision statent, show how to implement it, but everything is optional. That's how DC can have profiles. Maybe that's the vision we should have for ODRL. It's probably the default vision, nobody has implemented full ODRL.
Comments; Service profiles?
Ianella: Yes, that should be a separate document, here's how to implement ODRL in SOAP, or whatever.
Gunnarson: Not just SOAP...
Ianella: are there others...
Downes: REST
Gunnarson: the reason why SOAP is so difficult is you have to keep a state. There are others that are not so difficult. Tickets.
Ianella: What about privacy, we were told yesterday we should be aware of privacy. Should we do it?
Downes: privacy could be expressed as a duty on the vendor.
Guth: two views of privacy, of the digital content, or of the contract. P2P could apply to either, do we keep the contract secret, or do we keep the content secret.
Ianella: We should list it down on the to do list and as Wenning. We could express it as a duty...
Guth: If we are talking about the privacy of the content. But if we are talking about the privacy of the contract it's another problem.
Ianella: I want to look at one more exampl, from Stephen's talk, at the moment you have an asset and we grant permission, but what if we have 80 assets and we want to grant you permission to use 20 of those. Do we have a more flexible way to represent assets, identify using URI...?
Guth: Well, wasn't that just a misunderstanding...? That no rights expression has to apply to an object, but the connection has to be somewhere, Stephen said, the connection to the asset is there, we don't care whether this is contained in the description of the asset or the rights.
Ianella: this is a case where the asset would vary depending on what the user decided after the contract was designed. A subscription service where there are 80 movies, but you can only view 20 of them, you choose one now, one later.
Guth: that goes into the service level agreements. I'll write this down, for agreements, choosing from options.
Gunnarson: in software, many things are dual licensed, or triple licensed, eg., if you want to use it for free things, one license applies, but if you want to sell things...
Guth: that is in the license, in the offers, you choose one of the offers.
Ianella: Thank you all for your participation over the last two days. Thanks to Susanne for organizing and cohosting the workshop.
