[Paper Overview ] [ DRM-Workshop Homepage ]

Principles for Standardization and Interoperability in Web-based Digital Rights Management

A Position Paper for the W3C Workshop on Digital Rights Management (January 2001)

Authors:

John Erickson < john_erickson@hpl.hp.com>
Matt Williamson <
matthew_williamson@hp.com>
Dave Reynolds <
der@hplb.hpl.hp.com>
Poorvi Vora <
poorvi_vora@hp.com>
Peter Rodgers <
peter_rodgers@hp.com>

Hewlett-Packard Laboratories, Publishing Systems & Solutions

1. On the Role of the W3C in DRM Standardization

HP is pleased that the W3C has chosen to tackle the difficult issues concerning intellectual property rights (IPR) and the Web. We are confident that the W3C will play a unique and important role in fostering recommendations for the dissemination and application of IPR policies for Web-distributed information. We are also sure that the W3C will work hard to balance the needs of a wide range of stakeholders, from content creators through end users.

There are no clear and easy paths toward making IPR policy expression, enforcement and compliance an integral part of the Web, as the W3C discovered with its earlier efforts in the privacy domain [P3P]. But the of the Web as an important, pervasive conduit for the creation, sharing, trading and accessing of information demands that we rise to these challenges.

The Web is a network of information; as such it is also a network of intellectual property. All information that is made accessible on this network is by default published within some IPR context, in which relationships between those items and parties (such as creators, publishers and consumers) have been defined in some way, either implicitly or explicitly. The manifestation of those relationships in terms of specific items, parties and actions can be thought of as an IPR policy.

Today there are no consistent mechanisms for the expression of IPR policies on the Web, nor are there ways for Web-based information consumers (or agents operating on their behalf) to discover, access and interpret such policies for objects of interest. The quality of the Web suffers by not having an open and accessible way to bind or associate IPR policies with published information.

We therefore suggest that the role of the W3C should be to recommend a "platform" (esp. a language and a protocol) for IPR policy expression, discovery and interpretation; we suggest the name Policy and Rights Expression Platform (PREP). PREP would not be a standardized digital rights management (DRM) system, nor would it be a universal information commerce system --- although it might provide a basis for interoperability in both cases. It would also not be a replacement for advanced metadata expression and transport mechanisms currently in development. But it would provide a reliable way to express and transfer rights information, and could serve as an open interface for mechanisms for policy compliance and enforcement. From an IPR policy perspective, what the Web community needs first is a consistent and reliable mechanism for policy expression and discovery, with mechanisms for enforcement and compliance considered later as extensions.

2. IPR Requirements and the Design Principles of the Web

As the delegates to the DRM Workshop consider how best to treat the myriad IPR requirements of the Web community, it is especially important that we remain centered on the Design Principles of the Web , paraphrased here [W3C7Points]

a. Universal Access: One of W3C's primary goals is to make the universe of network-accessible information, which enables new forms of human communication and opportunities to share knowledge, available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability.

Mechanisms for IPR policy expression and enforcement must never interfere with users abilities to discover the information they are looking for; these mechanisms should always communicate in understandable language the policies under which they are allowed to use the information, as well as any necessary technical conditions and constraints. Policies must be communicated in ways that are fair and open; every policy that is enforced by a technical mechanism should also be expressed in semantically equivalent text, so that users clearly understand any contractual terms that might otherwise be hidden from view.

b. Semantic Web: On the Semantic Web we will be able to express ourselves in terms that our computers can interpret and exchange, enabling them to solve problems that we find tedious, to help us find quickly what we're looking for.

In some cases, users will want applicable IPR policies to be considered when they (or agents acting on their behalf) search for information; in other words, an important aspect of what we are looking for might be what we have a right to access (in a particular way). This leads to two observations: first, those IPR policies must be expressed in ways that are consistent with other metadata sources and expression mechanisms on the Web. Second, policy expression mechanisms will also serve as the basis for personal or organizational IPR policies, which may take the form of declaring the types of policies terms individuals or organizations will accept or reject.

