Network Working Group M. Mealling Internet-Draft VeriSign, Inc. Expires: May 14, 2002 November 13, 2001 Digital Rights Management Using the URI Resolution DDDS Application draft-irtf-idrm-uri-res-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 14, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This documenet describes how the URI Resolution DDDS Application plus the RESCAP protocol can be utilized as a digital rights publication platform. 1. Introduction Many of the existing and developing digital rights management platforms suffer from being very vertical solutions in a world that is moving toward general metadata services of which rights metadata is just one small part. This document proposes that digital rights be published via a RESCAP service that is discovered via the URI Resolution DDDS application. By virtue of URI Resolution being a Mealling Expires May 14, 2002 [Page 1] Internet-Draft DRM via the DDDS November 2001 general case for all URIs, it becomes possible for a DRM solution to deployed for all resolvable URI schemes. 2. URI Resolution The URI Resolution DDDS Application defined in RFC YYYY [3] allows for the easy discovery of services associated with URIs in a dynamic, out of band mechanism. Using that DDDS Application it is possible to find a server that can answer rights and policy questions for any resolvable URI scheme (local context dependent schemes cannot be resolved globally). One question to be answered: the URI Resolution application defines the 'I2C' (URI to Characteristics) service as the default service for complex metadata queries. Is that sufficent for a DRM application or is a further qualified service distinction (I2DRM?) needed to differentiate policy from general metadata? The URI Resolution application only provides the DRM metadata discovery portion of the solution. It does not provide a way of asking DRM related questions. It does provide for the use of multiple protocols and services in the case where some vertical or proprietary solution desires to be discoverable. But the current state of the art is that none of the currently available solutions provide for a general purpose query protocol. 3. RESCAP This document suggests that the use of the RESCAP [2] protocol is appropriate for small and/or discrete chunks of DRM metadata. The protocol as proposed is a lightweight, secure and extensible protocol for requesting attributes and values associated with some URI. Examples include: o file sizes o availability (mailbox is full, file not available, etc) o relationships to other URIs (mirrors, collections, etc) o capabilities (can display postscript, Unicode capable viewer, etc) Many pieces of DRM related metadata fall into this lightweight model since many items can easily fit into one or two UDP packets, still keeping round trip times lower than those needed to even setup the TCP session for protocols such as HTTP. The main problem to solve is the management of the attribute Mealling Expires May 14, 2002 [Page 2] Internet-Draft DRM via the DDDS November 2001 namespace. The RESCAP protocol is based on attributes and their values being associated with the URI. The intent is that complexity of metadata is kept opaquely inside an attribute's value. Thus, DRM metadata would not exist as specific attribute value pairs, but instead would exist as an opaque attribute value. RESCAP's proposed attribute naming structure would suggest the top level be 'drm' for Digital Rights Management. Subdelegations below that would be up for discussion. At a minimum the author suggests that two levels be created: o drm.defaults -- includes IETF standardized DRM attributes and values. For example: * drm.default.rights-holders * drm.default.rights-holders.author * drm.default.rights-holders.producer * drm.default.rights-holders.performer o drm. -- includes non-IETF DRM systems. For example: * drm.indecs.role.agent.creator * drm.indecs.input.sourceCreation * drm.mpeg7.financial.payment * drm.odrl.permission.display The management of these attribute names and their granularity is the area that needs the most work. The fundamental question is: will the world of IDRM involve small pieces of metadata intermingling or will applications be vertical enough that entire blobs of metadata will be retrieved as one large, indivisible chunk? References [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [2] Moore, K., "The Binary Low-Overhead Block Presentation Protocol", draft-moore-rescap-rc-01.txt (work in progress), June 2001. [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application", RFC YYYY, draft-ietf-urn- Mealling Expires May 14, 2002 [Page 3] Internet-Draft DRM via the DDDS November 2001 uri-res-ddds-05.txt (work in progress), October 2000. Author's Address Michael Mealling VeriSign, Inc. Sterling, CA US URI: http://www.verisignlabs.com Mealling Expires May 14, 2002 [Page 4] Internet-Draft DRM via the DDDS November 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mealling Expires May 14, 2002 [Page 5]