1 / 20

John S. Erickson, Ph.D. Hewlett-Packard Laboratories Publishing Systems & Solutions

Principles for Standardization and Interoperability in Web-based Digital Rights Management W3C Workshop on Digital Rights Management January 2001 Sophia Antipolis, France. John S. Erickson, Ph.D. Hewlett-Packard Laboratories Publishing Systems & Solutions.

Download Presentation

John S. Erickson, Ph.D. Hewlett-Packard Laboratories Publishing Systems & Solutions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Principles for Standardizationand Interoperability inWeb-based Digital Rights ManagementW3C Workshop on Digital Rights ManagementJanuary 2001Sophia Antipolis, France John S. Erickson, Ph.D. Hewlett-Packard Laboratories Publishing Systems & Solutions w3c_jse_jan01..ppt

  2. Summary: W3C should recommend a “platform” • W3C should recommend a “platform” (esp. a language and a protocol) for IPR policy expression, discovery and interpretation • W3C should not recommend a standardized digital rights management (DRM) system. But the W3C should provide a basis for interoperability for such systems • Core of W3C’s recommendation should be reliable way to express and transfer rights information, • Providing for open interface for mechanisms for policy interpretation, e.g. enforcement, compliance • Any W3C recommendation should build upon current work in advanced metadata expression, discovery and transport • From an IPR policy perspective, Web community first needs a consistent and reliable mechanism for policy expression and discovery • mechanisms for enforcement and compliance may be added later, as extensions w3c_jse_jan01.ppt

  3. DRM & the Design Principles of the Web* • IPR Expression and interpretation … • must never interfere with users abilities to discover the information they are looking for on the Web • should always communicate in understandable language the policies under which users are allowed to use the information, as well as any 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 Universal Access Trust Interoperability Semantic Web Decentralization Evolvability Cool Multimedia * http://www.w3.org/Consortium/ w3c_jse_jan01.ppt

  4. DRM & the Design Principles of the Web* • Users will want applicable IPR policies to be considered when they (or agents acting on their behalf) search for information • e.g. an aspect of what we are looking for might be what we have a right to access, in a particular way. • Therefore: • IPR policies must be expressed in ways that are consistent with other metadata sources and expression mechanisms on the Web • 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. Universal Access Trust Interoperability Semantic Web Decentralization Evolvability Cool Multimedia * http://www.w3.org/Consortium/ w3c_jse_jan01.ppt

  5. DRM & the Design Principles of the Web* • Languages and protocols are useless unless users have a basis for trusting the assertions, and can be confident in the integrity of the mechanisms that provide them with the information. • 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 B2B and 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. [c.f. P3P] Universal Access Trust Interoperability Semantic Web Decentralization Evolvability Cool Multimedia * http://www.w3.org/Consortium/ w3c_jse_jan01.ppt

  6. DRM & the Design Principles of the Web* • IPR information and policies must be discoverable and minimally interpretable in ways that are independent from any particular vendor's solution • 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 • Anyone 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. Universal Access Trust Interoperability Semantic Web Decentralization Evolvability Cool Multimedia * http://www.w3.org/Consortium/ w3c_jse_jan01.ppt

  7. DRM & the Design Principles of the Web* • 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 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 for interpreting IPR information and policies must be flexible enough to capture the sociological evolution of the IPR environment. Universal Access Trust Interoperability Semantic Web Decentralization Evolvability Cool Multimedia * http://www.w3.org/Consortium/ w3c_jse_jan01.ppt

  8. DRM & the Design Principles of the Web* • A Web-based mechanism for IPR information and policy expression should give rightsholdersmaximum choice in publishing their IPR information • 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 accommodate many modes of use Universal Access Trust Interoperability Semantic Web Decentralization Evolvability Cool Multimedia * http://www.w3.org/Consortium/ w3c_jse_jan01.ppt

  9. DRM & the Design Principles of the Web* • The principle underlying IPR laws worldwide is the encouragement of innovation and the propagation of new knowledge • 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 web languages should not "break" or inhibit IPR languages and protocols, and visa versa. Universal Access Trust Interoperability Semantic Web Decentralization Evolvability Cool Multimedia * http://www.w3.org/Consortium/ w3c_jse_jan01.ppt

  10. Proposed Name:The Policy and Rights Expression Platform (PREP) w3c_jse_jan01.ppt

  11. What PREP should and should not be (1 of 2) • PREP should enable digital content providers to express IPR policy assertions in a standard format that can be retrieved automatically and interpreted easily by user agents and client services. • 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 • PREP should enable the implementation of standardized technical mechanisms for ensuring that users and services are informed about rightsholders IPR policies prior to potentially infringing use • PREP should not provide any specific technical mechanisms for ensuring that users and services act according to those IPR policies. • Products/services implementing a PREP recommendation may provide some assistance in that regard, but that is up to specific implementations and outside the scope of such a recommendation w3c_jse_jan01.ppt

  12. What PREP should and should not be (2 of 2) • PREP should be complementary to laws and self-regulatory programs that can provide IPR enforcement mechanisms. • PREP may include a protocol for transferring IPR information and policy expressions, but should not specify 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. • PREP should help 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. • PREP should be consistent with the W3C's previous work in privacy. [c.f. 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. w3c_jse_jan01.ppt

  13. Building Blocks of PREP Policy Interpretation Mechanisms Semantics Rights Messaging Protocol Objects Rights Expression Languages Syntax w3c_jse_jan01.ppt

  14. Rights Expression Languages • 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. • Begun by <indecs>, basis of ODRL • Sometimes called a “rights dictionary” • Interoperability through shared ontologyis similar to ebXML • core components for building interoperable business objects. • Existing and 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. w3c_jse_jan01.ppt

  15. Thinking about a Rights Ontology:The Semantic Web “Stack” (Tim Berners-Lee) w3c_jse_jan01.ppt

  16. Rights Messaging Protocol (RMP) • Would provide the means for inquiring about, disseminating IPR information and policies • Might include a means for discovering an agent's capabilities for enforcement or compliance with particular IPR policies. • Compliance aspect of 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 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 w3c_jse_jan01.ppt

  17. Rights Messaging Protocol (RMP) Open Rights Management Interoperability Framework* • Conceived as a way to exchange rights messages between peer applications, primarily by way of web-published services • Not meant to target a particular sector • business-to-business messaging (e.g. sub-rights transactions) • business-to-consumer (e.g. IPR policy expression) • consumer-to-business (e.g. IPR policy discovery, authorization queries) • Interoperability between services and applications could be established by defining: • extensible set of standardized rights messages • standard way for handling those messages, including sequencing and routing to applications. * http://www.oasis-open.org/cover/ericksonRT19990624.pdf w3c_jse_jan01.ppt

  18. Policy Interpretation Mechanisms (DRM) • PREP should notspecify a particular IPR policy enforcement mechanism • Shouldprovide 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. • The ability to associate expressive vocabulary with technical mechanisms provides operational semantics to the declarative platform for rights expression w3c_jse_jan01.ppt

  19. Policy Interpretation Mechanisms (DRM) • PREP's policy-enforcement architecture must eventually accommodate the strict enforcement of policies in situations other than end use • Example: B2B Rights Trading • 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 • Affordances in the PREP architecture for policy-enforcement do not need to specify the nature of such tokens, only accommodate them. w3c_jse_jan01.ppt

  20. Example Recommendations (DRM) • 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* • 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 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 * c.f. http://hopf.math.northwestern.edu/digestauth/draft.rfc w3c_jse_jan01.ppt

More Related