c. Trust: To promote a more collaborative environment, we must build a Web of Trust that offers confidentiality, instills confidence, and makes it possible for people to take responsibility for (or be accountable for) what they publish on the Web.

Trusted relationships are built upon provably binding assertions (such as metadata) to trusted reference points that the relating parties have in common. In the context of expressing IPR information and policies, we recognize that even the best languages and protocols are useless unless users have a basis for believing the assertions, and can be confident in the integrity of the mechanisms that provide them with the information. Furthermore, we recognize that these mechanisms must operate in ways that ensure that confidentiality is preserved, even during the process of policy discovery.

The preservation of confidentiality of transactional and other information applies to both business-to-business (b2b) transactions, where commercial confidentiality is required to avoid revealing transactions to third parties, and to business-to-consumer (b2c) transactions, where privacy policies demand that an IPR policy expression and enforcement framework support controlled levels of anonymity for individuals and for aggregated transactions. This latter bit is the work that the W3C began with P3P. [P3P] The relationship between privacy and IPR policy enforcement is explored in a companion position paper submitted to this workshop by Poorvi Vora of HPLabs.

d. Interoperability: The W3C, a vendor-neutral organization, promotes interoperability by designing and promoting open (non-proprietary) computer languages and protocols that avoid the market fragmentation of the past.

IPR information and policies must be discoverable and minimally interpretable in ways that are independent from any particular vendor's solution. This means that any actor in the Web community should be able to discover and interpret the IPR policies of any piece of content, web-based or otherwise. Furthermore, they should be able to readily discover the transactional and technical requirements for accessing and using content, including any components or web services that might be required. The Web needs both a language for IPR expression and a protocol for IPR policy dissemination that is independent of and agnostic to any particular DRM mechanism.

e. Evolvability: W3C strives to build a Web that can easily evolve into an even better Web, without disrupting what already works. The principles of simplicity, modularity, compatibility, and extensibility guide all of our designs.

Evolvability is a key principle in the success of the Web, and of the Internet in general. We cannot imagine all the ways that today's information, and the languages and protocols we use to express and disseminate that information, will be used tomorrow. This is particularly true for IPR information and policies, which will remain the key enablers for both the legal and business aspects of the flow of information and knowledge. The languages and protocols we develop for IPR expression must be designed for evolution, inherently evolvable for the many ways that we will access and apply rights information in the future.

IPR information and policies must be discoverable and minimally interpretable in ways that we cannot imagine, meaning that new ways to segment fundamental rights will be introduced, and new statutes affecting what we call rights will be adopted. Our mechanisms and processes for interpreting IPR information and policies must be flexible enough to capture this sociological evolution of the IPR environment.

f. Decentralization: In a decentralized design, the number of central Web facilities is limited to reduce the vulnerability of the Web as a whole. Tolerance of errors is the necessary companion of distributed systems, and the life and breath of the Internet, not just the Web.

A Web-based mechanism for IPR information and policy expression should give rightsholders maximum choice in publishing their IPR information, and should likewise give information consumers maximum choice in discovering and interpreting that information. This does not mean that in every instance an IPR language and protocol would provide for discovery and interpretation in all channels; rather, it means that the language and protocol, through its fundamental modularity and extensibility, would provide for a variety of applications that accommodate many modes of use, if it is the choice of the parties to take advantage of these modes.

For example, some rightsholders or agents might elect to disseminate IPR information through Web services, while others might elect to bind IPR policies to information packages, perhaps with references to the network-distributed version. Binding their information to packages ensures that accessibility of the information under all circumstances, while disseminating through web services ensures that the most current information is always available the widest variety of users.

g. Cooler Multimedia: W3C's consensus process does not limit content provider creativity or mean boring browsing. Through its membership, W3C listens to end-users and works toward providing a solid framework for the development of the Cooler Web through innovative new languages.

The fundamental principle underlying IPR laws worldwide is the encouragement of innovation and the propagation of new knowledge. We believe that the W3C's highest calling is to preserve and extend this environment of innovation; W3C members must ensure that the Web is not only a place of "cool" innovation, but also a place where the innovators are fully recognized. So mechanisms for IPR policy expression and enforcement must be complementary to new forms of expression that emerge; cool new languages should not "break" or inhibit IPR languages and protocols, and visa versa.

3. The Policy and Rights Expression Platform (PREP)

The following set of principles was inspired by the W3C's previous work in the privacy domain, especially the background work by Joseph Reagle, and is consistent with the Design Principles of the Web. We propose these as the starting point for a W3C Recommendation directed at IPR policy expression and enforcement for Web-based information:

a. PREP should enable digital content providers to express IPR policy assertionsin a standard format that can be retrieved automatically and interpreted easily by user agents and client services.

b. PREP should enable users and services to be informed of rightsholders' IPR policies in both machine- and human-readable formats, and to automate decision-making based on these policies when appropriate

c. PREPshould enablethe implementation of standardized technical mechanisms for ensuring that users and services are informed about rightsholders IPR policies prior to potentially infringing use.

d. PREPshould not provide any specific technical mechanisms for ensuring that users and services act according to those IPR policies. Products or services implementing the PREP specification (when one exists) may provide some assistance in that regard, but that is up to specific implementations and outside the scope of such a specification.

e. PREP should be complementary to laws and self-regulatory programs that can provide IPR enforcement mechanisms.

f. PREPmay include a protocol for transferring IPR information and policy expressions, but should not introduce its own mechanism for securing that information in transit or storage. PREP may be built into tools designed to facilitate data transfer. These tools should include appropriate security safeguards.

g. The aim of PREP is to increase trust and confidence in the Web as a medium for the expression, exchange and commerce for goods in which IP rights are asserted.

h. PREP should be consistent with the W3C's previous work in privacy. [P3P] Specifically, PREP should be compatible with mechanisms for declaring the degrees of identity tracking and degrees of anonymity and disclosure of identity. PREP should also be compatible with mechanisms for communicating the degree to which privacy policies are complied with.

These principles are useful for understanding in a general sense what PREP, but they only begin to give us a sense of what PREP might look like as architecture. In the final sections of this paper we will first consider previous work by the W3C in rights management for the Web community, and based on this we will propose a layered model as a way to think about PREP.

4. The PREP Architecture for IPR Policy Expression, Enforcement and Compliance

...Build a platform, or set of protocols, so that it can evolve in any number of ways; don't play God; don't hardwire any single path of development; don't build into it a middle that can meddle with its use. Keep the core simple and let the application (or end) develop the complexity...No one can control how the system will evolve. No single individual gets to set the path the system will follow. It might evolve to follow a path, but it will evolve by the collective choice of many...

Lawrence Lessig, Open Code and Open Societies (1999) [OpenCode]

At its core, we believe that PREP should provide a model defining open interfaces between three architectural levels of abstraction: rights expression languages, rights messaging protocols and mechanisms for policy enforcement and compliance.

a. Rights Expression Language(s): So-called rights languages provide the basis for expressing rights information and policies, and as such are useful for a variety of rights messaging applications including IPR information discovery, simple policy expression, rights negotiation and trading, and the expression of rights agreements and electronic contracts (eContracts). Minimally, a rights language should provide vocabulary and syntax (format) for the declarative expression of rights and rights restrictions. In order to satisfied the Design Principles of interoperability and evolvability, we would also expect a rights language to provide an open-ended way to express new rights (e.g. new operations on content, new contextual constraints).

We believe that rights languages will prove to be important enablers of interoperability in this space. Although the principles underlying IPR-specific metadata have been around since at least 1993 [Perritt], the importance of standardized vocabularies and formats for expressing IPR policies has only recently begun to be appreciated at the application level. [XRML], [ODRL]

IPR policies may be expressed at different levels of abstraction, and therefore different vocabularies will be appropriate. To avoid chaos and to facilitate interoperability, we believe that a rights language ontology is required: a set of reusable terms for the basic rights concepts that can be mapped to different syntaxes. This was the work that was begun by the <indecs> project in 1998 [indecs], and is a fundamental basis of the Open Digital Rights Language (ODRL) work by Renato Ianella. [ODRL]

This concept of interoperability through shared ontology is similar to what the ebXML working group is trying to achieve with their core components approach to building interoperable business objects. [ebXML] Following that model, existing or future IPR expression languages could interoperate through translation via this shared semantic layer, rather than necessarily forcing applications and services to use a single common language.

Finally, we caution that rights languages should not be thought of as eContracting languages; rights vouchers are not eContracts. One use of a rights language is to express the parties, terms, rights and obligations contained in eContracts. [c.f. FIRM] However, eContracts go beyond the immediate scope of PREP since they require complex, dynamic behavior, not just declarative expression of state.

b. Rights Messaging Protocol: PREP should define a rights messaging protocol (RMP) that would provide the means for inquiring about and disseminating IPR information and policies; it may also include a means for determining an agent's capabilities for enforcement or compliance with particularIPR policies. The compliance aspect of an RMP would permit intermediaries or agents to describe any IPR tracking they use, and the types and strengths of enforcement mechanisms they are able or prepared to offer. [c.f. CC/PP] Some elements of this IPR information, supplied independently of the primary content stream, would allow consumers (or agents operating on their behalf) to decide whether to enter an agreement; other elements would enable publishers or intermediaries to determine whether to pass along information items on the basis of that information.

In [RightsTalk] I proposed an Open Rights Management Interoperability Framework, which was intended to be a way to exchange rights messages between peer applications, primarily by way of web-published services. The RightsTalk concept was not meant to target a particular sector; one could see it working as well for business-to-business messaging (e.g. sub-rights transactions) as it could for business-to-consumer (e.g. IPR policy expression) or consumer-to-business (e.g. IPR policy discovery, authorization queries). The important aspect of the RightsTalk concept was that interoperability between services and applications could be established by defining an extensible set of standardized rights messages and a standard way for handling those messages, including their sequencing and routing to applications.

c. Mechanisms for Policy Enforcement (DRM): PREP should not specify a particular IPR policy enforcement mechanism, but rather should provide a set of open APIs that will enable a competitive market in the provision of enforcement methods. PREP should provide a way to register sets of bindings that tie the leaves (or certain expressive elements) of rights expression languages into commercial transactions or other enforcement or compliance mechanisms. This ability to associate expressive vocabulary with technical mechanisms provides operational semantics to the declarative platform for rights expression.

PREP's policy-enforcement architecture will eventually have to accommodate the strict enforcement of policies in situations other than end use; examples are prevalent within the domain of b2b rights trading, where a publisher-to-distributor deal might stipulate that subsequent deals, involving rights assigned by the primary deal, are not authorized without (for example) a particular crypto-based token. Policy-compliant deal engines will understand this policy expression and will enforce the policy appropriately. The affordances in the PREP architecture for policy-enforcement do not need to specify the nature of such tokens, only accommodate them.

The establishment of technical enforcement API standards may be out of scope for W3C, but it is an important problem none-the-less; although it may be possible for b2b services to run on legal enforcement and trust, most stakeholders believe that for b2c some means of technical enforcement will be needed. It therefore might be useful for the W3C to make recommendations in the following areas, specific to technical mechanisms:

The W3C could recommend a standardized interface for passing authorization tokens to a web server for rights enforcement at the server end, similar to digest authentication but in this case referencing a rights description. [c.f. Digest]

The W3C could recommend a generalized secure container, to support enforcement at the client end. This could be a common, open content presentation format, functioning like a DRM meta-container, that would enable vendors to co-exist with differentiated solutions, but yet would provide application developers and users with a uniform, extensible interface. Such a meta-container or policy enforcement envelope would unambiguously guide a standard envelope handler to call the appropriate DRM mechanism. From the envelope processor's perspective, all DRM mechanisms would be equally accessible. For DRM vendors, this would seem to be ideal: each would be "inside" any application that would adopt the format.

These are merely suggestions, meant to serve as examples of areas to explore at the DRM Workshop and in subsequent discussions of the Working Group.

5. Conclusion

In this position paper we have suggested that the W3C should work toward a recommendation for a platform for IPR policy expression, discovery and interpretation; we have suggested the name Policy and Rights Expression Platform (PREP). Applying the W3C's Design Principles, PREP would provide a reliable way to express and transfer rights information, and could serve as an open interface for mechanisms for policy compliance and enforcement. From an IPR policy perspective, what the Web community needs first is a consistent and reliable mechanism for policy expression and discovery, with mechanisms for enforcement and compliance considered later as extensions.

6. References and Further Reading

[CC/PP] Mikael Nilsson et.al., Composite Capabilities/Preference Profiles (CC/PP): Requirements and Architecture. See http://www.w3.org/TR/2000/WD-CCPP-ra-20000721/

[Digest] H. Franks et.al., HTTP Authentication: Basic and Digest Access Authentication, IETF Internet-Draft (September 1998). See http://hopf.math.northwestern.edu/digestauth/draft.rfc

[DublinCore] The Dublin Core Metadata Initiative. See http://www.oclc.org/oclc/research/projects/core/index.htm

[EBX] The EBX Specification. See http://www.ebxwg.org/pdfs/spec.pdf

[ebXML] ebXML technical Architecture Specification, v0.9 (October 2000). See http://www.ebxml.org/specdrafts/ebXML_TA_v0.9.pdf

[FIRM] R. Martin Roscheisen, A Network-Centric Design For Relationship-Based Rights Management, Ph.D. Dissertation (Stanford University, 1997). http://pcd.stanford.edu/rmr/commpacts.html

[RightsTalk] John S. Erickson, Toward an Open Rights Management Interoperability Framework (June 1999). See http://www.oasis-open.org/cover/ericksonRT19990624.pdf

[KhareReagle] Rohit Khare & Joseph Reagle, Panel 3: Rights Management, Copy Detection, and Access Control, NRC/CSTB/Information Systems Trustworthiness Project. See http://www.w3.org/IPR/work/NRC-v1.htm

[indecs] Godfrey Rust and Mark Bide, The <indecs> Metadata Framework (June 2000). See http://www.indecs.org/pdf/framework.pdf

[ODRL] Renato Iannella, Open Digital Rights Language Specification v0.8. See http://odrl.net/ODRL-08.pdf

[OeB] Open eBook Publication Structure. See http://www.openebook.org/specification.htm

[P3P] Platform for Privacy Preferences (P3P) Project. See http://www.w3.org/P3P/

[P3PDataXfer] P3P Working Group, Removing Data Transfer from P3P. See http://www.w3.mag.keio.ac.jp/P3P/data-transfer.html

[P3P1.0] The Platform for Privacy Preferences 1.0 Specification. See http://www.w3.org/TR/P3P/

[Perritt] Henry W. Perritt, Jr. Knowbots, Permissions Headers and Contract Law, Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Environment, April 1993. See http://www.ifla.org/documents/infopol/copyright/perh2.txt

[TCPA] Trusted Computing Platform Alliance (TCPA) Specification v0.9. See http://www.trustedpc.org/home/Specification.htm

[W3C7Points] W3C, The W3C in 7 Points.

[XRML] ContentGuard, Inc., XrML White Paper. See http://www.xrml.org/white_paper.htm

Valid HTML 4.01!