From thardjono@mediaone.net Sun May 20 04:51:11 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:51:11 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] CfP, Workshop on Security and Privacy in Digital Rights Manageme nt 2001 (fwd) Message-ID: <5.0.0.25.2.20010519235052.024691f0@pop.ne.mediaone.net> >Date: Fri, 23 Mar 2001 11:37:19 -0500 (EST) >From: Judie Mulholland >Subject: [IDRM] CfP, Workshop on Security and Privacy in Digital Rights > Manageme nt 2001 (fwd) >To: ietf-idrm@lists.elistx.com, www-drm@w3.org >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >fyi/j > >ps > >sorry for the cross-posting. > > >--- begin forwarded text > > >From: Tomas Sander >Subject: CfP, Workshop on Security and Privacy in Digital Rights Manageme > nt 2001 >Date: Mon, 19 Mar 2001 17:03:19 -0800 > > > CALL FOR PAPERS > > WORKSHOP ON SECURITY AND PRIVACY IN DIGITAL RIGHTS MANAGEMENT 2001 > > November 5, 2001 > Philadelphia, Pennsylvania, USA > > held as part of the Eighth ACM Conference on Computer and > Communications Security (CCS-8) > > Workshop web site: http://www.star-lab.com/sander/spdrm/ > > >Increasingly the Internet is used for the distribution of digital >goods, including digital versions of books, articles, music and >images. The ease with which digital goods can be copied and >redistributed make the Internet well suited for unauthorized copying, >modification and redistribution. The rapid adoption of new >technologies such as high bandwidth connections and peer-to-peer >networks is accelerating this process. > >This workshop will consider technical problems faced by rights holders >(who seek to protect their intellectual property rights) and end >consumers (who seek to protect their privacy and to preserve access >they now enjoy in traditional media under existing copyright law). > >Digital Rights Management (DRM) systems are supposed to serve mass >markets, in which the participants have conflicting goals and cannot >be fully trusted. This adversarial situation introduces interesting >new twists on classical problems studied in cryptology and security >research, such as key management and access control. Furthermore, >novel business models and applications often require novel security >mechanisms. Recent research has also proposed new primitives for DRM, >such as hash functions that make it possible to identify content in an >adversarial setting. > >The workshop seeks submissions from academia and industry presenting >novel research on all theoretical and practical aspects of DRM, as >well as experimental studies of fielded systems. We encourage >submissions from other communities such as law and business that >present these communities' perspectives on technological issues. It is >planned to publish accepted papers in proceedings in the Springer >Lecture Notes in Computer Science (LNCS) series. > >Topics of interest include, but are not limited to, the following, as >they relate to digital rights management: > > access control mechanisms for digital rights > anonymous publishing > architectures for DRM systems > auditing and piracy > broadcast encryption and traitor tracing > business models and their security requirements > electronic commerce protocols > encryption and authentication for multimedia data > fair use > key management in DRM systems > payment mechanisms > peer-to-peer networks > portability of digital rights > privacy and anonymity > privacy-preserving data mining > risk management > robust identification of digital content > security for auctions and other emerging business models for > digital goods > security models > software tamper resistance > tamper resistant hardware and consumer devices > threat and vulnerability assessment > trust management > usability aspects of client software, consumer devices > watermarking and fingerprinting for media and software > > > IMPORTANT DATES > >Submission deadline August 3, 2001 >Acceptance notification September 7, 2001 > > > > PROGRAM CHAIR > >Tomas Sander, InterTrust STAR Lab >sander@intertrust.com, +1-408-855 0242 > > > > PROGRAM COMMITTEE > >Eberhard Becker, University of Dortmund >Dan Boneh, Stanford University >Karlheinz Brandenburg, Fraunhofer Institute for Integrated Circuits >Leonardo Chiariglione, CSELT >Drew Dean, Xerox PARC >Joan Feigenbaum, Yale University >Edward Felten, Princeton University >Yair Frankel, eCash Technologies >Markus Jakobsson, Bell Labs >Paul Kocher, Cryptography Research >John Manferdelli, Microsoft Research >Kevin McCurley, IBM Research >Moni Naor, Weizmann Institute >Fabien Petitcolas, Microsoft Research >Pamela Samuelson, University of California, Berkeley >Hal Varian, University of California, Berkeley >Moti Yung, CertCo > > > > PAPER SUBMISSIONS > >Submitted papers must not substantially overlap with papers that have >been published or that are simultaneously submitted to a journal or a >conference with proceedings. Papers should be at most 18 pages >excluding the bibliography and well-marked appendices (using 11-point >font and reasonable margins), and at most 22 pages total. Committee >members are not required to read the appendices and the paper should >be intelligible without them. The paper should start with the title, >names of authors and an abstract. The introduction should give some >background and summarize the contributions of the paper at a level >appropriate for a non-specialist reader. It is planned to publish >accepted papers in proceedings in the Springer Lecture Notes in >Computer Science (LNCS) series after the workshop. During the >workshop preproceedings will be made available. Final versions are not >due until after the workshop, giving the authors the opportunity to >revise their papers based on discussions during the meeting. > >Submissions can be made in Postscript, PDF or MS Word format. To >submit a paper, send a plain ASCII text email to the program chair >(email: sander@intertrust.com) containing the title and abstract of >the paper, the authors' names, email and postal addresses, phone and >fax numbers, and identification of the contact author. To the same >message, attach your submission (as a MIME attachment). Papers must be >received by August 3, 2001. Notification of acceptance or rejection >will be sent to authors no later than September 7, 2001. Authors of >accepted papers must guarantee that their paper will be presented at >the workshop. Final versions (due after the workshop) need to comply >with the instructions for authors made available by Springer. > > > > > >--- end forwarded text > > >-- >----------------- >R. A. Hettinga >The Internet Bearer Underwriting Corporation >44 Farquhar Street, Boston, MA 02131 USA >"... however it may deserve respect for its usefulness and antiquity, >[predicting the end of the world] has not been found agreeable to >experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' > >For help on using this list (especially unsubscribing), send a message to >"dcsb-request@reservoir.com" with one line of text: "help". From thardjono@mediaone.net Sun May 20 04:53:23 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:53:23 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] Web site up Message-ID: <5.0.0.25.2.20010519235317.01b96730@pop.ne.mediaone.net> >Date: Fri, 23 Mar 2001 13:17:15 -0500 >From: Thomas Hardjono >Subject: [IDRM] Web site up >X-Sender: thardjono@pop.ne.mediaone.net >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >Folks, > >The IDRM page is up at www.idrm.org. > >Still basic, but more pages will be added soon. > >cheers, > >thomas >------ From thardjono@mediaone.net Sun May 20 04:53:36 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:53:36 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] Summary report of 1st IDRM Research Group meeting Message-ID: <5.0.0.25.2.20010519235332.01b97200@pop.ne.mediaone.net> >Date: Sat, 24 Mar 2001 11:04:36 -0800 >From: Mark Baugher >Subject: [IDRM] Summary report of 1st IDRM Research Group meeting >X-Sender: mbaugher@mira-sjc5-6.cisco.com >To: ietf-idrm@lists.elistx.com >Cc: Erik Huizer , club-scud@cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >hi > We have a temporary site for posting the minutes, presentations >and results of our first meeting. I'd appreciate it if you would >review the pages and files on the site and report any problems. >http://www.rdrop.com/users/mbaugher/IDRM/ >is the temporary location. Thomas will be moving these >files to the RG web site when he gets it established. > >Cheers, Mark From thardjono@mediaone.net Sun May 20 04:53:47 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:53:47 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] Page updated + add your links Message-ID: <5.0.0.25.2.20010519235342.01b553e0@pop.ne.mediaone.net> >Date: Sun, 25 Mar 2001 10:48:52 -0500 >From: Thomas Hardjono >Subject: [IDRM] Page updated + add your links >X-Sender: thardjono@pop.ne.mediaone.net >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >Folks, > >The www.idrm.org site has been updated with the minutes and slides >from the meeting. > >Also added is a page for the collection of links/URLs. >I have just put a few there (the ones I remembered off-hand). > >If you know of others or wish to have your organization/project/website/papers >listed, just email them to me. > >cheers, > >thomas >------ From thardjono@mediaone.net Sun May 20 04:53:56 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:53:56 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] napster goes to washington! Message-ID: <5.0.0.25.2.20010519235353.01b93a80@pop.ne.mediaone.net> >Date: Wed, 28 Mar 2001 09:21:28 -0500 (EST) >From: Judie Mulholland >Subject: [IDRM] napster goes to washington! >To: ietf-idrm@lists.elistx.com >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >fyi/j > >there will be a hearing before the us senate on april 3rd that should >prove interesting, especially in light of orin hatch's comments after the >napster decision re: the prospect of compulsory licensing. > >The Senate Committee on the Judiciary will hold a hearing on >Tuesday, April 3, 2001 at 10:00 a.m. in Dirksen Room 226, on >"Online Entertainment and Copyright Law: Coming Soon to a Digital >Device Near You." > >http://www.senate.gov/~judiciary/ > >plus, some other links that may be of interest: > >http://www.napster.com/speakout/ac/ > >http://www.senate.gov/~judiciary/ogh021401nap.htm > >http://www.futureofmusic.org/ > > >Ph.D. Candidate Voice: (850) 942-1628 >School of Information Studies Fax: (850) 942-0709 >Florida State University Mobile: (850) 322-8546 >Tallahassee, FL 32306 From thardjono@mediaone.net Sun May 20 04:54:06 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:54:06 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] Charter now up on IRTF page Message-ID: <5.0.0.25.2.20010519235404.01b55030@pop.ne.mediaone.net> >Date: Thu, 29 Mar 2001 16:22:51 -0500 >From: Thomas Hardjono >Subject: [IDRM] Charter now up on IRTF page >X-Sender: thardjono@pop.ne.mediaone.net >To: ietf-idrm@lists.elistx.com >Cc: mbaugher@cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >Hi, > >The IDRM charter is finally up on the IRTF page. > >Here is the link: > >http://www.irtf.org/charters/Digital-Rights-Management.html > > >cheers, > >thomas >------ From thardjono@mediaone.net Sun May 20 04:54:18 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:54:18 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] Interesting piece on DRM standardization Message-ID: <5.0.0.25.2.20010519235416.01b973f0@pop.ne.mediaone.net> >Date: Wed, 11 Apr 2001 22:47:39 -0700 >From: Thomas Hardjono >Subject: [IDRM] Interesting piece on DRM standardization >X-Sender: thardjono@pop.ne.mediaone.net >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >Folks, > >Here's an interesting piece on the need to standardize DRM. >Its from Seybold-Boston, which is happening this week. > >http://www.key3media.com/seyboldseminars/boston2001/daily/features/drm_publish.html > >cheers, > >thomas >------ From thardjono@mediaone.net Sun May 20 04:54:33 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:54:33 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] Fw: [DOI-EB] Meeting Times Message-ID: <5.0.0.25.2.20010519235431.01b6d1a0@pop.ne.mediaone.net> >Date: Wed, 18 Apr 2001 05:38:24 -0400 >From: "Sam X. Sun (@S2000)" >Subject: [IDRM] Fw: [DOI-EB] Meeting Times >To: ietf-idrm@lists.elistx.com >X-Mailer: Microsoft Outlook Express 5.50.4133.2400 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >FYI. This is the DOI-Ebook working group meeting I mentioned last time. >Steve Mooney, who is chairing the working group, told me that anyone in >our working group are welcomed to join their meeting if you let him know >in advance. You can find more about their work from >http://www.doi.org/ebooks.html. > > >Thanks, >Sam > > >----- Original Message ----- >From: Steve Mooney >To: DOI-EB >Sent: Monday, April 16, 2001 2:00 PM >Subject: [DOI-EB] Meeting Times > >The meeting on the 26th will begin at 10 and conclude at 4. If you have >not confirmed your attendance, please send me an email. > >The meeting will take place at McGraw Hill in New York, and specifics on >the venue will follow in a couple of days. > >Thank you. From thardjono@mediaone.net Sun May 20 04:54:43 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:54:43 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] MPAA is going after gnutella Message-ID: <5.0.0.25.2.20010519235440.01b97830@pop.ne.mediaone.net> >Date: Wed, 18 Apr 2001 13:37:35 -0400 (EDT) >From: Judie Mulholland >Subject: [IDRM] MPAA is going after gnutella >To: ietf-idrm@lists.elistx.com >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >fyi/j > >Action! Piracy clampdown targets movies > >By Lisa M. Bowman >ZDNet News >April 17, 2001 1:31 PM PT > >The movie industry is training its legal guns on the Gnutella file-sharing >system in its latest efforts to combat piracy. > >The Motion Picture Association of America (MPAA) has sent hundreds of >letters to major Internet service providers and universities, warning them >that some people on their networks are violating the Digital Millennium >Copyright Act (DMCA) by trading copyrighted movies through Gnutella. > > >the rest of the article can be found at: > >http://www.zdnet.com/zdnn/stories/news/0,4586,5081293,00.html From thardjono@mediaone.net Sun May 20 04:54:58 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:54:58 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] MPAA is going after gnutella Message-ID: <5.0.0.25.2.20010519235455.01b557e0@pop.ne.mediaone.net> >Date: Wed, 18 Apr 2001 11:18:28 -0700 >From: Mark Baugher >Subject: Re: [IDRM] MPAA is going after gnutella >X-Sender: mbaugher@mira-sjc5-6.cisco.com >To: Judie Mulholland >Cc: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >hi Judie, > >http://www.law.wayne.edu/litman/papers/demon.pdf >discusses this practice of "demonizing" piracy. But how >does the MPAA know that Gnutella or Freenet users are >swapping copyright movies without snooping the contents >of files being exchanged? I think the digital rights and >personal privacy issues are very closely related for >us in IDRM. > >thanks, Mark > >At 01:37 PM 4/18/2001 -0400, Judie Mulholland wrote: >>fyi/j >> >>Action! Piracy clampdown targets movies >> >>By Lisa M. Bowman >>ZDNet News >>April 17, 2001 1:31 PM PT >> >>The movie industry is training its legal guns on the Gnutella file-sharing >>system in its latest efforts to combat piracy. >> >>The Motion Picture Association of America (MPAA) has sent hundreds of >>letters to major Internet service providers and universities, warning them >>that some people on their networks are violating the Digital Millennium >>Copyright Act (DMCA) by trading copyrighted movies through Gnutella. >> >> >>the rest of the article can be found at: >> >>http://www.zdnet.com/zdnn/stories/news/0,4586,5081293,00.html From thardjono@mediaone.net Sun May 20 04:55:10 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:55:10 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] MPAA is going after gnutella Message-ID: <5.0.0.25.2.20010519235508.01b534b0@pop.ne.mediaone.net> >Date: Wed, 18 Apr 2001 14:37:35 -0400 (EDT) >From: Judie Mulholland >Subject: Re: [IDRM] MPAA is going after gnutella >To: Mark Baugher >Cc: ietf-idrm@lists.elistx.com >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >On Wed, 18 Apr 2001, Mark Baugher wrote: > > > hi Judie, > > > > http://www.law.wayne.edu/litman/papers/demon.pdf > > discusses this practice of "demonizing" piracy. But how > > does the MPAA know that Gnutella or Freenet users are > > swapping copyright movies without snooping the contents > > of files being exchanged? I think the digital rights and > > personal privacy issues are very closely related for > > us in IDRM. > > > >i totally agree which reminds me of a comment first made by kelsey and >schneir. in a slightly different context, they write that trying to >prevent copyright infringement of digital assets is beginning the resemble >"the war on drugs." > >Kelsey, J. and B. Schneier "The Street Performer Protocol and Digital >Copyrights," 4 First Monday, (June 7, 1999) > >URL: http://firstmonday.org/issues/issue4_6/kelsey/index.html > >and thanks for the reference to the article on the demonization of >piracy. i look forward to reading it. > >/j From thardjono@mediaone.net Sun May 20 04:55:19 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:55:19 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] erickson article on rights management Message-ID: <5.0.0.25.2.20010519235516.01b95ae0@pop.ne.mediaone.net> >Date: Thu, 19 Apr 2001 13:11:32 -0400 (EDT) >From: Judie Mulholland >Subject: [IDRM] erickson article on rights management >To: ietf-idrm@lists.elistx.com >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >fyi/j > > >D-Lib Magazine >April 2001 >Volume 7 Number 4 > >Information Objects and Rights Management: A Mediation-based Approach to >DRM Interoperability >John S. Erickson > >http://www.dlib.org/dlib/april01/erickson/04erickson.html From thardjono@mediaone.net Sun May 20 04:55:27 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:55:27 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] Fwd: SDMI demands Princeton prof "destroy" paper about vulnerability Message-ID: <5.0.0.25.2.20010519235524.01b6fca0@pop.ne.mediaone.net> >Date: Sat, 21 Apr 2001 09:44:29 -0700 >From: Thomas Hardjono >Subject: [IDRM] Fwd: SDMI demands Princeton prof "destroy" paper about > vulnerability >X-Sender: thardjono@pop.ne.mediaone.net >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >From: John Young >Subject: RIAA Warns SDMI Hackers >To: cypherpunks@lne.com >Date: Fri, 20 Apr 2001 22:36:45 -0400 > >RIAA and The SDMI Foundation on April 9 warned Ed Felten >and his researchers not to publish their paper about the >weaknesses of the SDMI content protection system at the >4th International Information Hiding Workshop to be held >April 25-29, 2001. Their paper is public: > > http://cryptome.org/sdmi-attack.htm (41K text with 11 images) > >Zipped text and images: > > http://cryptome.org/sdmi-attack.zip (328K) > >*********** > >http://cryptome.org/sdmi-attack.htm > > April 9, 2001 > > Professor Edward Felton > Department of Computer Science > Princeton University > Princeton, NY 08544 > > Dear Professor Felten, > > We understand that in conjunction with the 4th International > Information Hiding Workshop to be held April 25-29, 2001, you and your > colleagues who participated in last year's Secure Digital Music > Initiative ("SDMI") Public Challenge are planning to publicly release > information concerning the technologies that were included in that > challenge and certain methods you and your colleagues developed as > part of your participation in the challenge. On behalf of the SDMI > Foundation, I urge you to reconsider your intentions and to refrain > from any public disclosure of confidential information derived from > the Challenge and instead engage SDMI in a constructive dialogue on > how the academic aspects of your research can be shared without > jeopardizing the commercial interests of the owners of the various > technologies. > > As you are aware, at least one of the technologies that was the > subject of the Public Challenge, the Verance Watermark, is already in > commercial use and the disclosure of any information that might assist > others to remove this watermark would seriously jeopardize the > technology and the content it protects.1 Other technologies that were > part of the Challenge are either likewise in commercial use or could > be could be utilized in this capacity in the near future. Therefore, > any disclosure of information that would allow the defeat of those > technologies would violate both the spirit and the terms of the > Click-Through Agreement (the "Agreement"). In addition, any disclosure > of information gained from participating in the Public Challenge would > be outside the scope of activities permitted by the Agreement and > could subject you and your research team to actions under the Digital > Millennium Copyright Act ("DCMA"). > > ____________________ > > 1 The Verance Watermark is currently used for DVD-Audio and SDMI > Phase I products and certain portions of that technology are trade > secrets. > > We appreciate your position, as articulated in the Frequently Asked > Questions document, that the purpose of releasing your research is not > designed to "help anyone impose or steal anything." Further more, you > participation in the Challenge and your contemplated disclosure > appears to be motivated by a desire to engage in scientific research > that will ensure that SDMI does not deploy a flawed system. > Unfortunately, the disclosure that you are contemplating could result > in significantly broader consequences and could directly lead to the > illegal distribution of copyrighted material. Such disclosure is not > authorized in the Agreement, would constitute a violation of the > Agreement and would subject your research team to enforcement actions > under the DMCA and possibly other federal laws. > > As you are aware, the Agreement covering the Public challenge narrowly > authorizes participants to attack the limited number of music samples > and files that were provided by SDMI. The specific purpose of > providing these encoded files and for setting up the Challenge was to > assist SDMI in determining which of the proposed technologies are best > suited to protect content in Phase II products. The limited waiver of > rights (including possible DMCA claims) that was contained in the > Agreement specifically prohibits participants from attacking content > protected by SDMI technologies outside the Public Challenge. If your > research is released to the public this is exactly what could occur. > In short, you would be facilitating and encouraging the attack of > copyrighted content outside the limited boundaries of the Public > Challenge and thus places you and your researchers in direct violation > of the Agreement. > > In addition, because public disclosure of your research would be > outside the limited authorization of the Agreement, you could be > subject to enforcement actions under federal law, including the DMCA. > The Agreement specifically reserves any rights that proponents of the > technology being attacked may have "under any applicable law, > including, without limitation, the U.S. Digital Millennium Copyright > Act, for any acts not expressly authorized by their Agreement." The > Agreement simply does not "expressly authorize" participants to > disclose information and research developed through participating in > the Public challenge and such disclosure could be the subject of a > DMCA action. > > We recognize and appreciate your position, made clear throughout this > process, that it is not your intention to engage in any illegal > behavior or to otherwise jeopardize the legitimate commercial > interests of others. We are concerned that your actions are outside > the peer review process established by the Public Challenge and setup > by engineers and other experts to ensure the academic integrity of > this project. With these facts in mind, we invite you to work with the > SDMI Foundation to find a way for you to share the academic components > of your research while remaining true to your intention to not violate > the law or the Agreement. In the meantime, we urge you to withdraw the > paper submitted for the upcoming Information Hiding Workshop, assure > that it is removed from the Workshop distribution materials and > destroyed, and avoid a public discussion of confidential information. > > Sincerely, > > [Signature] > > Matthew Oppenheim, Secretary > The SDMI Foundation > > cc: Mr. Ira S. Moskowitz, Program Chair, Information Hiding Workshop, > Naval Research Laboratory > Cpt. Douglas S. Rau, USN, Commanding Officer, Naval Research > Laboratory > Mr. Howard Ende, General Counsel of Princeton > Mr. Edward Dobkin, Computer Science Department Head of Princeton > _________________________________________________________________ > >*********** From thardjono@mediaone.net Sun May 20 04:55:39 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:55:39 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] Napster Licenses Acoustic Fingerprinting Technology Message-ID: <5.0.0.25.2.20010519235532.01b95760@pop.ne.mediaone.net> >Date: Sat, 21 Apr 2001 09:49:18 -0700 >From: Thomas Hardjono >Subject: [IDRM] Napster Licenses Acoustic Fingerprinting Technology >X-Sender: thardjono@pop.ne.mediaone.net >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >http://news.excite.com/news/r/010420/12/net-tech-napster-dc > >REDWOOD CITY, Calif. (Reuters) - Embattled song-swap company Napster on > Friday said it licensed privately held Relatable's acoustic > fingerprinting technology to > help filter songs in compliance with an injunction. > > Alexandria, Va.-based Relatable's technology identifies music based on > the recordings themselves and analyzes the > acoustical properties of a recording's waveform to identify it > precisely, regardless of its audio format, bit rate or > minor signal distortion, the companies said. > > Napster's service has attracted about 60 million users who swap songs > for free by trading MP3 files, a > compression format that turns music on compact discs into small > digital files. > > The recording industry sued the company in December 1999 for copyright > infringement. Napster has recently > come under fire for its inability to block trading of copyrighted > songs completely following the issuance of a March > 5 injunction. > > Music industry officials contend that many of the thousands of titles > record labels have asked Napster to block > remain available on the system and have called for Napster to filter > its service by searching for songs with digital > fingerprint technology to analyze the content of the MP3 files. > > "We are now working closely with Relatable's engineers to coordinate > their technology with our file filtering > systems; we hope they will be a substantial part of our overall > filtering solution," said Hank Barry, chief executive of > Napster, on Friday. > > Napster said it also hopes to incorporate the technology into its > current file screening system and into a new > membership service it hopes to launch this summer. > > The labels that sued Napster include Vivendi Universal's (EAUG.PA) > Universal Music, Sony Music (6758.T), > Warner Music (AOL), EMI Group Plc (EMI.L) and Bertelsmann AG's > (BTGGga.D) BMG. From thardjono@mediaone.net Sun May 20 04:55:52 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:55:52 -0400 Subject: [IETF-IDRM] Fwd: [WM]: Re: [IDRM]/[WM] Fwd: SDMI demands Princeton prof "destroy" paper aboutvulnerability Message-ID: <5.0.0.25.2.20010519235549.01b96af0@pop.ne.mediaone.net> >Delivered-To: zeus-waterma-watermarking-list@phoebe.hosting4u.net >Date: Sat, 21 Apr 2001 16:14:07 -0500 (Eastern Standard Time) >From: "Neil F.Johnson" >To: , watermarking@watermarkingworld.org, > thardjono@mediaone.net, ietf-idrm@lists.elistx.com >Subject: [WM]: Re: [IDRM]/[WM] Fwd: SDMI demands Princeton prof "destroy" > paper aboutvulnerability >Reply-To: nfj@jjtc.com >Organization: Johnson & Johnson Technolofy Consultants, LC >Sender: watermarking-owner@watermarkingworld.org > >I belong to both the IDRM and Watermarkingworld >list groups and saw this message go across both. > >Well, I'm sure this will be a hot topic at IHW2001. >The fact that The Verance Watermark is currently >being used means that someone rushed to production >without doing all of their homework. > >I look forward to discussing the matter further >in Pittsburgh next week. > >BTW... >What if those of us who did not participate wish >to discuss the SDMI challenge? > >-- > >Neil F. Johnson >Associate Director >Center for Secure Information Systems >George Mason University >njohnson@gmu.edu > > > > > >From: John Young > >Subject: RIAA Warns SDMI Hackers > >To: cypherpunks@lne.com > >Date: Fri, 20 Apr 2001 22:36:45 -0400 > > > >RIAA and The SDMI Foundation on April 9 warned Ed Felten > >and his researchers not to publish their paper about the > >weaknesses of the SDMI content protection system at the > >4th International Information Hiding Workshop to be held > >April 25-29, 2001. Their paper is public: > > > > http://cryptome.org/sdmi-attack.htm (41K text with 11 images) > > > >Zipped text and images: > > > > http://cryptome.org/sdmi-attack.zip (328K) > > > >*********** > > > >http://cryptome.org/sdmi-attack.htm > > > > April 9, 2001 > > > > Professor Edward Felton > > Department of Computer Science > > Princeton University > > Princeton, NY 08544 > > > > Dear Professor Felten, > > > > We understand that in conjunction with the 4th International > > Information Hiding Workshop to be held April 25-29, 2001, you and your > > colleagues who participated in last year's Secure Digital Music > > Initiative ("SDMI") Public Challenge are planning to publicly release > > information concerning the technologies that were included in that > > challenge and certain methods you and your colleagues developed as > > part of your participation in the challenge. On behalf of the SDMI > > Foundation, I urge you to reconsider your intentions and to refrain > > from any public disclosure of confidential information derived from > > the Challenge and instead engage SDMI in a constructive dialogue on > > how the academic aspects of your research can be shared without > > jeopardizing the commercial interests of the owners of the various > > technologies. > > > > As you are aware, at least one of the technologies that was the > > subject of the Public Challenge, the Verance Watermark, is already in > > commercial use and the disclosure of any information that might assist > > others to remove this watermark would seriously jeopardize the > > technology and the content it protects.1 Other technologies that were > > part of the Challenge are either likewise in commercial use or could > > be could be utilized in this capacity in the near future. Therefore, > > any disclosure of information that would allow the defeat of those > > technologies would violate both the spirit and the terms of the > > Click-Through Agreement (the "Agreement"). In addition, any disclosure > > of information gained from participating in the Public Challenge would > > be outside the scope of activities permitted by the Agreement and > > could subject you and your research team to actions under the Digital > > Millennium Copyright Act ("DCMA"). > > > > ____________________ > > > > 1 The Verance Watermark is currently used for DVD-Audio and SDMI > > Phase I products and certain portions of that technology are trade > > secrets. > > > > We appreciate your position, as articulated in the Frequently Asked > > Questions document, that the purpose of releasing your research is not > > designed to "help anyone impose or steal anything." Further more, you > > participation in the Challenge and your contemplated disclosure > > appears to be motivated by a desire to engage in scientific research > > that will ensure that SDMI does not deploy a flawed system. > > Unfortunately, the disclosure that you are contemplating could result > > in significantly broader consequences and could directly lead to the > > illegal distribution of copyrighted material. Such disclosure is not > > authorized in the Agreement, would constitute a violation of the > > Agreement and would subject your research team to enforcement actions > > under the DMCA and possibly other federal laws. > > > > As you are aware, the Agreement covering the Public challenge narrowly > > authorizes participants to attack the limited number of music samples > > and files that were provided by SDMI. The specific purpose of > > providing these encoded files and for setting up the Challenge was to > > assist SDMI in determining which of the proposed technologies are best > > suited to protect content in Phase II products. The limited waiver of > > rights (including possible DMCA claims) that was contained in the > > Agreement specifically prohibits participants from attacking content > > protected by SDMI technologies outside the Public Challenge. If your > > research is released to the public this is exactly what could occur. > > In short, you would be facilitating and encouraging the attack of > > copyrighted content outside the limited boundaries of the Public > > Challenge and thus places you and your researchers in direct violation > > of the Agreement. > > > > In addition, because public disclosure of your research would be > > outside the limited authorization of the Agreement, you could be > > subject to enforcement actions under federal law, including the DMCA. > > The Agreement specifically reserves any rights that proponents of the > > technology being attacked may have "under any applicable law, > > including, without limitation, the U.S. Digital Millennium Copyright > > Act, for any acts not expressly authorized by their Agreement." The > > Agreement simply does not "expressly authorize" participants to > > disclose information and research developed through participating in > > the Public challenge and such disclosure could be the subject of a > > DMCA action. > > > > We recognize and appreciate your position, made clear throughout this > > process, that it is not your intention to engage in any illegal > > behavior or to otherwise jeopardize the legitimate commercial > > interests of others. We are concerned that your actions are outside > > the peer review process established by the Public Challenge and setup > > by engineers and other experts to ensure the academic integrity of > > this project. With these facts in mind, we invite you to work with the > > SDMI Foundation to find a way for you to share the academic components > > of your research while remaining true to your intention to not violate > > the law or the Agreement. In the meantime, we urge you to withdraw the > > paper submitted for the upcoming Information Hiding Workshop, assure > > that it is removed from the Workshop distribution materials and > > destroyed, and avoid a public discussion of confidential information. > > > > Sincerely, > > > > [Signature] > > > > Matthew Oppenheim, Secretary > > The SDMI Foundation > > > > cc: Mr. Ira S. Moskowitz, Program Chair, Information Hiding Workshop, > > Naval Research Laboratory > > Cpt. Douglas S. Rau, USN, Commanding Officer, Naval Research > > Laboratory > > Mr. Howard Ende, General Counsel of Princeton > > Mr. Edward Dobkin, Computer Science Department Head of Princeton > > _________________________________________________________________ > > > >*********** > > > > >______________________________________________________________________________ > >Watermarking Mailing List - http://www.watermarkingworld.org/ml.html >To unsubscribe send email to "majordomo@watermarkingworld.org" with >"unsubscribe watermarking YOURMAIL" in the body. >______________________________________________________________________________ > From thardjono@mediaone.net Sun May 20 04:56:14 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:56:14 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] XrML? Message-ID: <5.0.0.25.2.20010519235612.01b6e620@pop.ne.mediaone.net> >Date: Wed, 25 Apr 2001 12:46:26 +0100 (BST) >From: "J. Chong" >Subject: [IDRM] XrML? >To: ietf-idrm@lists.elistx.com >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >Hi, > > I am currently working with DRM. I wish to know whether there is a >standard language (which is recognized by W3C) which is used to describe >and define the rights on a digital content. For example, I came across >XrML (www.xrml.org), and I am wondering what is the status of XrML in >W3C. Please help. Thanks. > > >Best regards, >Jordan CN CHONG From thardjono@mediaone.net Sun May 20 04:56:24 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:56:24 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] XrML? Message-ID: <5.0.0.25.2.20010519235621.01b6e440@pop.ne.mediaone.net> >Date: Wed, 25 Apr 2001 14:52:39 +0100 (BST) >From: "J. Chong" >Subject: Re: [IDRM] XrML? >To: Mark Baugher >Cc: ietf-idrm@lists.elistx.com >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >Dear Mark, > > Thanks for your reply and help. Do you mind telling me what you >think about XrML (www.xrml.org)? Thanks. > >On Wed, 25 Apr 2001, Mark Baugher wrote: > > > Hi > > There is no standard rights management language yet. There is only > > one that I am aware of that is intended to be an "open-standard" language > > and that is ODRL, Open Digital Rights Language. Following the W3C > > meeting at Inria earlier in the year, the Workshop on Digital Rights, > > I am expecting some initiative to start in the W3C. > > > > Mark > > > > At 12:46 PM 4/25/2001 +0100, J. Chong wrote: > > > > >Hi, > > > > > > I am currently working with DRM. I wish to know whether there > is a > > >standard language (which is recognized by W3C) which is used to describe > > >and define the rights on a digital content. For example, I came across > > >XrML (www.xrml.org), and I am wondering what is the status of XrML in > > >W3C. Please help. Thanks. > > > > > > > > >Best regards, > > >Jordan CN CHONG > > > > > >Best regards, >Jordan CN CHONG From thardjono@mediaone.net Sun May 20 04:56:31 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:56:31 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] XrML? Message-ID: <5.0.0.25.2.20010519235628.01c7feb0@pop.ne.mediaone.net> >Date: Wed, 25 Apr 2001 12:43:19 -0400 >From: Thomas Hardjono >Subject: Re: [IDRM] XrML? >X-Sender: thardjono@pop.ne.mediaone.net >To: "J. Chong" , ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >Hi, > >As far as I know there is currently no specific language defined by >the W3C. The first step is for a DRM WG to be created in the W3C >and there are efforts underway to do this. > >cheers, > >thomas >------ > > >At 4/25/2001||12:46 PM, J. Chong wrote: > >>Hi, >> >> I am currently working with DRM. I wish to know whether there is a >>standard language (which is recognized by W3C) which is used to describe >>and define the rights on a digital content. For example, I came across >>XrML (www.xrml.org), and I am wondering what is the status of XrML in >>W3C. Please help. Thanks. >> >> >>Best regards, >>Jordan CN CHONG From thardjono@mediaone.net Sun May 20 04:56:40 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:56:40 -0400 Subject: [IETF-IDRM] Fwd: RE: [IDRM] XrML? Message-ID: <5.0.0.25.2.20010519235638.01c7b0c0@pop.ne.mediaone.net> >Date: Fri, 27 Apr 2001 12:38:49 -0700 >From: Rob Koenen >Subject: RE: [IDRM] XrML? >To: "'Mark Baugher'" , "J. Chong" >Cc: ietf-idrm@lists.elistx.com >X-Mailer: Internet Mail Service (5.5.2653.19) >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > > There is no standard rights management language yet. > > There is only > > one that I am aware of that is intended to be an > > "open-standard" language > > and that is ODRL, Open Digital Rights Language. Following the W3C > > meeting at Inria earlier in the year, the Workshop on Digital Rights, > > I am expecting some initiative to start in the W3C. > >Initiative has already started in MPEG, and representatives of both >ODRL and XrML are participating in a requirements study, along >with quite a few more people. If there is interest I can send >the call for Requirements and draft Requirements Document to this >list. >MPEG anticipates issuing a Call for Proposals in July. >MPEG has invited W3C to jointly take on this enormous undertaking. > >As there were some remarks about licensing: >MPEG does not accept conditional submissions, and will seek the best >standard as a combination from all proposals received. > >MPEG technology is not usually license free, but contributors to the >standard are required to declare that they will license their essential >patents on fair, reasonable and non-discriminatory terms. >I am not a lawyer, and will not try to pass judgement on what >constitutes "fair, reasonable and non-discriminatory". > >Rob Koenen >Chairman MPEG Requirements Group. From thardjono@mediaone.net Sun May 20 04:56:48 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:56:48 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] Microsoft DRM demo at Info-Hiding Workshop Message-ID: <5.0.0.25.2.20010519235645.01c7b540@pop.ne.mediaone.net> >Date: Wed, 02 May 2001 12:11:46 -0400 >From: Thomas Hardjono >Subject: [IDRM] Microsoft DRM demo at Info-Hiding Workshop >X-Sender: thardjono@pop.ne.mediaone.net >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > > MS May Have File-Trading Answer > By Declan McCullagh > > 2:00 a.m. May. 1, 2001 PDT > > PITTSBURGH -- Microsoft has developed a prototype system that > limits unauthorized playback of music by > embedding a watermark that remains permanently attached to > audio files. > > During a security workshop on Friday, a Microsoft Research > scientist demonstrated how the hidden copyright > fingerprint is so securely affixed to the audio that it > remains intact even if a jazz song is played aloud on > speakers in a noisy room and then re-recorded. > >http://www.wired.com/news/digiwood/0%2C1412%2C43389%2C00.html From thardjono@mediaone.net Sun May 20 04:57:03 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:57:03 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] NAPSTER LEAVES AN IMPRINT ON MP3 FILES Message-ID: <5.0.0.25.2.20010519235700.01b6f650@pop.ne.mediaone.net> >Date: Mon, 14 May 2001 10:22:49 -0400 >From: Thomas Hardjono >Subject: [IDRM] NAPSTER LEAVES AN IMPRINT ON MP3 FILES >X-Sender: thardjono@pop.ne.mediaone.net >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >*NAPSTER LEAVES AN IMPRINT ON MP3 FILES >Napster plans to acoustically fingerprint music files in its system to >prevent copyrighted material from being downloaded for free--and to show a >federal court it is making an earnest effort to block copyrighted >material. > >The TRM technology, licensed from Virginia-based Relatable, identifies a >small amount of data representing a file's unique sound recording, >regardless of the audio format, bit rate or signal distortion. The audio >"fingerprints" are then stored in a database and used to monitor MP3 files >being swapped among Napster subscribers. > >This differs from Napster's initial digital fingerprinting, which blocked >copyrighted files based on their names or song titles. Napster users had >circumvented those content filters by intentionally misspelling file >names. > >The announcement came weeks after Napster officials told an U.S. District >Court that audio fingerprinting to block copyrighted recordings doesn't >work well. The technology has improved rapidly in a short amount of time, >the company now says. Napster was successfully sued for copyright >infringement last year by the recording industry. > >Some industry insiders have questioned the robustness of Relatable's TRM, >but company CEO Pat Breslin says his product can handle the volume. "TRM >will help ensure that the millions of music files transferred through the >new Napster system will be accurately monitored, and it will enable the >appropriate allocation of royalties to artists, music publishers and >record companies," he said in a statement. From thardjono@mediaone.net Sun May 20 04:57:24 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:57:24 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] frequency domain Message-ID: <5.0.0.25.2.20010519235722.01be0150@pop.ne.mediaone.net> >Date: Mon, 14 May 2001 17:54:35 +0000 >From: ASD DSA >Subject: [IDRM] frequency domain >X-Originating-IP: [212.138.47.11] >To: ietf-idrm@lists.elistx.com >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > >X-OriginalArrivalTime: 14 May 2001 17:54:35.0718 (UTC) > FILETIME=[F0144E60:01C0DC9E] > >hi all >i want some detail about insertion the watermark in the frequency domain >and advantage it over the spatial domain >thanks alot >_________________________________________________________________________ >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From thardjono@mediaone.net Sun May 20 04:57:35 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:57:35 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] New IDRM drafts on website + thoughts on PKI/DRM Message-ID: <5.0.0.25.2.20010519235733.01be0cc0@pop.ne.mediaone.net> >Date: Mon, 14 May 2001 16:09:28 -0400 >From: Thomas Hardjono >Subject: [IDRM] New IDRM drafts on website + thoughts on PKI/DRM >X-Sender: thardjono@pop.ne.mediaone.net (Unverified) >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >Folks, > >We have received a formal submission to IDRM of three Internet-Drafts >relating to the Handle System. > >These are located on http://www.idrm.org/idrm_drafts.htm > >I think the issues of Naming, Naming-Authorities and Naming-Support-Systems >are an integral part of any DRM systems and thus the DRM infrastructure >as a whole. Thus, it would be good to see discussion on these issues. > >As an example, if a URN is used within a Record, then some form of >digital signature will need to be applied to the Record. >This further implies that there is a Certification Authority (CA) >that is behind the Certificate used for the signature. This, in-turn, >suggests that some resemblance of a PKI is needed before the Naming system >can function. > >Does this mean that the whole DRM industry must wait for a worldwide PKI to >exist, or can we build-up a DRM-specific PKI stage-by-stage (and in fact >be one of the primary movers for the worldwide PKI)? > >Any comments? > >cheers, > >thomas >------ From thardjono@mediaone.net Sun May 20 04:57:42 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:57:42 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] More on InterTrust sues Microsoft Message-ID: <5.0.0.25.2.20010519235740.01be29b0@pop.ne.mediaone.net> >Date: Mon, 14 May 2001 16:19:01 -0400 >From: Thomas Hardjono >Subject: [IDRM] More on InterTrust sues Microsoft >X-Sender: thardjono@pop.ne.mediaone.net >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe:= >List-Archive: >List-Help: , > > > >http://www.zdnet.com/intweek/stories/news/0,4164,2716226,00.html > >Digital Patents Go to Court >By Sara Robinson, Interactive Week >May 8, 2001 12:58 PM PT >URL: > >A high-stakes battle over a keyechnology for managing the distribution of= =20 >digital content has been >launched, and the first volley is InterTrust Technologies' lawsuit against= =20 >Microsoft for patent >infringement. > >InterTrust, founded in 1990, holds extensive patents in digital rights=20 >management, a technology that >enables companies to encrypt documents or media files and attach rules for= =20 >their use. DRM is just >beginning to fulfill its promise as an essential building block for=20 >commerce of digital goods. > >Companies developing DRM worry that if InterTrust's patents hold up, they= =20 >will be forced to pay >costly licensing fees or awkwardly engineer their products to work around= =20 >the patents. The outcome >is unclear for corporate customers that are just beginning to use DRM to=20 >manage such assets as >photos, logos, legal documents and corporate training videos. For example,= =20 >using DRM, a training >video could be encrypted so that a company could track how many times it=20 >is watched. > >Even if the patents are eventually struck down, the legal morass could=20 >prove costly for DRM >providers and their customers. And InterTrust's lawsuit is likely to be=20 >one of many technology patent >battles ahead. > >"Now that the dot-com boom is crashing, one of the things that's left to=20 >milk is the patents," said >Greg Aharonian, publisher at the Internet Patent News Service, a=20 >newsletter covering technology >patent issues. "You'll see a lot more of this." > >The lawsuit, which asks for damages and an injunction against the=20 >distribution and sale of Windows >Media Player and other products, focuses only on Microsoft =97 for now. But= =20 >in the April 26 lawsuit >filed in San Jose, InterTrust reserves the right to add other companies.=20 >Some observers think the >small, struggling firm is trying to make a business out of such legal=20 >fights =97 or position itself to be >acquired. > >Suitor Sought? > >Aram Sinnreich, a senior analyst at Jupiter Research, believes in the=20 >latter theory. "DRM is finally >going to become very important in the very near term, and it sounds like=20 >their patents are very >far-reaching," Sinnreich said. "If I had to pick one reason to explain the= =20 >lawsuit, I think InterTrust is >trying to goad Microsoft or someone else into buying them." > >Other leading providers of DRM are ContentGuard and IBM; both declined to= =20 >comment on the >lawsuit. > >DRM technology was first marketed for business-to-consumer applications,=20 >such as sales of digital >music and electronic books. But since the systems can be awkward to use=20 >and often require >downloads of client software, they haven't been popular. > >Recently, however, DRM started steadily gaining traction in the enterprise= =20 >market in the form of >digital asset management. Systems to help corporations efficiently manage= =20 >use of their digital >property are offered by companies such as Artesia Technologies, eMotion=20 >and MediaBin. > >InterTrust's enormous patent portfolio has long frustrated rival companies= =20 >developing DRM >technology, which charge that the patents are overly broad. > >For example, the patent that is at the heart of the Microsoft suit was=20 >filed in 1998 as a continuation >of patents going back to 1994. The patent was issued in February. It=20 >governs basic aspects of >DRM such as content rights management procedures; "superdistribution,"=20 >which is the distribution of >protected content from peer-to-peer; and subscription services for content= =20 >governed by usage rules. > >"If they get an adequate settlement out of Microsoft, that certainly=20 >wouldn't hurt their position with >the other companies doing digital rights management," Aharonian said. "If= =20 >they get a jury verdict, >that really strengthens their hand." > >A researcher at a large company that has developed DRM technology, who=20 >asked not to be >named, complained that InterTrust has 5,000 to 10,000 pages of claims in=20 >its 18 existing patents, >and more than 40 patents pending. > >"Until they are invalidated, people will have to worry about it, because=20 >you have these huge, huge >patents with zillions of different claims," the researcher said. "If you=20 >go to a patent attorney and give >them 10,000 pages to read and the meter clicks at $300 an hour, expenses=20 >start mounting up very >quickly." > >Asked whether he believes the patents to be frivolous, the re searcher=20 >responded: "No one can >really be sure because they are so voluminous. . . . Some people are=20 >willing to give them the benefit >of the doubt because they have very smart people on their payroll and=20 >they've been around for quite >a while, but most of our people are very skeptical of InterTrust patents." > >Ed Fish, president of the MetaTrust Utility division at InterTrust,=20 >acknowledged that the patent that >provoked the lawsuit covers very fundamental aspects of DRM systems. "They= =20 >are fundamental >aspects of technical components that we think are necessary for efficient= =20 >digital rights management," >Fish said. But, he added, "I don't want to make the point that this covers= =20 >every functional means. >The patent claims are technical and specific." > >Jim Cullinan, a Microsoft spokes man, said Microsoft has been developing=20 >DRM technology for >many years, but declined to comment on the specifics of the lawsuit. "We=20 >have just received this >complaint and we continue to evaluate it," Cullinan said, reading from a=20 >prepared statement. > >Fish said the complaint focused solely on Microsoft because the company=20 >spelled out the details of >its system clearly enough in public documents that InterTrust felt sure=20 >Microsoft was infringing. > >"It's possible that there are other infringers, but there's less=20 >information available," Fish said. "We're >continuing to investigate." > >Given the stakes involved, Aharonian said, the courts will probably act=20 >quickly on the injunction. If >InterTrust can get an injunction, he added, Microsoft may well choose to=20 >settle rather than hold up >the distribution of Windows XP, the latest version of its consumer=20 >operating system which is >scheduled for release this fall. Microsoft's Media Player and DRM=20 >technology, the subject of the >lawsuit, are built right into the new OS. > >A settlement in the current case would be a boon to InterTrust, which is=20 >struggling financially. The >company reported a net loss of $21.6 million for the first quarter, and=20 >during its earnings call last >week, it announced it would lay off 15 percent of its staff. > >InterTrust has been peddling its patents to its rivals for the last=20 >several years. So far, none of these >companies license the InterTrust technology =97 primarily because the=20 >licensing fees InterTrust has >asked seemed unreasonably high, several companies said privately. > >Still, this lawsuit is "not going to be a slam dunk" for either Microsoft= =20 >or InterTrust, Aharonian said. >"Inter Trust comes in with a good hand, but Microsoft has a ton of money = =97=20 >and if it fights off the >injunction, maybe it just bleeds InterTrust to death." > > >Who Has the (Digital) Right? > >The InterTrust Technologies patent that is the subject of a lawsuit=20 >against Microsoft deals with many >aspects of digital rights management: > Content rights management and provision of electronic licenses and= permits > Rules managing electronic subscriptions for content > Messaging and other communications according to secure policies and= rules > Trusted electronic negotiation, digital information escrow and=20 > automated, secure fulfillment > Tracking and secure control of electronic documents, records and other= =20 > digital information among >authenticated members of select user groups From thardjono@mediaone.net Sun May 20 04:58:05 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:58:05 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] New IDRM drafts on website + thoughts on PKI/DRM Message-ID: <5.0.0.25.2.20010519235803.01be1130@pop.ne.mediaone.net> >Date: Mon, 14 May 2001 13:30:10 -0700 >From: Mark Baugher >Subject: Re: [IDRM] New IDRM drafts on website + thoughts on PKI/DRM >X-Sender: mbaugher@mira-sjc5-6.cisco.com >To: Thomas Hardjono >Cc: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >hi Thomas > I hope to get to this thread when I return from some business travel > later this week. I just wanted to point out that there are alternatives > to PKI, as I'm sure you know. Obviously, public/private crypto can be > used without a public key infrastructure if there is no compelling reason > to publicly bind the name to the key; SPKI is one such example. There > are also systems based on Kerberos that may be applied in some > environments. Finally, there are issues with using signing keys at all > for publishing: Ross Anderson et. al. have pointed out that the key life > is typically too short for a published work that may last 70 years after > the author's death and too long for a content work that needs to be > authenticated and have its integrity checked within a short period after > the work is made available. So they have a cataloging system that takes > the place of a PKI. > >Cheers, Mark >At 04:09 PM 5/14/2001 -0400, Thomas Hardjono wrote: > >>Folks, >> >>We have received a formal submission to IDRM of three Internet-Drafts >>relating to the Handle System. >> >>These are located on http://www.idrm.org/idrm_drafts.htm >> >>I think the issues of Naming, Naming-Authorities and Naming-Support-Systems >>are an integral part of any DRM systems and thus the DRM infrastructure >>as a whole. Thus, it would be good to see discussion on these issues. >> >>As an example, if a URN is used within a Record, then some form of >>digital signature will need to be applied to the Record. >>This further implies that there is a Certification Authority (CA) >>that is behind the Certificate used for the signature. This, in-turn, >>suggests that some resemblance of a PKI is needed before the Naming system >>can function. >> >>Does this mean that the whole DRM industry must wait for a worldwide PKI to >>exist, or can we build-up a DRM-specific PKI stage-by-stage (and in fact >>be one of the primary movers for the worldwide PKI)? >> >>Any comments? >> >>cheers, >> >>thomas >>------ From thardjono@mediaone.net Sun May 20 04:58:30 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:58:30 -0400 Subject: [IETF-IDRM] Fwd: RE: [IDRM] XrML? Message-ID: <5.0.0.25.2.20010519235822.01be2d80@pop.ne.mediaone.net> >Date: Tue, 15 May 2001 02:17:49 -0700 >From: Fabien Petitcolas >Subject: RE: [IDRM] XrML? >To: Mark Baugher , "J. Chong" >Cc: ietf-idrm@lists.elistx.com >Thread-Topic: [IDRM] XrML? >Thread-Index: AcDNkR0h16P1or5CSli+AfjFX2J5MQO1LTzw >X-MS-Has-Attach: >X-MS-TNEF-Correlator: >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > >X-OriginalArrivalTime: 15 May 2001 09:17:50.0371 (UTC) > FILETIME=[E9DD8F30:01C0DD1F] > >Dear Mark, > >After asking to people who are better informed than me, it looks like >you may have misread the ContentGuard Agreement: > >"While ContentGuard does get rights to derivative improvements in XrML >(as it needs to to carry on the standard), the licensees are free to use >any version of XrML. However, after a period of time, if they do not >support the latest version of XrML, they have to stop CALLING their >implementation XrML or implying that it is XrML compliant." > >Hope this helps, > >Fabien > >-----Original Message----- >From: Mark Baugher [mailto:mbaugher@cisco.com] >Sent: Wednesday 25 April 2001 15:07 >To: J. Chong >Cc: ietf-idrm@lists.elistx.com >Subject: Re: [IDRM] XrML? > >Hi > I can only relate my personal experience here. Content Guard >requires >people to sign a license to look at XrML, or at least they did; I have >not >checked recently to see if this has changed. The license seems to >grant Content Guard a perpetual license to use any and all derivatives >but only grants the person signing the license rights to use the >current version of XrML. At least this was the license that I read >last year and I'm not a lawyer. So I sent a note to them asking about >this and participation in the group that determines the direction of >XrML in the future. I got no reply to that note. I think that its >predecessor, DPRL, is pretty extensive and compares favorable >to ODRL, though I have not done any extensive analysis of these >languages. I'm hoping that this work will be undertaken by W3C. > >Mark > >At 02:52 PM 4/25/2001 +0100, J. Chong wrote: > >Dear Mark, > > > > Thanks for your reply and help. Do you mind telling me what >you > >think about XrML (www.xrml.org)? Thanks. > > > >On Wed, 25 Apr 2001, Mark Baugher wrote: > > > > > Hi > > > There is no standard rights management language yet. There is >only > > > one that I am aware of that is intended to be an "open-standard" >language > > > and that is ODRL, Open Digital Rights Language. Following the W3C > > > meeting at Inria earlier in the year, the Workshop on Digital >Rights, > > > I am expecting some initiative to start in the W3C. > > > > > > Mark > > > > > > At 12:46 PM 4/25/2001 +0100, J. Chong wrote: > > > > > > >Hi, > > > > > > > > I am currently working with DRM. I wish to know whether >there > > is a > > > >standard language (which is recognized by W3C) which is used to >describe > > > >and define the rights on a digital content. For example, I came >across > > > >XrML (www.xrml.org), and I am wondering what is the status of XrML >in > > > >W3C. Please help. Thanks. > > > > > > > > > > > >Best regards, > > > >Jordan CN CHONG > > > > > > > > > >Best regards, > >Jordan CN CHONG From thardjono@mediaone.net Sun May 20 04:58:41 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:58:41 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] DRM Taxonomy work Message-ID: <5.0.0.25.2.20010519235839.01be25f0@pop.ne.mediaone.net> >Date: Thu, 17 May 2001 15:33:34 -0700 >From: Mark Baugher >Subject: [IDRM] DRM Taxonomy work >X-Sender: mbaugher@mira-sjc5-6.cisco.com >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >Hi > We wanted to begin work on developing a draft on requirements for > IDRM. Sam Sun, Thomas Hardjono and I discussed this and we think that a > good first step would be to develop a taxonomy, which is a classification > of the parts of an end-to-end DRM system from which we can develop a > common model, or models, and common definitions - so we speak the same > language to one another. > > Our focus in IDRM is with the IP network infrastructure aspects of > DRM. To me, this means that we are less concerned with the syntax or > semantics of rights specifications than in the handling and use of rights > metadata in end-to-end systems; we are less concerned with the specifics > of watermarking technology or with technical protection mechanisms than > in key and license distribution systems; persistent and globally-unique > names may not be as much of a concern to IDRM as are trusted repositories > of content works and metadata. So there are things in our taxonomy that > are part of end-to-end DRM systems like watermarks, TPM, and rights > languages that are not necessarily things that will be a focus of IDRM. > > At our last meeting, Thomas and I proposed that there are two distinct > sets of relationships in end-to-end DRM. First, is between content > provider and distributor (aka "service provider"). We would use "service > provider" if the content were to be delivered to consumers over a IP > network but the distributor could be a company that manufactures DVDs or > a TV broadcaster that receives files from a TV or film studio. Trusted > repositories for the files and rights metadata, authorization, and > authentication are IP infrastructure components that the content provider > may need to properly manage this process. It is unlikely that technical > protection mechanisms or digital licenses are needed in this > business-to-business transaction. > > The second set of relationships is between the service provider and the > content consumer. On the Internet today, it is hard if not impossible to > unambiguously identify illegal sources and uses of copyright content > works from illegal uses. Trusted repositories and sources with rights > metadata are important to DRM in this relationship. Authorization, > authentication, and technical protection mechanisms may be needed so > standard ways to do key and license management will promote > inter-operability. What we should not overlook in digital > rights-conferral and mechanisms that support it is the flow of > information assets from the consumer to the provider for the purposes of > authorization. In this regard, "rights management" should include the > rights that consumers have with respect to information that they provide > and DRM is about information assets and not only copyright works. > >We want to begin developing our taxonomy and putting flesh to an IDRM >model. This note outlines the general approach that we are taking and >we're soliciting any comments that people might have. Also, if others are >interested in working on a draft document for the taxonomy, please let us know. > >Mark From thardjono@mediaone.net Sun May 20 05:01:03 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sun, 20 May 2001 00:01:03 -0400 Subject: [IETF-IDRM] test - ignore Message-ID: <5.0.0.25.2.20010520000046.01be1610@pop.ne.mediaone.net> test - ignore From thardjono@mediaone.net Sun May 20 04:58:58 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:58:58 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010519235855.01be6eb0@vhqpostal.verisign.com> >Date: Sat, 19 May 2001 10:47:39 -0400 >From: "Sam X. Sun (@S2000)" >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >To: Mark Baugher , ietf-idrm@lists.elistx.com >X-Mailer: Microsoft Outlook Express 5.50.4133.2400 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >Hi, > >I think it's a good application model to classify in end-to-end DRM >relationships in terms of content provider and distributor, and distributor >and content consumer. They represent some real world scenarios that DRM will >have to address. On the other hand, I wonder if we could further model the >underlying DRM framework in terms of transactions of certain entities (e.g. >digital content) among other kinds of entities (e.g. content holder), and >the transaction may be reflected in terms of exchange/update of digital >rights bound to each content instance acquired by the content holder. > >In other words, I wonder whether it's reasonable to categorize the entities >that DRM framework has to deal with in terms of: > > 1. the digital content (per instance) > 2. the content holder (current or potential) > > >And think of the digital rights as state information of the digital content >hold by content holder. From this, one may imagine building mechanisms >within the framework to: > > * Associate rights per digital content acquired by the content holder > * Identify content holder, along with its authentication attributes. > * Exchange/update digital rights per digital content among content >holders > * Facilitate/monitor/trace legitimate digital contents for their proper >use > * Report illegal content upon showing up within the framework (doable?) > etc... > >Assumptions here are that everyone can obtain a copy of digital content >freely, but need to acquire (e.g. via purchase) adequate rights to be able >to "use" it. Depending on the rights associated to the digital content >acquired by the content holder, the content holder could act as a publisher, >a distributor, a retailer, or end consumer. A transaction of digital content >from a retailer to consumer could be modeled as retailer (with the right) to >generate a new instance of the digital content, assign it with consumer >rights, and "give" it to the consumer (along with the consumer rights). A >consumer may later become a retailer after obtaining the "retail" rights for >its copy of digital content... > >It's a bit off tracking to Mark's message:)... Just want to share some >thoughts. Any comments? > > >Cheers, >Sam > > > > >----- Original Message ----- >From: "Mark Baugher" >To: >Sent: Thursday, May 17, 2001 6:33 PM >Subject: [IDRM] DRM Taxonomy work > > > > Hi > > We wanted to begin work on developing a draft on requirements for > > IDRM. Sam Sun, Thomas Hardjono and I discussed this and we think that a > > good first step would be to develop a taxonomy, which is a classification > > of the parts of an end-to-end DRM system from which we can develop a >common > > model, or models, and common definitions - so we speak the same language >to > > one another. > > > > Our focus in IDRM is with the IP network infrastructure aspects of > > DRM. To me, this means that we are less concerned with the syntax or > > semantics of rights specifications than in the handling and use of rights > > metadata in end-to-end systems; we are less concerned with the specifics >of > > watermarking technology or with technical protection mechanisms than in >key > > and license distribution systems; persistent and globally-unique names may > > not be as much of a concern to IDRM as are trusted repositories of content > > works and metadata. So there are things in our taxonomy that are part of > > end-to-end DRM systems like watermarks, TPM, and rights languages that are > > not necessarily things that will be a focus of IDRM. > > > > At our last meeting, Thomas and I proposed that there are two distinct > > sets of relationships in end-to-end DRM. First, is between content > > provider and distributor (aka "service provider"). We would use "service > > provider" if the content were to be delivered to consumers over a IP > > network but the distributor could be a company that manufactures DVDs or a > > TV broadcaster that receives files from a TV or film studio. Trusted > > repositories for the files and rights metadata, authorization, and > > authentication are IP infrastructure components that the content provider > > may need to properly manage this process. It is unlikely that technical > > protection mechanisms or digital licenses are needed in this > > business-to-business transaction. > > > > The second set of relationships is between the service provider and the > > content consumer. On the Internet today, it is hard if not impossible to > > unambiguously identify illegal sources and uses of copyright content works > > from illegal uses. Trusted repositories and sources with rights metadata > > are important to DRM in this relationship. Authorization, authentication, > > and technical protection mechanisms may be needed so standard ways to do > > key and license management will promote inter-operability. What we >should > > not overlook in digital rights-conferral and mechanisms that support it is > > the flow of information assets from the consumer to the provider for the > > purposes of authorization. In this regard, "rights management" should > > include the rights that consumers have with respect to information that > > they provide and DRM is about information assets and not only copyright >works. > > > > We want to begin developing our taxonomy and putting flesh to an IDRM > > model. This note outlines the general approach that we are taking and > > we're soliciting any comments that people might have. Also, if others are > > interested in working on a draft document for the taxonomy, please let us >know. > > > > Mark > > From thardjono@mediaone.net Sun May 20 04:59:10 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 19 May 2001 23:59:10 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010519235907.01be6280@vhqpostal.verisign.com> >Date: Sat, 19 May 2001 15:17:51 -0400 >From: Thomas Hardjono >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >X-Sender: thardjono@pop.ne.mediaone.net >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >Hi Sam, > >I don't think you are off-track. You have brought up some good issues which >I'll comment below (I'll send comments about Mark's posting separately). > > >At 5/19/01||10:47 AM, Sam X. Sun (@S2000) wrote: >>Hi, >> >>I think it's a good application model to classify in end-to-end DRM >>relationships in terms of content provider and distributor, and distributor >>and content consumer. They represent some real world scenarios that DRM will >>have to address. On the other hand, I wonder if we could further model the >>underlying DRM framework in terms of transactions of certain entities (e.g. >>digital content) among other kinds of entities (e.g. content holder), and >>the transaction may be reflected in terms of exchange/update of digital >>rights bound to each content instance acquired by the content holder. >> >>In other words, I wonder whether it's reasonable to categorize the entities >>that DRM framework has to deal with in terms of: >> >> 1. the digital content (per instance) >> 2. the content holder (current or potential) >> >> >>And think of the digital rights as state information of the digital content >>hold by content holder. From this, one may imagine building mechanisms >>within the framework to: >> >> * Associate rights per digital content acquired by the content holder >> * Identify content holder, along with its authentication attributes. >> * Exchange/update digital rights per digital content among content >>holders >> * Facilitate/monitor/trace legitimate digital contents for their proper >>use >> * Report illegal content upon showing up within the framework (doable?) >> etc... > >I'm unclear about the term "content holder" above. I assume you mean >the Consumer that actually uses (reads/views/plays) the Content, >since Content not in the Consumer's hands will not generate money. > >As I understand it, the Digital-Rights (or Rights-Metadata) can be >Content-specific only or can be tied to both the Content and the Consumer. > >The distinction becomes relevant when we talk about the Business Models. >Thus, say in one business model, the Content-Creator/Owner may >specify usage rights in the Rights-Metadata (without mentioning specific >Customers). Assuming the Content-Creator/Owner has a business relationship >with a Distributor, then perhaps it is up to the Distributor(s) to >create further Rights-Metadata that is Customer-specific (eg. for Customer >who are members of the video-club, say). > >WRT your second bullet above, when the Distributor starts dealing >with Consumers (i.e content holder) does the Consumer's authentication >attributes becomes extremely relevant. It here that I think individual >certificates will become a key issue. A Customer's certificate will become >more important and persistent comapred to his/her credit card number. >And accounting and tracking may also perhaps be based on certificates. > >In terms of the transferability of Contents, most systems I have seen >or read about deploy some kind of verification/checking each time >the Content's ownership is transffered. Thus, in basic terms, if I sell >my (encrypted) MP3 file on eBay, then the purchaser will have to register >with the Distributor (or the entity claiming to be the contact-point for that >Content) and obtain a copy of the key (or a derived version). > >This model does not really fit into the "pure" P2P distribution scheme, >but it ensures continuous revenue for the distributor (who gets >additional new customer info). This model also allos tracking of >moved/sold Contents on the net. > > > >>Assumptions here are that everyone can obtain a copy of digital content >>freely, but need to acquire (e.g. via purchase) adequate rights to be able >>to "use" it. Depending on the rights associated to the digital content >>acquired by the content holder, the content holder could act as a publisher, >>a distributor, a retailer, or end consumer. > >This idea is cool and reflects more of the pure P2P approach. I don't >know if the big players will like the notion of a Consumer (content holder) >taking the role of publisher/distributor/retailer. > >I think the term P2P itself has been overused and means different things >to different people. I used it to mean the non-hierarchical/flat >distributed system that runs democratically from one user's machine >to another. > >Other people seem to mean P2P as "group-sharing of files" regardless >of how the files are managed (ie. the files could be sitting on >a single machine/server with everyone connecting to that server). >This later view is similar to the mainframe usage model of the 70s. > > > >>A transaction of digital content >>from a retailer to consumer could be modeled as retailer (with the right) to >>generate a new instance of the digital content, assign it with consumer >>rights, and "give" it to the consumer (along with the consumer rights). > >OK, so here is an interesting question: can BlockBuster Video make >copies of videos (ie. a new instant of content) in their backroom >and lease them? (and I don't mean replacements for broken/stolen >videocassettes). > > > >>A consumer may later become a retailer after obtaining the "retail" >>rights for its copy of digital content... > >Hmmm... > >cheers, > >thomas >------ From ssun@cnri.reston.va.us Wed May 23 18:10:19 2001 From: ssun@cnri.reston.va.us (Sam X. Sun (@S2000)) Date: Wed, 23 May 2001 13:10:19 -0400 Subject: [IETF-IDRM] Re: [IDRM] DRM Taxonomy work -- drm framework... -- handle system References: <5.0.0.25.2.20010514155912.0185c780@pop.ne.mediaone.net> <4.3.2.7.2.20010517141924.068f98c8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010521095254.04469ee8@mira-sjc5-6.cisco.com> <006001c0e34e$2cc005b0$0a00a8c0@S2000> <20010523101044.D7549@bailey.dscga.com> Message-ID: <00bd01c0e3ab$3e970010$5b041b0a@S2000> Hi Michael, I agree with you that DRM doesn't have to stick with any specific technology for its process. All we wanted here is to understand the process, and identify technologies that can be applied to it... In terms of Handle System and URN, I would say that they are quite different now in terms of how they work and the issues that they want to address. Handle system started about the same time PURL and URN started, trying to address persistence issue of URL namespace. But later we found that persistence is more of a social and/or management issue than a mere technical one. While Handle System does provide a technical approach to encourage more persistent namespace management, we have put more focus on service security, distributed name administration, internationalization (i18n), and service scalability. It might be helpful if you can read the latest HS drafts to understand the difference... On the other hand, I see no reason why Handle System cannot work with URN. One way to do it is to register HS namespace as a namespace under URN, as we discussed earlier last year. The issues that we need to address are how to make sure that the NAPTR approach won't become a bottleneck, and how to achieve service security over such approach. Maybe we should discuss these in a separate thread, or bring them to the URN working group... Regarding URI and HS, I'm not sure if they are comparable. I tend to think that URI is a collection of name services, and Handle System is just a specific one, under a specific protocol. While some members of URI can be as secure as you want, others can be totally insecure. I wonder if it's appropriate to say a URI in general is secure, or carries any semantic meaning (a name, an address, an identifier, etc)? In fact, because DNS is not secure as we know of today, that makes any name service based on DNS questionable in their security. The Handle System is designed to be independent of DNS, and to address the security and i18n issues that DNS is struggling to overcome. It has the advantage that it's starting from scratch, and doesn't have to deal with the backward compatibility issues that DNS has to take care of... On the other hand, we are in the process of defining handle system URI syntax for handles to be used in web context. In that sense, Handle system defines a namespace under URI, and we are in agreement there. In fact, I'm more inclined to think that Handle System is in par with DNS. In fact, if DNS can address security, i18n, access control on name attributes, and to allow individuals to manage the names they registered, we probably won't need the Handle System. On the other hand, people from DNS working group has refused to apply DNS as a general name service other than network-address translation, which makes us think that an independent name service would be helpful... Cheers, Sam ----- Original Message ----- From: "Michael Mealling" To: "Sam X. Sun (@S2000)" Cc: "Mark Baugher" ; Sent: Wednesday, May 23, 2001 10:10 AM Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... > Hi Sam! > > On Wed, May 23, 2001 at 02:03:48AM -0400, Sam X. Sun (@S2000) wrote: > > Regarding the handle system, I think there are two sides of DRM that could > > take advantage of it. First is the metadata and content attribute > > association, as you mentioned in the DOI application. > > >From what I remember this part of the handle service seemed easily > seperable from the resolution part of the system. The query methods > for the attribute value pairs were straight forward and secure but really > weren't tied to how resolution happened, right? > > > The other is the > > identity reference for "content holder" (e.g. consumer identity). > > I.e. you assign some identifier to the entities involved in the transaction? > > > What makes handle system unique in this case is that it provides a secured > > name resolution service (for name attribute binding), > > I wouldn't say that the handle system is unique in that regard. The entire > URI Resoluion process was built to be as secured as you wanted it to be. > Heck, since Bill built the handle resolution system to mirror the URN > resolution mechanism they're pretty much identical. > > > , and allows ownership to be > > defined per name (vs. URL, where the name administration belongs to the site > > manager). This is particularly important for individuals to be able to > > manage their identity attributes, including their public keys. > > Can you explain that one further? Are you suggesting that URIs that > have domain-names somehow confer ownership semantics? We should be > very clear here since whether or not a URI is a name has everything to do > with how you actually use it and nothing to do with what it actually looks > like... > > > The point I was trying to make in my earlier message is that we probably > > need to pay equal attention for identity or trust management as we do for > > content management. And I want to understand better the nature of the > > identity used in DRM application before we move further into the framework. > > Same here. As yet I can't see a reason that URIs are no sufficient. You > have a requirement to identifiy all parties in the transaction but > that just means you assign a URI to the parties involved as well... > > -MM > > -- > -------------------------------------------------------------------------- ------ > Michael Mealling | Vote Libertarian! | urn:pin:1 > michael@neonym.net | | http://www.neonym.net > | | go:Michael Mealling From Michael Mealling Wed May 23 18:50:34 2001 From: Michael Mealling (Michael Mealling) Date: Wed, 23 May 2001 13:50:34 -0400 Subject: [IETF-IDRM] Re: [IDRM] DRM Taxonomy work -- drm framework... -- handle system In-Reply-To: <"from ssun"@cnri.reston.va.us> References: <5.0.0.25.2.20010514155912.0185c780@pop.ne.mediaone.net> <4.3.2.7.2.20010517141924.068f98c8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010521095254.04469ee8@mira-sjc5-6.cisco.com> <006001c0e34e$2cc005b0$0a00a8c0@S2000> <20010523101044.D7549@bailey.dscga.com> <00bd01c0e3ab$3e970010$5b041b0a@S2000> Message-ID: <20010523135034.K7549@bailey.dscga.com> On Wed, May 23, 2001 at 01:10:19PM -0400, Sam X. Sun (@S2000) wrote: > I agree with you that DRM doesn't have to stick with any specific technology > for its process. All we wanted here is to understand the process, and > identify technologies that can be applied to it... Great! There's alot of stuff like this being handled in the RDF/Semantic Web areas in the W3C so that's one place we really should be watching since it'd be a shame for the IETF and the W3C to diverge here.... > In terms of Handle System and URN, I would say that they are quite different > now in terms of how they work and the issues that they want to address. Sure. From what Larry was talking about, the system is much more concerned about the rights metadata than the identifier resolution process... > Handle system started about the same time PURL and URN started, trying to > address persistence issue of URL namespace. But later we found that > persistence is more of a social and/or management issue than a mere > technical one. Agreed. But that doesn't negate the fact that if you know the identifier is supposed to be persistent you can make a lot of safe assumptions... > While Handle System does provide a technical approach to > encourage more persistent namespace management, we have put more focus on > service security, Which is one thing this group will really need... > distributed name administration, What's being adminstered? Is that for provisioning of the identifier or managing the metadata associated with the object being identified? The first is interesting (and actually what the PROVREG group is doing.) The second is a metadata service feature.... > internationalization > (i18n), and service scalability. It might be helpful if you can read the > latest HS drafts to understand the difference... I'll go check 'em out. Has it changed that radically? > On the other hand, I see no > reason why Handle System cannot work with URN. One way to do it is to > register HS namespace as a namespace under URN, as we discussed earlier last > year. That should be fairly painless. I'll send you the template.... > The issues that we need to address are how to make sure that the NAPTR > approach won't become a bottleneck, It really can't. You only do one lookp and the record has a time to live of several _years_. From my analysis you end up doing the _exact_ same number of lookups for NAPTR records in the degenerative case (which handles would be) as you do for A records.... > and how to achieve service security over such approach. The same way you are now. URI resolution just gets you to the authoritative server for that identifier. How secure it is after that point is up to you and the types of protocols/services you require to do the task. > Maybe we should discuss these in a separate thread, or bring > them to the URN working group... I think that would be best. We don't want to bug these guys with identifier stuff to much. ;-) > Regarding URI and HS, I'm not sure if they are comparable. I tend to think > that URI is a collection of name services, and Handle System is just a > specific one, under a specific protocol. Semi-right. A URI is an identifier, nothing else. Some identifiers have _default_ methods for resolving into a representation of the abstract object they identifier but there is no requirement that it be the only method. > While some members of URI can be as > secure as you want, others can be totally insecure. I wonder if it's > appropriate to say a URI in general is secure, or carries any semantic > meaning (a name, an address, an identifier, etc)? Correct. URIs themselves say nothing about security since they're just identifiers. Its how you use them that ends up being secure or not secure. I.e. if I use an http URI in some service where every single entity is signed and encrypted then I'm using that URI securely. The URI itself doesn't create or require security.... > In fact, because DNS is > not secure as we know of today, that makes any name service based on DNS > questionable in their security. Not true. While some aspects of DNSSEC are still being worked on. It is very possible to have trusted DNS in normal operation. > The Handle System is designed to be > independent of DNS, and to address the security and i18n issues that DNS is > struggling to overcome. And the URI resolution mechanism I mentioned solve those problems as well. (Besides, i18n issues aren't really identifier related issues anyway.) > It has the advantage that it's starting from > scratch, and doesn't have to deal with the backward compatibility issues > that DNS has to take care of... On the other hand, we are in the process of > defining handle system URI syntax for handles to be used in web context. In > that sense, Handle system defines a namespace under URI, and we are in > agreement there. Not really. My suggestion is that any DRM shouldn't need to make requirements about the identifier itself. Any URI should be able to be used to find out about and get rights enabled access to any object. Digital Rights Management has about zero to do with the identifier used to talk about the object.... > In fact, I'm more inclined to think that Handle System is in par with DNS. I'm more inclined to think of the RESCAP Working Group actually. > In fact, if DNS can address security, i18n, access control on name > attributes, and to allow individuals to manage the names they registered, we > probably won't need the Handle System. With the exception of that last item, this is _exactly_ what RESCAP was chartered to do. That last item, in my opinion, is not a requirement of digital rights management. Why do I have to use an identifier that is registered with some third party? Most folks would like to be able to manage the digital rights of http://www.joe-blow.com/music/my-music.midi without having to create yet another identifier for it.... > On the other hand, people from DNS > working group has refused to apply DNS as a general name service other than > network-address translation, which makes us think that an independent name > service would be helpful... Sure. Everyone should consider the DNS to be at the end of its usefullness. It was never intended to be any of the things you listed there. Where did the DNS come into this anyway? I don't think anyone has made the suggestion that currently deployed DNS infrastructure can handle any of this. This is why the URN working group did what it did. This is why the IESG is creating uri.arpa as an infrastructure level Internet technology for reliable, secure URI services such as caching/replication, metadata, access control, policy, etc... There has been _considerable_ work done in the IETF in this particular area. I'm just suggesting that this group use that work and not chuck all of it in favor of one very verticle solution. Make the system modular and make it use the identifier infrastructure that the IETF and the W3C are standardizing on... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net | | go:Michael Mealling From thardjono@mediaone.net Wed May 23 19:31:38 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:31:38 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523143135.01b59570@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 15:01:49 +1000 >From: Renato Iannella >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >To: ietf-idrm@lists.elistx.com >X-Mailer: Mulberry/2.0.7 (MacOS) >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > > >--On 21/5/01 10:25 AM -0400 Jason Petrone wrote: > >>Imagine a system where the author of a book would receive notification >>from Barnes & Noble whenever a copy of her book was sold. This would >>give her much more bargaining power with her publisher, should it claim >>sales were lower than they were. I am told this is a real problem for >>authors of books and music which sell slowly. > >Such systems are becoming a reality. For example, the Ozauthors >ebook site [1] pays direct to all rightsholders for each >sale and all rightsholders (including authors) can see transaction >histories. (This is clearly in favour of the content creators >and "solves" the current "random-sampling" methods used by >collection agencies.) > >>The prerequisites for end-to-end DRM need to be defined. MPEG-21 outlines >>four broad requirements for DRM: >> >>Identification >>Description >>Management >>Protection > >Just to update the seven MEPG-21 activities: > >1. Digital Item Declaration (a uniform and flexible abstraction and >interoperable schema for declaring Digital Items); > >2. Digital Item Identification and Description (a framework for >identification and description of any entity regardless of its nature, >type or granularity); > >3. Content Handling and Usage (provide interfaces and protocols that >enable creation, manipulation, search, access, storage, delivery, and >(re)use of content across the content distribution and consumption value >chain); > >4. Intellectual Property Management and Protection (the means to enable >content to be persistently and reliably managed and protected across a >wide range of networks and devices); > >5. Terminals and Networks (the ability to provide interoperable and >transparent access to content across networks and terminals); > >6. Content Representation (how the media resources are represented); >Event Reporting (the metrics and interfaces that enable Users to >understand precisely the performance of all reportable events within the >framework); > > >>These sound right to me, though it still leaves the difficult task of >>defining each in a general sense, and not just for motion pictures. > >MPEG-21 is more broader than just audio/video. It purposely uses >the term "Digital Item" to mean any "structured digital object with a >standard representation, identification and meta-data". > > > >Cheers...Renato >Chief Scientist, IPR Systems Pty Ltd \ > > >[1] http://www.ozauthors.com.au/ From ssun@cnri.reston.va.us Wed May 23 20:50:43 2001 From: ssun@cnri.reston.va.us (Sam X. Sun (@S2000)) Date: Wed, 23 May 2001 15:50:43 -0400 Subject: [IETF-IDRM] Re: [IDRM] DRM Taxonomy work -- "content holder" vs. "content owner" References: <5.0.0.25.2.20010514155912.0185c780@pop.ne.mediaone.net> <4.3.2.7.2.20010517141924.068f98c8@mira-sjc5-6.cisco.com> <5.0.0.25.2.20010519144826.01b563f0@pop.ne.mediaone.net> <5.0.0.25.2.20010523110531.01bab200@pop.ne.mediaone.net> Message-ID: <012c01c0e3c1$a744a160$5b041b0a@S2000> Ok, Thomas, I think we are getting closer here in understanding each other :)... Like you said, I was trying to see if it's appropriate to say that "Content-Holder means a holder of an instance of a digital Content, where that holder is *not* the legal owner of the copyright of the Content". The emphasis is on the INSTANCE of a digital content, while the copyright might be the metadata associated to EVERY instance of the digital content, or the content class if such thing exists. In other words, is it appropriate to say that copyright defines "ownership" of the digital content, while digital rights defines "operational rights" of the digital content? Clearly, they are also closely related, but the former is independent of each instance, and doesn't depend on who the instance "holder" is... In the example you gave, could we say that you and your neighbor acquires certain digital rights to operate on the acquired instance of the digital content, but not the "ownership" (e.g. copyright, or some other legal rights) of the WORK inscribed by that instance? Sam ----- Original Message ----- From: "Thomas Hardjono" To: "Sam X. Sun (@S2000)" ; Sent: Wednesday, May 23, 2001 11:16 AM Subject: Re: [IDRM] DRM Taxonomy work -- "content holder" vs. "content owner" > > OK, I'm still rather confused about the Content-Holder, but let me try a > very simple example: > > - Madonna issues a new song downloadable as MP3 through some > Content-Distributor. > > Here Madonna (or he record company/publisher) is the Content-Owner. > > - I download the song and pay $2 (reasonable I think :) > > Here I am the Content-Holder (where the Content is that MP3 file). > I only own my copy (1 copy) of that Content. I do not have further > rights. > > In this scenario, if I gave a copy of Madonna's MP3 song to my neighbor, > then clearly my neighbour has to (again) pay the Content-Owner (ie. Madonna > or her record company/publisher). > > Neither I nor my neighbour own the *rights* to that Content/MP3. > > Thus, I think the term Content-Holder means a holder of an instance > of a digital Content, where that holder is *not* the legal > owner of the copyright of the Content. > > Hmmmm, am I on track here? Isn't the Content-Holder = Consumer ? > > cheers, > > thomas > ------ > > At 5/23/01||01:40 AM, Sam X. Sun (@S2000) wrote: > >My second question is regarding the content holder vs. content owner. > > > >When I say "content holder", I'm using it as a general term of "owner of an > >instance of digital content", or "a kind of digital content sharing some > >common attribute". The "content holder" can be "consumer", "distributor", > >"retailer", "publisher", and "content creator", depending on the "digital > >rights" he has and/or acquired for his copy of digital content. I tends of > >think of "consumer" as a relative term, depending on the view point. For > >example, "retailer" and "distributor" may all be treated as "consumer" (with > >special "distribution" rights) from a "publisher", and the "publisher" can > >generate money, directly or indirectly, from any kind of "consumer" of its > >content. > > > >I was trying to avoid using "content owner" but "content holder", fearing > >that the "content holder" is not necessarily the "owner of the content". > >Should we first try to clarify these terminologies? I guess this is one of > >the reasons Mark started this thread. > > > > > >Sam > > > >----- Original Message ----- > >From: "Thomas Hardjono" > >To: > >Sent: Saturday, May 19, 2001 3:17 PM > >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... > > > > > > > > > > Hi Sam, > > > > > > I don't think you are off-track. You have brought up some good issues > >which > > > I'll comment below (I'll send comments about Mark's posting separately). > > > > > > > > > At 5/19/01||10:47 AM, Sam X. Sun (@S2000) wrote: > > > >Hi, > > > > > > > >I think it's a good application model to classify in end-to-end DRM > > > >relationships in terms of content provider and distributor, and > >distributor > > > >and content consumer. They represent some real world scenarios that DRM > >will > > > >have to address. On the other hand, I wonder if we could further model > >the > > > >underlying DRM framework in terms of transactions of certain entities > >(e.g. > > > >digital content) among other kinds of entities (e.g. content holder), and > > > >the transaction may be reflected in terms of exchange/update of digital > > > >rights bound to each content instance acquired by the content holder. > > > > > > > >In other words, I wonder whether it's reasonable to categorize the > >entities > > > >that DRM framework has to deal with in terms of: > > > > > > > > 1. the digital content (per instance) > > > > 2. the content holder (current or potential) > > > > > > > > > > > >And think of the digital rights as state information of the digital > >content > > > >hold by content holder. From this, one may imagine building mechanisms > > > >within the framework to: > > > > > > > > * Associate rights per digital content acquired by the content > >holder > > > > * Identify content holder, along with its authentication attributes. > > > > * Exchange/update digital rights per digital content among content > > > >holders > > > > * Facilitate/monitor/trace legitimate digital contents for their > >proper > > > >use > > > > * Report illegal content upon showing up within the framework > >(doable?) > > > > etc... > > > > > > I'm unclear about the term "content holder" above. I assume you mean > > > the Consumer that actually uses (reads/views/plays) the Content, > > > since Content not in the Consumer's hands will not generate money. > > > > > > As I understand it, the Digital-Rights (or Rights-Metadata) can be > > > Content-specific only or can be tied to both the Content and the Consumer. > > > > > > The distinction becomes relevant when we talk about the Business Models. > > > Thus, say in one business model, the Content-Creator/Owner may > > > specify usage rights in the Rights-Metadata (without mentioning specific > > > Customers). Assuming the Content-Creator/Owner has a business > >relationship > > > with a Distributor, then perhaps it is up to the Distributor(s) to > > > create further Rights-Metadata that is Customer-specific (eg. for Customer > > > who are members of the video-club, say). > > > > > > WRT your second bullet above, when the Distributor starts dealing > > > with Consumers (i.e content holder) does the Consumer's authentication > > > attributes becomes extremely relevant. It here that I think individual > > > certificates will become a key issue. A Customer's certificate will > >become > > > more important and persistent comapred to his/her credit card number. > > > And accounting and tracking may also perhaps be based on certificates. > > > > > > In terms of the transferability of Contents, most systems I have seen > > > or read about deploy some kind of verification/checking each time > > > the Content's ownership is transffered. Thus, in basic terms, if I sell > > > my (encrypted) MP3 file on eBay, then the purchaser will have to register > > > with the Distributor (or the entity claiming to be the contact-point for > >that > > > Content) and obtain a copy of the key (or a derived version). > > > > > > This model does not really fit into the "pure" P2P distribution scheme, > > > but it ensures continuous revenue for the distributor (who gets > > > additional new customer info). This model also allos tracking of > > > moved/sold Contents on the net. > > > > > > > > > > > > >Assumptions here are that everyone can obtain a copy of digital content > > > >freely, but need to acquire (e.g. via purchase) adequate rights to be > >able > > > >to "use" it. Depending on the rights associated to the digital content > > > >acquired by the content holder, the content holder could act as a > >publisher, > > > >a distributor, a retailer, or end consumer. > > > > > > This idea is cool and reflects more of the pure P2P approach. I don't > > > know if the big players will like the notion of a Consumer (content > >holder) > > > taking the role of publisher/distributor/retailer. > > > > > > I think the term P2P itself has been overused and means different things > > > to different people. I used it to mean the non-hierarchical/flat > > > distributed system that runs democratically from one user's machine > > > to another. > > > > > > Other people seem to mean P2P as "group-sharing of files" regardless > > > of how the files are managed (ie. the files could be sitting on > > > a single machine/server with everyone connecting to that server). > > > This later view is similar to the mainframe usage model of the 70s. > > > > > > > > > > > > >A transaction of digital content > > > >from a retailer to consumer could be modeled as retailer (with the right) > >to > > > >generate a new instance of the digital content, assign it with consumer > > > >rights, and "give" it to the consumer (along with the consumer rights). > > > > > > OK, so here is an interesting question: can BlockBuster Video make > > > copies of videos (ie. a new instant of content) in their backroom > > > and lease them? (and I don't mean replacements for broken/stolen > > > videocassettes). > > > > > > > > > > > > >A consumer may later become a retailer after obtaining the "retail" > >rights > > > >for its copy of digital content... > > > > > > Hmmm... > > > > > > cheers, > > > > > > thomas > > > ------ > > > > From thardjono@mediaone.net Wed May 23 19:28:14 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:28:14 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523142810.01bb5e20@pop.ne.mediaone.net> >Date: Mon, 21 May 2001 17:17:22 -0400 >From: Thomas Hardjono >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >X-Sender: thardjono@pop.ne.mediaone.net (Unverified) >To: Jason Petrone , ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >Hi, > >Can you elaborate more on these 4 broad requirements from MPEG21? > >It would be useful, as there seems to be several DRM-related >groups in different sectors of the Internet industry. > >The last two (management and protection) sounds interesting and >relevant to IDRM. > > >cheers, > >thomas >------ > > >At 5/21/01||10:25 AM, Jason Petrone wrote: > > >>The prerequisites for end-to-end DRM need to be defined. MPEG-21 outlines >>four broad requirements for DRM: >> >>Identification >>Description >>Management >>Protection >> >>These sound right to me, though it still leaves the difficult task of >>defining >>each in a general sense, and not just for motion pictures. >> >>Jason From thardjono@mediaone.net Wed May 23 19:27:37 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:27:37 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523142659.01bc04c0@pop.ne.mediaone.net> >Date: Mon, 21 May 2001 10:25:59 -0400 >From: Jason Petrone >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >To: ietf-idrm@lists.elistx.com >Mail-followup-to: Jason Petrone , > ietf-idrm@lists.elistx.com >User-Agent: Mutt/1.3.17i >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >On Sat, May 19, 2001 at 10:47:39AM -0400, Sam X. Sun (@S2000) wrote: > > I think it's a good application model to classify in end-to-end DRM > > relationships in terms of content provider and distributor, and distributor > > and content consumer. > >It might be advantageous to also express the relationship between content >creator and content provider. Under the current content delivery system >content providers(publishers, record labels) pay authors, songwriters, etc. >based on sales. Creators rely on the providers to monitor sales, and >sometimes >do not receive the full compensation they are due, simply because they do not >have direct access to sales figures. > >Imagine a system where the author of a book would receive notification from >Barnes & Noble whenever a copy of her book was sold. This would give her much >more bargaining power with her publisher, should it claim sales were lower >than >they were. I am told this is a real problem for authors of books and music >which sell slowly. > >The prerequisites for end-to-end DRM need to be defined. MPEG-21 outlines >four broad requirements for DRM: > >Identification >Description >Management >Protection > >These sound right to me, though it still leaves the difficult task of defining >each in a general sense, and not just for motion pictures. > >Jason From thardjono@mediaone.net Wed May 23 19:28:37 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:28:37 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523142834.01b81eb0@pop.ne.mediaone.net> >Date: Mon, 21 May 2001 16:21:24 -0700 >From: Mark Baugher >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >X-Sender: mbaugher@mira-sjc5-6.cisco.com >To: Jason Petrone >Cc: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >At 10:25 AM 5/21/2001 -0400, Jason Petrone wrote: >>On Sat, May 19, 2001 at 10:47:39AM -0400, Sam X. Sun (@S2000) wrote: >> > I think it's a good application model to classify in end-to-end DRM >> > relationships in terms of content provider and distributor, and >> distributor >> > and content consumer. >> >>It might be advantageous to also express the relationship between content >>creator and content provider. Under the current content delivery system >>content providers(publishers, record labels) pay authors, songwriters, etc. >>based on sales. Creators rely on the providers to monitor sales, and >>sometimes >>do not receive the full compensation they are due, simply because they do not >>have direct access to sales figures. > >That's a good point. We have been treating the content provider as the >representative of all rights holders in the value chain under the supposition >that the content-provider's enterprise has established mechanisms for >clearing the transactions among all that have claims to a work. > >My understanding is that the rights-holder relationships are much >simpler for movies than for music, where movie studios generally hold all >rights to their works but record labels don't (see >http://dailynews.yahoo.com/h/nf/20010518/tc/9847_1.html >for example). > > >>Imagine a system where the author of a book would receive notification from >>Barnes & Noble whenever a copy of her book was sold. This would give her >>much >>more bargaining power with her publisher, should it claim sales were >>lower than >>they were. I am told this is a real problem for authors of books and music >>which sell slowly. >> >>The prerequisites for end-to-end DRM need to be defined. MPEG-21 outlines >>four broad requirements for DRM: >> >>Identification >>Description >>Management >>Protection > >Another good point. I think we consider the MPEG-21 taxonomy in light of >Internet requirements. > >Mark > > >>These sound right to me, though it still leaves the difficult task of >>defining >>each in a general sense, and not just for motion pictures. >> >>Jason From thardjono@mediaone.net Wed May 23 19:28:49 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:28:49 -0400 Subject: [IETF-IDRM] Fwd: MPEG-21 (was Re: [IDRM] DRM Taxonomy work -- drm framework...) Message-ID: <5.0.0.25.2.20010523142846.01b9f170@pop.ne.mediaone.net> >Date: Tue, 22 May 2001 10:21:17 -0400 >From: Jason Petrone >Subject: MPEG-21 (was Re: [IDRM] DRM Taxonomy work -- drm framework...) >To: ietf-idrm@lists.elistx.com >Mail-followup-to: Jason Petrone , > ietf-idrm@lists.elistx.com >User-Agent: Mutt/1.3.17i >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >On Mon, May 21, 2001 at 05:17:22PM -0400, Thomas Hardjono wrote: > > Can you elaborate more on these 4 broad requirements from MPEG21? > >I must admit, I haven't been following MPEG-21 too closely, but I will do >my best to explain. > >Keep in mind that it is still a work in progress, and is more reflective of >requirements than actual solutions. > >Identification: Content items are each assigned unique identifiers. This > serves the same purpose as ISBNs for books and ISSNs for > periodicals. Identification is a vital first step for the > management of any kind of content. > >Description : The MPEG-21 working group is putting together a schema which > can be used to express intellectual property metadata. I > think this is something like http://www.indecs.org/. The > working group intends to also define standard access methods > for retrieving identifiers and descriptions(i.e. some kind > of registry I suppose). > >Management : This deals with content delivery, physical format > interoperability, payment/subscription models, etc. > >Protection : My understanding is that this area addresses consumer privacy, > and technologies like watermarking and encryption. > > >Jason From thardjono@mediaone.net Wed May 23 19:29:09 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:29:09 -0400 Subject: [IETF-IDRM] Fwd: RE: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523142905.01b82c90@pop.ne.mediaone.net> >From: Rob Koenen >To: Thomas Hardjono , > Jason Petrone > , ietf-idrm@lists.elistx.com >Subject: RE: [IDRM] DRM Taxonomy work -- drm framework... >Date: Tue, 22 May 2001 16:26:20 -0700 >X-Mailer: Internet Mail Service (5.5.2653.19) > >I think the best way to do this is to study the >MPEG-21 technical report. > >Please go to www.cselt.it/mpeg and look in the section >Not News. > >I am offline now, so I cannot give the direct link. > >Rob > > > -----Original Message----- > > From: Thomas Hardjono [mailto:thardjono@mediaone.net] > > Sent: Monday, 21 May, 2001 14:17 > > To: Jason Petrone; ietf-idrm@lists.elistx.com > > Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... > > > > > > > > Hi, > > > > Can you elaborate more on these 4 broad requirements from MPEG21? > > > > It would be useful, as there seems to be several DRM-related > > groups in different sectors of the Internet industry. > > > > The last two (management and protection) sounds interesting and > > relevant to IDRM. > > > > > > cheers, > > > > thomas > > ------ > > > > > > At 5/21/01||10:25 AM, Jason Petrone wrote: > > > > > > >The prerequisites for end-to-end DRM need to be defined. > > MPEG-21 outlines > > >four broad requirements for DRM: > > > > > >Identification > > >Description > > >Management > > >Protection > > > > > >These sound right to me, though it still leaves the > > difficult task of defining > > >each in a general sense, and not just for motion pictures. > > > > > >Jason > > From thardjono@mediaone.net Wed May 23 19:29:23 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:29:23 -0400 Subject: [IETF-IDRM] Fwd: RE: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523142920.01b9e370@pop.ne.mediaone.net> >Date: Tue, 22 May 2001 18:10:33 -0700 >From: Mark Baugher >Subject: RE: [IDRM] DRM Taxonomy work -- drm framework... >X-Sender: mbaugher@mira-sjc5-6.cisco.com >To: Rob Koenen >Cc: Thomas Hardjono , > Jason Petrone , ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >Thanks, Rob > I am online >http://www.cselt.it/mpeg/public/mpeg-21_pdtr.zip >is the pointer I think Rob is referring to. I promised Thomas I'd send >it this morning. > >Mark >At 04:26 PM 5/22/2001 -0700, Rob Koenen wrote: >>I think the best way to do this is to study the >>MPEG-21 technical report. >> >>Please go to www.cselt.it/mpeg and look in the section >>Not News. >> >>I am offline now, so I cannot give the direct link. >> >>Rob >> >> > -----Original Message----- >> > From: Thomas Hardjono [mailto:thardjono@mediaone.net] >> > Sent: Monday, 21 May, 2001 14:17 >> > To: Jason Petrone; ietf-idrm@lists.elistx.com >> > Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >> > >> > >> > >> > Hi, >> > >> > Can you elaborate more on these 4 broad requirements from MPEG21? >> > >> > It would be useful, as there seems to be several DRM-related >> > groups in different sectors of the Internet industry. >> > >> > The last two (management and protection) sounds interesting and >> > relevant to IDRM. >> > >> > >> > cheers, >> > >> > thomas >> > ------ >> > >> > >> > At 5/21/01||10:25 AM, Jason Petrone wrote: >> > >> > >> > >The prerequisites for end-to-end DRM need to be defined. >> > MPEG-21 outlines >> > >four broad requirements for DRM: >> > > >> > >Identification >> > >Description >> > >Management >> > >Protection >> > > >> > >These sound right to me, though it still leaves the >> > difficult task of defining >> > >each in a general sense, and not just for motion pictures. >> > > >> > >Jason >> > From thardjono@mediaone.net Wed May 23 17:56:14 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 12:56:14 -0400 Subject: [IETF-IDRM] test -- ignore Message-ID: <5.0.0.25.2.20010523125557.01bc5260@pop.ne.mediaone.net> test -- ignore From thardjono@mediaone.net Wed May 23 19:29:38 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:29:38 -0400 Subject: [IETF-IDRM] Fwd: RE: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523142935.01bb5800@pop.ne.mediaone.net> >From: Rob Koenen >To: Mark Baugher , Rob Koenen >Cc: Thomas Hardjono , > Jason Petrone > , ietf-idrm@lists.elistx.com >Subject: RE: [IDRM] DRM Taxonomy work -- drm framework... >Date: Tue, 22 May 2001 19:40:33 -0700 >X-Mailer: Internet Mail Service (5.5.2653.19) > >Thanks Mark - I am back online and that's inded the link I meant. > >(The section was obviously called Hot News rather than Not News. :-) > >Rob >-----Original Message----- >From: Mark Baugher [mailto:mbaugher@cisco.com] >Sent: Tuesday, 22 May, 2001 18:11 >To: Rob Koenen >Cc: Thomas Hardjono; Jason Petrone; ietf-idrm@lists.elistx.com >Subject: RE: [IDRM] DRM Taxonomy work -- drm framework... > >Thanks, Rob > I am online >http://www.cselt.it/mpeg/public/mpeg-21_pdtr.zip >is the pointer I think Rob is referring to. I promised Thomas I'd send >it this morning. > >Mark >At 04:26 PM 5/22/2001 -0700, Rob Koenen wrote: >>I think the best way to do this is to study the >>MPEG-21 technical report. >> >>Please go to www.cselt.it/mpeg and look in the section >>Not News. From thardjono@mediaone.net Wed May 23 19:31:09 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:31:09 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work Message-ID: <5.0.0.25.2.20010523143106.01b9d200@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 13:30:54 +1000 >From: Renato Iannella >Subject: Re: [IDRM] DRM Taxonomy work >To: ietf-idrm@lists.elistx.com >X-Mailer: Mulberry/2.0.7 (MacOS) >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > > >--On 17/5/01 3:33 PM -0700 Mark Baugher wrote: > >>We want to begin developing our taxonomy and putting flesh to an IDRM >>model. This note outlines the general approach that we are taking and >>we're soliciting any comments that people might have. Also, if others >>are interested in working on a draft document for the taxonomy, please >>let us know. > >The OpenEBook Forum published "A Framework for the Epublishing Ecology" >which would be useful material for the taxonomy: > >%20Ecology.pdf> > > >Cheers...Renato >Chief Scientist, IPR Systems Pty Ltd From thardjono@mediaone.net Wed May 23 19:31:19 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:31:19 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523143117.01bb63b0@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 13:43:09 +1000 >From: Renato Iannella >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >To: ietf-idrm@lists.elistx.com >X-Mailer: Mulberry/2.0.7 (MacOS) >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > > >--On 19/5/01 3:17 PM -0400 Thomas Hardjono wrote: > >>>Sam X. Sun (@S2000) wrote: >>>Assumptions here are that everyone can obtain a copy of digital content >>>freely, but need to acquire (e.g. via purchase) adequate rights to be >>>able to "use" it. Depending on the rights associated to the digital >>>content acquired by the content holder, the content holder could act as >>>a publisher, a distributor, a retailer, or end consumer. >> >>This idea is cool and reflects more of the pure P2P approach. I don't >>know if the big players will like the notion of a Consumer (content >>holder) taking the role of publisher/distributor/retailer. > >In the ebook-world, this is called "Superdistribution" and >is a valid business model being used by them. That is, they are >happy for consumers to pass-on their content as the recipient >will then be re-directed to purchase a license when they try >to open/run the content. (eg Adobe's secure PDF does this.) > >>OK, so here is an interesting question: can BlockBuster Video make >>copies of videos (ie. a new instant of content) in their backroom >>and lease them? (and I don't mean replacements for broken/stolen >>videocassettes). > >Not without obtaining the "rights" to do so. I suspect that such >video stores negotiate the rights to loan X copies from the >video distributor (who, in turn has the "rights" to make such >deals - granted to them by the movie rights holders)...A chain >or layers of rights holders and permissions... > > > >Cheers...Renato >Chief Scientist, IPR Systems Pty Ltd From thardjono@mediaone.net Wed May 23 19:31:29 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:31:29 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523143126.01b5a9b0@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 14:48:16 +1000 >From: Renato Iannella >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >To: ietf-idrm@lists.elistx.com >X-Mailer: Mulberry/2.0.7 (MacOS) >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > > >--On 21/5/01 10:00 AM -0700 Mark Baugher wrote: > >>I think that >>there is often some entity in the chain that has special claims >>(such as legally owning the content) that is distinct from the >>current "content holder." > >Yes, and like copyright, is usually jurisdiction-based. > >For example, many countries now have Moral Rights (see Australian >version at [1]). In this case, as the author of content that >I sold *all* rights to a Publisher, I still can make claims to >protect my reputation (for example). > > >Cheers...Renato >Chief Scientist, IPR Systems Pty Ltd > >[1] http://www.copyright.org.au/PDF/InfoSheets/G043v08.pdf From thardjono@mediaone.net Wed May 23 19:31:48 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:31:48 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] draft-irtf-idrm-handle-system-protocol-00.txt Message-ID: <5.0.0.25.2.20010523143145.01bc6510@pop.ne.mediaone.net> >Date: Tue, 22 May 2001 22:26:05 -0700 >From: Mark Baugher >Subject: [IDRM] draft-irtf-idrm-handle-system-protocol-00.txt >X-Sender: mbaugher@mira-sjc5-6.cisco.com >To: ietf-idrm@lists.elistx.com >Cc: ssun@cnri.reston.va.us, llannom@cnri.reston.va.us >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >I have a number of comments on this draft. I also plan to post comments >on the two other handle drafts, draft-irtf-idrm-handle-system-def-00.txt >and draft-irtf-idrm-handle-system-protocol-00.txt. I'll start with >draft-irtf-idrm-handle-system-00.txt comments, a couple at a time since my >other questions and comments may be resolved along the way. > >My first comment is that there does not seem to be name-resolution draft >in the mix. Is this not to be published? I can see a lot of uses for a >namespace that is not global, such as between a content provider >(publisher) and service provider (distributor) that want to use the >metadata facilities of handles to store rights information with the >content work and to identify one or more "official repositories" for the >content work. If you're requiring a global namespace but not publishing >the resolution mechanisms, then this seems to be an impediment to many >business-to-business uses. > >Mark From thardjono@mediaone.net Wed May 23 19:31:57 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:31:57 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] draft-irtf-idrm-handle-system-protocol-00.txt Message-ID: <5.0.0.25.2.20010523143154.01b68340@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 01:31:44 -0400 >From: Michael Mealling >Subject: Re: [IDRM] draft-irtf-idrm-handle-system-protocol-00.txt >To: Mark Baugher >Cc: ietf-idrm@lists.elistx.com, ssun@cnri.reston.va.us, > llannom@cnri.reston.va.us >Reply-to: Michael Mealling >User-Agent: Mutt/1.1.2i >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >On Tue, May 22, 2001 at 10:26:05PM -0700, Mark Baugher wrote: > > My first comment is that there does not seem to be name-resolution > draft in > > the mix. Is this not to be published? I can see a lot of uses for a > > namespace that is not global, such as between a content provider > > (publisher) and service provider (distributor) that want to use the > > metadata facilities of handles to store rights information with the > content > > work and to identify one or more "official repositories" for the content > > work. If you're requiring a global namespace but not publishing the > > resolution mechanisms, then this seems to be an impediment to many > > business-to-business uses. > >If you need name resolution then you should take a look at the >URI Resolution documents: >http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-03.txt >http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-04.txt >http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-04.txt > >Is there any reason why a DRM system needs a special namespace? I've >heard a persistence requirement from some and in that case you could easily >use URNs. But in the general case, shouldn't a URI be sufficient for >identifying the resource that is having its rights digitally managed? > > From all of the examples I've ever seen any DRM system is really just >a special function metadata service with some strong encryption thrown >in for good measure.... > >-MM > >-- >-------------------------------------------------------------------------------- >Michael Mealling | Vote Libertarian! | urn:pin:1 >michael@neonym.net | | http://www.neonym.net > | | go:Michael Mealling From thardjono@mediaone.net Wed May 23 19:32:08 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:32:08 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- digital rights... Message-ID: <5.0.0.25.2.20010523143205.01b680b0@pop.ne.mediaone.net> >From: "Sam X. Sun \(@S2000\)" >To: "Thomas Hardjono" , >Subject: Re: [IDRM] DRM Taxonomy work -- digital rights... >Date: Wed, 23 May 2001 01:38:12 -0400 >X-Mailer: Microsoft Outlook Express 5.50.4133.2400 > >Thomas, >I'm going to follow up your remarks in separate threads, so that we can keep >each message short... > >First of all, I'd like to understand better regarding the definition of >digital rights. I was under the impression that digital rights always apply >to the combination of "content" and "content holder", instead of just >"content" itself, for expressing "the permission for the 'content holder' to >operate on the 'content'". Now the question is: can we define "digital >rights" without specifying the "content holder", where the "content holder" >can be anyone ranging from consumer, distributor, or publisher? On the flip >side, can we specify "digital rights" with "content holder" alone, without >referencing the digital content? These might be trivial questions, but I >wish to get them clarified nevertheless. > > >Sam > > >----- Original Message ----- >From: "Thomas Hardjono" >To: >Sent: Saturday, May 19, 2001 3:17 PM >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... > > > > > > Hi Sam, > > > > I don't think you are off-track. You have brought up some good issues >which > > I'll comment below (I'll send comments about Mark's posting separately). > > > > > > At 5/19/01||10:47 AM, Sam X. Sun (@S2000) wrote: > > >Hi, > > > > > >I think it's a good application model to classify in end-to-end DRM > > >relationships in terms of content provider and distributor, and >distributor > > >and content consumer. They represent some real world scenarios that DRM >will > > >have to address. On the other hand, I wonder if we could further model >the > > >underlying DRM framework in terms of transactions of certain entities >(e.g. > > >digital content) among other kinds of entities (e.g. content holder), and > > >the transaction may be reflected in terms of exchange/update of digital > > >rights bound to each content instance acquired by the content holder. > > > > > >In other words, I wonder whether it's reasonable to categorize the >entities > > >that DRM framework has to deal with in terms of: > > > > > > 1. the digital content (per instance) > > > 2. the content holder (current or potential) > > > > > > > > >And think of the digital rights as state information of the digital >content > > >hold by content holder. From this, one may imagine building mechanisms > > >within the framework to: > > > > > > * Associate rights per digital content acquired by the content >holder > > > * Identify content holder, along with its authentication attributes. > > > * Exchange/update digital rights per digital content among content > > >holders > > > * Facilitate/monitor/trace legitimate digital contents for their >proper > > >use > > > * Report illegal content upon showing up within the framework >(doable?) > > > etc... > > > > I'm unclear about the term "content holder" above. I assume you mean > > the Consumer that actually uses (reads/views/plays) the Content, > > since Content not in the Consumer's hands will not generate money. > > > > As I understand it, the Digital-Rights (or Rights-Metadata) can be > > Content-specific only or can be tied to both the Content and the Consumer. > > > > The distinction becomes relevant when we talk about the Business Models. > > Thus, say in one business model, the Content-Creator/Owner may > > specify usage rights in the Rights-Metadata (without mentioning specific > > Customers). Assuming the Content-Creator/Owner has a business >relationship > > with a Distributor, then perhaps it is up to the Distributor(s) to > > create further Rights-Metadata that is Customer-specific (eg. for Customer > > who are members of the video-club, say). > > > > WRT your second bullet above, when the Distributor starts dealing > > with Consumers (i.e content holder) does the Consumer's authentication > > attributes becomes extremely relevant. It here that I think individual > > certificates will become a key issue. A Customer's certificate will >become > > more important and persistent comapred to his/her credit card number. > > And accounting and tracking may also perhaps be based on certificates. > > > > In terms of the transferability of Contents, most systems I have seen > > or read about deploy some kind of verification/checking each time > > the Content's ownership is transffered. Thus, in basic terms, if I sell > > my (encrypted) MP3 file on eBay, then the purchaser will have to register > > with the Distributor (or the entity claiming to be the contact-point for >that > > Content) and obtain a copy of the key (or a derived version). > > > > This model does not really fit into the "pure" P2P distribution scheme, > > but it ensures continuous revenue for the distributor (who gets > > additional new customer info). This model also allos tracking of > > moved/sold Contents on the net. > > > > > > > > >Assumptions here are that everyone can obtain a copy of digital content > > >freely, but need to acquire (e.g. via purchase) adequate rights to be >able > > >to "use" it. Depending on the rights associated to the digital content > > >acquired by the content holder, the content holder could act as a >publisher, > > >a distributor, a retailer, or end consumer. > > > > This idea is cool and reflects more of the pure P2P approach. I don't > > know if the big players will like the notion of a Consumer (content >holder) > > taking the role of publisher/distributor/retailer. > > > > I think the term P2P itself has been overused and means different things > > to different people. I used it to mean the non-hierarchical/flat > > distributed system that runs democratically from one user's machine > > to another. > > > > Other people seem to mean P2P as "group-sharing of files" regardless > > of how the files are managed (ie. the files could be sitting on > > a single machine/server with everyone connecting to that server). > > This later view is similar to the mainframe usage model of the 70s. > > > > > > > > >A transaction of digital content > > >from a retailer to consumer could be modeled as retailer (with the right) >to > > >generate a new instance of the digital content, assign it with consumer > > >rights, and "give" it to the consumer (along with the consumer rights). > > > > OK, so here is an interesting question: can BlockBuster Video make > > copies of videos (ie. a new instant of content) in their backroom > > and lease them? (and I don't mean replacements for broken/stolen > > videocassettes). > > > > > > > > >A consumer may later become a retailer after obtaining the "retail" >rights > > >for its copy of digital content... > > > > Hmmm... > > > > cheers, > > > > thomas > > ------ > > From thardjono@mediaone.net Wed May 23 19:32:23 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:32:23 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- "content holder" vs. "content owner" Message-ID: <5.0.0.25.2.20010523143220.01b69c90@pop.ne.mediaone.net> >From: "Sam X. Sun \(@S2000\)" >To: "Thomas Hardjono" , >Subject: Re: [IDRM] DRM Taxonomy work -- "content holder" vs. "content owner" >Date: Wed, 23 May 2001 01:40:19 -0400 >X-Mailer: Microsoft Outlook Express 5.50.4133.2400 > >My second question is regarding the content holder vs. content owner. > >When I say "content holder", I'm using it as a general term of "owner of an >instance of digital content", or "a kind of digital content sharing some >common attribute". The "content holder" can be "consumer", "distributor", >"retailer", "publisher", and "content creator", depending on the "digital >rights" he has and/or acquired for his copy of digital content. I tends of >think of "consumer" as a relative term, depending on the view point. For >example, "retailer" and "distributor" may all be treated as "consumer" (with >special "distribution" rights) from a "publisher", and the "publisher" can >generate money, directly or indirectly, from any kind of "consumer" of its >content. > >I was trying to avoid using "content owner" but "content holder", fearing >that the "content holder" is not necessarily the "owner of the content". >Should we first try to clarify these terminologies? I guess this is one of >the reasons Mark started this thread. > > >Sam > >----- Original Message ----- >From: "Thomas Hardjono" >To: >Sent: Saturday, May 19, 2001 3:17 PM >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... > > > > > > Hi Sam, > > > > I don't think you are off-track. You have brought up some good issues >which > > I'll comment below (I'll send comments about Mark's posting separately). > > > > > > At 5/19/01||10:47 AM, Sam X. Sun (@S2000) wrote: > > >Hi, > > > > > >I think it's a good application model to classify in end-to-end DRM > > >relationships in terms of content provider and distributor, and >distributor > > >and content consumer. They represent some real world scenarios that DRM >will > > >have to address. On the other hand, I wonder if we could further model >the > > >underlying DRM framework in terms of transactions of certain entities >(e.g. > > >digital content) among other kinds of entities (e.g. content holder), and > > >the transaction may be reflected in terms of exchange/update of digital > > >rights bound to each content instance acquired by the content holder. > > > > > >In other words, I wonder whether it's reasonable to categorize the >entities > > >that DRM framework has to deal with in terms of: > > > > > > 1. the digital content (per instance) > > > 2. the content holder (current or potential) > > > > > > > > >And think of the digital rights as state information of the digital >content > > >hold by content holder. From this, one may imagine building mechanisms > > >within the framework to: > > > > > > * Associate rights per digital content acquired by the content >holder > > > * Identify content holder, along with its authentication attributes. > > > * Exchange/update digital rights per digital content among content > > >holders > > > * Facilitate/monitor/trace legitimate digital contents for their >proper > > >use > > > * Report illegal content upon showing up within the framework >(doable?) > > > etc... > > > > I'm unclear about the term "content holder" above. I assume you mean > > the Consumer that actually uses (reads/views/plays) the Content, > > since Content not in the Consumer's hands will not generate money. > > > > As I understand it, the Digital-Rights (or Rights-Metadata) can be > > Content-specific only or can be tied to both the Content and the Consumer. > > > > The distinction becomes relevant when we talk about the Business Models. > > Thus, say in one business model, the Content-Creator/Owner may > > specify usage rights in the Rights-Metadata (without mentioning specific > > Customers). Assuming the Content-Creator/Owner has a business >relationship > > with a Distributor, then perhaps it is up to the Distributor(s) to > > create further Rights-Metadata that is Customer-specific (eg. for Customer > > who are members of the video-club, say). > > > > WRT your second bullet above, when the Distributor starts dealing > > with Consumers (i.e content holder) does the Consumer's authentication > > attributes becomes extremely relevant. It here that I think individual > > certificates will become a key issue. A Customer's certificate will >become > > more important and persistent comapred to his/her credit card number. > > And accounting and tracking may also perhaps be based on certificates. > > > > In terms of the transferability of Contents, most systems I have seen > > or read about deploy some kind of verification/checking each time > > the Content's ownership is transffered. Thus, in basic terms, if I sell > > my (encrypted) MP3 file on eBay, then the purchaser will have to register > > with the Distributor (or the entity claiming to be the contact-point for >that > > Content) and obtain a copy of the key (or a derived version). > > > > This model does not really fit into the "pure" P2P distribution scheme, > > but it ensures continuous revenue for the distributor (who gets > > additional new customer info). This model also allos tracking of > > moved/sold Contents on the net. > > > > > > > > >Assumptions here are that everyone can obtain a copy of digital content > > >freely, but need to acquire (e.g. via purchase) adequate rights to be >able > > >to "use" it. Depending on the rights associated to the digital content > > >acquired by the content holder, the content holder could act as a >publisher, > > >a distributor, a retailer, or end consumer. > > > > This idea is cool and reflects more of the pure P2P approach. I don't > > know if the big players will like the notion of a Consumer (content >holder) > > taking the role of publisher/distributor/retailer. > > > > I think the term P2P itself has been overused and means different things > > to different people. I used it to mean the non-hierarchical/flat > > distributed system that runs democratically from one user's machine > > to another. > > > > Other people seem to mean P2P as "group-sharing of files" regardless > > of how the files are managed (ie. the files could be sitting on > > a single machine/server with everyone connecting to that server). > > This later view is similar to the mainframe usage model of the 70s. > > > > > > > > >A transaction of digital content > > >from a retailer to consumer could be modeled as retailer (with the right) >to > > >generate a new instance of the digital content, assign it with consumer > > >rights, and "give" it to the consumer (along with the consumer rights). > > > > OK, so here is an interesting question: can BlockBuster Video make > > copies of videos (ie. a new instant of content) in their backroom > > and lease them? (and I don't mean replacements for broken/stolen > > videocassettes). > > > > > > > > >A consumer may later become a retailer after obtaining the "retail" >rights > > >for its copy of digital content... > > > > Hmmm... > > > > cheers, > > > > thomas > > ------ > > From thardjono@mediaone.net Wed May 23 19:32:35 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:32:35 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523143233.01c322a0@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 02:03:48 -0400 >From: "Sam X. Sun (@S2000)" >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >To: Mark Baugher >Cc: ietf-idrm@lists.elistx.com >X-Mailer: Microsoft Outlook Express 5.50.4133.2400 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >Mark, > >Regarding the handle system, I think there are two sides of DRM that could >take advantage of it. First is the metadata and content attribute >association, as you mentioned in the DOI application. The other is the >identity reference for "content holder" (e.g. consumer identity). What makes >handle system unique in this case is that it provides a secured name >resolution service (for name attribute binding), and allows ownership to be >defined per name (vs. URL, where the name administration belongs to the site >manager). This is particularly important for individuals to be able to >manage their identity attributes, including their public keys. > >The point I was trying to make in my earlier message is that we probably >need to pay equal attention for identity or trust management as we do for >content management. And I want to understand better the nature of the >identity used in DRM application before we move further into the framework. > >Sam > >----- Original Message ----- >From: "Mark Baugher" >To: "Sam X. Sun (@S2000)" >Cc: >Sent: Monday, May 21, 2001 1:00 PM >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... > > > > Sam > > I have two thoughts here. First is that the Handle System makes > > it possible to associate metadata with a handle (a directory entry), > > and that metadata can include a rights specification like DPRL or > > ODRL, which captures the rights relationships you mention in the > > first paragraph of your note. I know you know this; I think DOI does > > this. I expect that I'm missing something. > > > > Second, there should probably be an asymmetry between those > > who hold rights and those to whom the rights holder grants rights. > > Leaving aside copyright law, which varies between countries and > > over time, I might consider personal information that I give to a > > provider as information that I always have some special rights to > > though I may hand it over to a site that, for the sake of argument, > > agrees not to share that information with anyone else. I think that > > there is often some entity in the chain that has special claims > > (such as legally owning the content) that is distinct from the > > current "content holder." > > > > Mark > > At 10:47 AM 5/19/2001 -0400, Sam X. Sun (@S2000) wrote: > > >Hi, > > > > > >I think it's a good application model to classify in end-to-end DRM > > >relationships in terms of content provider and distributor, and >distributor > > >and content consumer. They represent some real world scenarios that DRM >will > > >have to address. On the other hand, I wonder if we could further model >the > > >underlying DRM framework in terms of transactions of certain entities >(e.g. > > >digital content) among other kinds of entities (e.g. content holder), and > > >the transaction may be reflected in terms of exchange/update of digital > > >rights bound to each content instance acquired by the content holder. > > > > > >In other words, I wonder whether it's reasonable to categorize the >entities > > >that DRM framework has to deal with in terms of: > > > > > > 1. the digital content (per instance) > > > 2. the content holder (current or potential) > > > > > > > > >And think of the digital rights as state information of the digital >content > > >hold by content holder. From this, one may imagine building mechanisms > > >within the framework to: > > > > > > * Associate rights per digital content acquired by the content >holder > > > * Identify content holder, along with its authentication attributes. > > > * Exchange/update digital rights per digital content among content > > >holders > > > * Facilitate/monitor/trace legitimate digital contents for their >proper > > >use > > > * Report illegal content upon showing up within the framework >(doable?) > > > etc... > > > > > >Assumptions here are that everyone can obtain a copy of digital content > > >freely, but need to acquire (e.g. via purchase) adequate rights to be >able > > >to "use" it. Depending on the rights associated to the digital content > > >acquired by the content holder, the content holder could act as a >publisher, > > >a distributor, a retailer, or end consumer. A transaction of digital >content > > >from a retailer to consumer could be modeled as retailer (with the right) >to > > >generate a new instance of the digital content, assign it with consumer > > >rights, and "give" it to the consumer (along with the consumer rights). A > > >consumer may later become a retailer after obtaining the "retail" rights >for > > >its copy of digital content... > > > > > >It's a bit off tracking to Mark's message:)... Just want to share some > > >thoughts. Any comments? > > > > > > > > >Cheers, > > >Sam > > > > > > > > > > > > > > >----- Original Message ----- > > >From: "Mark Baugher" > > >To: > > >Sent: Thursday, May 17, 2001 6:33 PM > > >Subject: [IDRM] DRM Taxonomy work > > > > > > > > > > Hi > > > > We wanted to begin work on developing a draft on requirements for > > > > IDRM. Sam Sun, Thomas Hardjono and I discussed this and we think that >a > > > > good first step would be to develop a taxonomy, which is a >classification > > > > of the parts of an end-to-end DRM system from which we can develop a > > >common > > > > model, or models, and common definitions - so we speak the same >language > > >to > > > > one another. > > > > > > > > Our focus in IDRM is with the IP network infrastructure aspects of > > > > DRM. To me, this means that we are less concerned with the syntax or > > > > semantics of rights specifications than in the handling and use of >rights > > > > metadata in end-to-end systems; we are less concerned with the >specifics > > >of > > > > watermarking technology or with technical protection mechanisms than >in > > >key > > > > and license distribution systems; persistent and globally-unique names >may > > > > not be as much of a concern to IDRM as are trusted repositories of >content > > > > works and metadata. So there are things in our taxonomy that are part >of > > > > end-to-end DRM systems like watermarks, TPM, and rights languages that >are > > > > not necessarily things that will be a focus of IDRM. > > > > > > > > At our last meeting, Thomas and I proposed that there are two >distinct > > > > sets of relationships in end-to-end DRM. First, is between content > > > > provider and distributor (aka "service provider"). We would use >"service > > > > provider" if the content were to be delivered to consumers over a IP > > > > network but the distributor could be a company that manufactures DVDs >or a > > > > TV broadcaster that receives files from a TV or film studio. Trusted > > > > repositories for the files and rights metadata, authorization, and > > > > authentication are IP infrastructure components that the content >provider > > > > may need to properly manage this process. It is unlikely that >technical > > > > protection mechanisms or digital licenses are needed in this > > > > business-to-business transaction. > > > > > > > > The second set of relationships is between the service provider and >the > > > > content consumer. On the Internet today, it is hard if not impossible >to > > > > unambiguously identify illegal sources and uses of copyright content >works > > > > from illegal uses. Trusted repositories and sources with rights >metadata > > > > are important to DRM in this relationship. Authorization, >authentication, > > > > and technical protection mechanisms may be needed so standard ways to >do > > > > key and license management will promote inter-operability. What we > > >should > > > > not overlook in digital rights-conferral and mechanisms that support >it is > > > > the flow of information assets from the consumer to the provider for >the > > > > purposes of authorization. In this regard, "rights management" should > > > > include the rights that consumers have with respect to information >that > > > > they provide and DRM is about information assets and not only >copyright > > >works. > > > > > > > > We want to begin developing our taxonomy and putting flesh to an IDRM > > > > model. This note outlines the general approach that we are taking and > > > > we're soliciting any comments that people might have. Also, if others >are > > > > interested in working on a draft document for the taxonomy, please let >us > > >know. > > > > > > > > Mark > > > > > > From thardjono@mediaone.net Wed May 23 19:32:44 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:32:44 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt Message-ID: <5.0.0.25.2.20010523143242.01c32b70@pop.ne.mediaone.net> >Date: Tue, 22 May 2001 23:05:59 -0700 >From: Mark Baugher >Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt >X-Sender: mbaugher@mira-sjc5-6.cisco.com >To: ietf-idrm@lists.elistx.com >Cc: ssun@cnri.reston.va.us, llannom@cnri.reston.va.us >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >Oh, by the way, this note is commenting upon >draft-irtf-idrm-handle-system-00.txt and not >draft-irtf-idrm-handle-system-protocol-00.txt - I made a mistake in the >Subject line that I'll correct in subsequent responses. > >Mark >At 10:26 PM 5/22/2001 -0700, Mark Baugher wrote: >>I have a number of comments on this draft. I also plan to post comments >>on the two other handle drafts, draft-irtf-idrm-handle-system-def-00.txt >>and draft-irtf-idrm-handle-system-protocol-00.txt. I'll start with >>draft-irtf-idrm-handle-system-00.txt comments, a couple at a time since >>my other questions and comments may be resolved along the way. >> >>My first comment is that there does not seem to be name-resolution draft >>in the mix. Is this not to be published? I can see a lot of uses for a >>namespace that is not global, such as between a content provider >>(publisher) and service provider (distributor) that want to use the >>metadata facilities of handles to store rights information with the >>content work and to identify one or more "official repositories" for the >>content work. If you're requiring a global namespace but not publishing >>the resolution mechanisms, then this seems to be an impediment to many >>business-to-business uses. >> >>Mark From thardjono@mediaone.net Wed May 23 19:32:55 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:32:55 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt Message-ID: <5.0.0.25.2.20010523143253.01c36ab0@pop.ne.mediaone.net> >Date: Tue, 22 May 2001 23:21:48 -0700 >From: Mark Baugher >Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt >X-Sender: mbaugher@mira-sjc5-6.cisco.com >To: Michael Mealling >Cc: ietf-idrm@lists.elistx.com, ssun@cnri.reston.va.us, > llannom@cnri.reston.va.us >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >hi Michael >At 01:31 AM 5/23/2001 -0400, Michael Mealling wrote: >>On Tue, May 22, 2001 at 10:26:05PM -0700, Mark Baugher wrote: >> > My first comment is that there does not seem to be name-resolution >> draft in >> > the mix. Is this not to be published? I can see a lot of uses for a >> > namespace that is not global, such as between a content provider >> > (publisher) and service provider (distributor) that want to use the >> > metadata facilities of handles to store rights information with the >> content >> > work and to identify one or more "official repositories" for the content >> > work. If you're requiring a global namespace but not publishing the >> > resolution mechanisms, then this seems to be an impediment to many >> > business-to-business uses. >> >>If you need name resolution then you should take a look at the >>URI Resolution documents: >>http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-03.txt >>http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-04.txt >>http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-04.txt > >As 5.3 of the draft concludes, the success of either urn or the Handle >System do not depend on each other. I did not glean from the Handle >System Overview I-D the idea that the Handle System would use >URN resolvers. I guess we should ask Sam and Larry about that. > > >>Is there any reason why a DRM system needs a special namespace? I've >>heard a persistence requirement from some and in that case you could easily >>use URNs. But in the general case, shouldn't a URI be sufficient for >>identifying the resource that is having its rights digitally managed? > >I really don't know if persistent naming is a requirement for DRM on the >Internet. >One issue that people have is that it is difficult or not impossible to >identify >content works and uses of content works that are legitimate from those >that are not. >EFF has introduced a special license for "free" music, if people read the >license. >One idea we have been discussing in the group is the need for an >infrastructure >that identifies legitimate repositories and legitimate uses of content >works - or >of any information assets to include the case of personal information that >is used >for the purposes of authentication. The Handle System is one system that >addresses >these requirements for content-work publishing, in my opinion. You don't >get this >with URIs today. Will publishers, record labels, movie studios want the >namespace and persistence features as well? I don't know. > > >> From all of the examples I've ever seen any DRM system is really just >>a special function metadata service with some strong encryption thrown >>in for good measure.... > >There needs to be integrity checking and authentication of the information >asset and its source. If the work is encrypted, then this entails some >authentication of the entity that's going to receive the key. Many people >would >include clearing systems as part of DRM. > >Mark > > >>-MM >> >>-- >>-------------------------------------------------------------------------------- >>Michael Mealling | Vote Libertarian! | urn:pin:1 >>michael@neonym.net | | >>http://www.neonym.net >> | | go:Michael Mealling From thardjono@mediaone.net Wed May 23 19:33:05 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:33:05 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523143302.01c32600@pop.ne.mediaone.net> >Date: Tue, 22 May 2001 23:36:48 -0700 >From: Mark Baugher >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >X-Sender: mbaugher@mira-sjc5-6.cisco.com >To: "Sam X. Sun (@S2000)" >Cc: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >Hi Sam >At 02:03 AM 5/23/2001 -0400, Sam X. Sun (@S2000) wrote: >>Mark, >> >>Regarding the handle system, I think there are two sides of DRM that could >>take advantage of it. First is the metadata and content attribute >>association, as you mentioned in the DOI application. The other is the >>identity reference for "content holder" (e.g. consumer identity). What makes >>handle system unique in this case is that it provides a secured name >>resolution service (for name attribute binding), and allows ownership to be >>defined per name (vs. URL, where the name administration belongs to the site >>manager). This is particularly important for individuals to be able to >>manage their identity attributes, including their public keys. > >I think this addresses a question Michael posed in his recent message. > > >>The point I was trying to make in my earlier message is that we probably >>need to pay equal attention for identity or trust management as we do for >>content management. And I want to understand better the nature of the >>identity used in DRM application before we move further into the framework. > >Trust is a complicated topic here. What are we trusting or whom are we >trusting with what. Someone getting a published work may want to trust >the source of the work is who the person thinks it is and that the work itself >has not been altered by anyone. At first blush, this looks like a public-key >crypto application, but the paper, "Secure Books: Protecting the >Distribution of Knowledge" (http://www.cl.cam.ac.uk/~rja14/) points out >that PKC is in many ways unsuitable because the lifetime of a public >key is too short for copyright works, which may last for 70+ years after >the author's death, and too short for copyright works, since you may >not want the author to alter the work after you have accepted and >verified its integrity. They have a catalog system approach. > >Someone releasing a published work, say, to a consumer may have >different criteria of trust. But does the distributor or service provider >need to know who the person is who is getting the content work? >If it's encrypted then there will be some authentication. But what >gets authenticated and how? Maybe the software or hardware used >to access the work gets authenticated and no information gets released >about the individual at all. I think this is among the MPEG IPMP >Requirements. > >Mark > > >>Sam >> >>----- Original Message ----- >>From: "Mark Baugher" >>To: "Sam X. Sun (@S2000)" >>Cc: >>Sent: Monday, May 21, 2001 1:00 PM >>Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >> >> >> > Sam >> > I have two thoughts here. First is that the Handle System makes >> > it possible to associate metadata with a handle (a directory entry), >> > and that metadata can include a rights specification like DPRL or >> > ODRL, which captures the rights relationships you mention in the >> > first paragraph of your note. I know you know this; I think DOI does >> > this. I expect that I'm missing something. >> > >> > Second, there should probably be an asymmetry between those >> > who hold rights and those to whom the rights holder grants rights. >> > Leaving aside copyright law, which varies between countries and >> > over time, I might consider personal information that I give to a >> > provider as information that I always have some special rights to >> > though I may hand it over to a site that, for the sake of argument, >> > agrees not to share that information with anyone else. I think that >> > there is often some entity in the chain that has special claims >> > (such as legally owning the content) that is distinct from the >> > current "content holder." >> > >> > Mark >> > At 10:47 AM 5/19/2001 -0400, Sam X. Sun (@S2000) wrote: >> > >Hi, >> > > >> > >I think it's a good application model to classify in end-to-end DRM >> > >relationships in terms of content provider and distributor, and >>distributor >> > >and content consumer. They represent some real world scenarios that DRM >>will >> > >have to address. On the other hand, I wonder if we could further model >>the >> > >underlying DRM framework in terms of transactions of certain entities >>(e.g. >> > >digital content) among other kinds of entities (e.g. content holder), and >> > >the transaction may be reflected in terms of exchange/update of digital >> > >rights bound to each content instance acquired by the content holder. >> > > >> > >In other words, I wonder whether it's reasonable to categorize the >>entities >> > >that DRM framework has to deal with in terms of: >> > > >> > > 1. the digital content (per instance) >> > > 2. the content holder (current or potential) >> > > >> > > >> > >And think of the digital rights as state information of the digital >>content >> > >hold by content holder. From this, one may imagine building mechanisms >> > >within the framework to: >> > > >> > > * Associate rights per digital content acquired by the content >>holder >> > > * Identify content holder, along with its authentication attributes. >> > > * Exchange/update digital rights per digital content among content >> > >holders >> > > * Facilitate/monitor/trace legitimate digital contents for their >>proper >> > >use >> > > * Report illegal content upon showing up within the framework >>(doable?) >> > > etc... >> > > >> > >Assumptions here are that everyone can obtain a copy of digital content >> > >freely, but need to acquire (e.g. via purchase) adequate rights to be >>able >> > >to "use" it. Depending on the rights associated to the digital content >> > >acquired by the content holder, the content holder could act as a >>publisher, >> > >a distributor, a retailer, or end consumer. A transaction of digital >>content >> > >from a retailer to consumer could be modeled as retailer (with the right) >>to >> > >generate a new instance of the digital content, assign it with consumer >> > >rights, and "give" it to the consumer (along with the consumer rights). A >> > >consumer may later become a retailer after obtaining the "retail" rights >>for >> > >its copy of digital content... >> > > >> > >It's a bit off tracking to Mark's message:)... Just want to share some >> > >thoughts. Any comments? >> > > >> > > >> > >Cheers, >> > >Sam >> > > >> > > >> > > >> > > >> > >----- Original Message ----- >> > >From: "Mark Baugher" >> > >To: >> > >Sent: Thursday, May 17, 2001 6:33 PM >> > >Subject: [IDRM] DRM Taxonomy work >> > > >> > > >> > > > Hi >> > > > We wanted to begin work on developing a draft on requirements for >> > > > IDRM. Sam Sun, Thomas Hardjono and I discussed this and we think that >>a >> > > > good first step would be to develop a taxonomy, which is a >>classification >> > > > of the parts of an end-to-end DRM system from which we can develop a >> > >common >> > > > model, or models, and common definitions - so we speak the same >>language >> > >to >> > > > one another. >> > > > >> > > > Our focus in IDRM is with the IP network infrastructure aspects of >> > > > DRM. To me, this means that we are less concerned with the syntax or >> > > > semantics of rights specifications than in the handling and use of >>rights >> > > > metadata in end-to-end systems; we are less concerned with the >>specifics >> > >of >> > > > watermarking technology or with technical protection mechanisms than >>in >> > >key >> > > > and license distribution systems; persistent and globally-unique names >>may >> > > > not be as much of a concern to IDRM as are trusted repositories of >>content >> > > > works and metadata. So there are things in our taxonomy that are part >>of >> > > > end-to-end DRM systems like watermarks, TPM, and rights languages that >>are >> > > > not necessarily things that will be a focus of IDRM. >> > > > >> > > > At our last meeting, Thomas and I proposed that there are two >>distinct >> > > > sets of relationships in end-to-end DRM. First, is between content >> > > > provider and distributor (aka "service provider"). We would use >>"service >> > > > provider" if the content were to be delivered to consumers over a IP >> > > > network but the distributor could be a company that manufactures DVDs >>or a >> > > > TV broadcaster that receives files from a TV or film studio. Trusted >> > > > repositories for the files and rights metadata, authorization, and >> > > > authentication are IP infrastructure components that the content >>provider >> > > > may need to properly manage this process. It is unlikely that >>technical >> > > > protection mechanisms or digital licenses are needed in this >> > > > business-to-business transaction. >> > > > >> > > > The second set of relationships is between the service provider and >>the >> > > > content consumer. On the Internet today, it is hard if not impossible >>to >> > > > unambiguously identify illegal sources and uses of copyright content >>works >> > > > from illegal uses. Trusted repositories and sources with rights >>metadata >> > > > are important to DRM in this relationship. Authorization, >>authentication, >> > > > and technical protection mechanisms may be needed so standard ways to >>do >> > > > key and license management will promote inter-operability. What we >> > >should >> > > > not overlook in digital rights-conferral and mechanisms that support >>it is >> > > > the flow of information assets from the consumer to the provider for >>the >> > > > purposes of authorization. In this regard, "rights management" should >> > > > include the rights that consumers have with respect to information >>that >> > > > they provide and DRM is about information assets and not only >>copyright >> > >works. >> > > > >> > > > We want to begin developing our taxonomy and putting flesh to an IDRM >> > > > model. This note outlines the general approach that we are taking and >> > > > we're soliciting any comments that people might have. Also, if others >>are >> > > > interested in working on a draft document for the taxonomy, please let >>us >> > >know. >> > > > >> > > > Mark >> > > > >> > From thardjono@mediaone.net Wed May 23 19:33:14 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:33:14 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- asymmetry vs. symmetry... Message-ID: <5.0.0.25.2.20010523143311.02979d30@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 02:45:12 -0400 >From: "Sam X. Sun (@S2000)" >Subject: Re: [IDRM] DRM Taxonomy work -- asymmetry vs. symmetry... >To: Mark Baugher , ietf-idrm@lists.elistx.com >X-Mailer: Microsoft Outlook Express 5.50.4133.2400 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >Mark, >I'm struggling with the notion of asymmetry vs. symmetry, regarding to the >different kinds of roles "content holder" plays. I tends to think "someone >who grant rights" is also "someone holds the rights", except that the rights >are different from each other. I wonder if the difference stems from how to >think of digital rights: as a function of content and content holder >combined, or a function of content (or a function of content holder) along. >Also, I wonder if the asymmetry can be realized by either the metadata >associated to the content INSTANCE, and/or the attributes associated to the >content holder? > >Sam > > >----- Original Message ----- >From: "Mark Baugher" >To: "Sam X. Sun (@S2000)" >Cc: >Sent: Monday, May 21, 2001 1:00 PM >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... > > > > Sam > > I have two thoughts here. First is that the Handle System makes > > it possible to associate metadata with a handle (a directory entry), > > and that metadata can include a rights specification like DPRL or > > ODRL, which captures the rights relationships you mention in the > > first paragraph of your note. I know you know this; I think DOI does > > this. I expect that I'm missing something. > > > > Second, there should probably be an asymmetry between those > > who hold rights and those to whom the rights holder grants rights. > > Leaving aside copyright law, which varies between countries and > > over time, I might consider personal information that I give to a > > provider as information that I always have some special rights to > > though I may hand it over to a site that, for the sake of argument, > > agrees not to share that information with anyone else. I think that > > there is often some entity in the chain that has special claims > > (such as legally owning the content) that is distinct from the > > current "content holder." > > > > Mark > > At 10:47 AM 5/19/2001 -0400, Sam X. Sun (@S2000) wrote: > > >Hi, > > > > > >I think it's a good application model to classify in end-to-end DRM > > >relationships in terms of content provider and distributor, and >distributor > > >and content consumer. They represent some real world scenarios that DRM >will > > >have to address. On the other hand, I wonder if we could further model >the > > >underlying DRM framework in terms of transactions of certain entities >(e.g. > > >digital content) among other kinds of entities (e.g. content holder), and > > >the transaction may be reflected in terms of exchange/update of digital > > >rights bound to each content instance acquired by the content holder. > > > > > >In other words, I wonder whether it's reasonable to categorize the >entities > > >that DRM framework has to deal with in terms of: > > > > > > 1. the digital content (per instance) > > > 2. the content holder (current or potential) > > > > > > > > >And think of the digital rights as state information of the digital >content > > >hold by content holder. From this, one may imagine building mechanisms > > >within the framework to: > > > > > > * Associate rights per digital content acquired by the content >holder > > > * Identify content holder, along with its authentication attributes. > > > * Exchange/update digital rights per digital content among content > > >holders > > > * Facilitate/monitor/trace legitimate digital contents for their >proper > > >use > > > * Report illegal content upon showing up within the framework >(doable?) > > > etc... > > > > > >Assumptions here are that everyone can obtain a copy of digital content > > >freely, but need to acquire (e.g. via purchase) adequate rights to be >able > > >to "use" it. Depending on the rights associated to the digital content > > >acquired by the content holder, the content holder could act as a >publisher, > > >a distributor, a retailer, or end consumer. A transaction of digital >content > > >from a retailer to consumer could be modeled as retailer (with the right) >to > > >generate a new instance of the digital content, assign it with consumer > > >rights, and "give" it to the consumer (along with the consumer rights). A > > >consumer may later become a retailer after obtaining the "retail" rights >for > > >its copy of digital content... > > > > > >It's a bit off tracking to Mark's message:)... Just want to share some > > >thoughts. Any comments? > > > > > > > > >Cheers, > > >Sam > > > > > > > > > > > > > > >----- Original Message ----- > > >From: "Mark Baugher" > > >To: > > >Sent: Thursday, May 17, 2001 6:33 PM > > >Subject: [IDRM] DRM Taxonomy work > > > > > > > > > > Hi > > > > We wanted to begin work on developing a draft on requirements for > > > > IDRM. Sam Sun, Thomas Hardjono and I discussed this and we think that >a > > > > good first step would be to develop a taxonomy, which is a >classification > > > > of the parts of an end-to-end DRM system from which we can develop a > > >common > > > > model, or models, and common definitions - so we speak the same >language > > >to > > > > one another. > > > > > > > > Our focus in IDRM is with the IP network infrastructure aspects of > > > > DRM. To me, this means that we are less concerned with the syntax or > > > > semantics of rights specifications than in the handling and use of >rights > > > > metadata in end-to-end systems; we are less concerned with the >specifics > > >of > > > > watermarking technology or with technical protection mechanisms than >in > > >key > > > > and license distribution systems; persistent and globally-unique names >may > > > > not be as much of a concern to IDRM as are trusted repositories of >content > > > > works and metadata. So there are things in our taxonomy that are part >of > > > > end-to-end DRM systems like watermarks, TPM, and rights languages that >are > > > > not necessarily things that will be a focus of IDRM. > > > > > > > > At our last meeting, Thomas and I proposed that there are two >distinct > > > > sets of relationships in end-to-end DRM. First, is between content > > > > provider and distributor (aka "service provider"). We would use >"service > > > > provider" if the content were to be delivered to consumers over a IP > > > > network but the distributor could be a company that manufactures DVDs >or a > > > > TV broadcaster that receives files from a TV or film studio. Trusted > > > > repositories for the files and rights metadata, authorization, and > > > > authentication are IP infrastructure components that the content >provider > > > > may need to properly manage this process. It is unlikely that >technical > > > > protection mechanisms or digital licenses are needed in this > > > > business-to-business transaction. > > > > > > > > The second set of relationships is between the service provider and >the > > > > content consumer. On the Internet today, it is hard if not impossible >to > > > > unambiguously identify illegal sources and uses of copyright content >works > > > > from illegal uses. Trusted repositories and sources with rights >metadata > > > > are important to DRM in this relationship. Authorization, >authentication, > > > > and technical protection mechanisms may be needed so standard ways to >do > > > > key and license management will promote inter-operability. What we > > >should > > > > not overlook in digital rights-conferral and mechanisms that support >it is > > > > the flow of information assets from the consumer to the provider for >the > > > > purposes of authorization. In this regard, "rights management" should > > > > include the rights that consumers have with respect to information >that > > > > they provide and DRM is about information assets and not only >copyright > > >works. > > > > > > > > We want to begin developing our taxonomy and putting flesh to an IDRM > > > > model. This note outlines the general approach that we are taking and > > > > we're soliciting any comments that people might have. Also, if others >are > > > > interested in working on a draft document for the taxonomy, please let >us > > >know. > > > > > > > > Mark > > > > > > From thardjono@mediaone.net Wed May 23 19:33:24 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:33:24 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- digital rights... Message-ID: <5.0.0.25.2.20010523143322.0297ec70@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 17:07:44 +1000 >From: Renato Iannella >Subject: Re: [IDRM] DRM Taxonomy work -- digital rights... >To: ietf-idrm@lists.elistx.com >X-Mailer: Mulberry/2.0.7 (MacOS) >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > > >--On 23/5/01 1:38 AM -0400 Sam X. Sun (@S2000) wrote: > >>First of all, I'd like to understand better regarding the definition of >>digital rights. I was under the impression that digital rights always >>apply to the combination of "content" and "content holder", instead of >>just "content" itself, for expressing "the permission for the 'content >>holder' to operate on the 'content'". Now the question is: can we define >>"digital rights" without specifying the "content holder", where the >>"content holder" can be anyone ranging from consumer, distributor, or >>publisher? On the flip side, can we specify "digital rights" with >>"content holder" alone, without referencing the digital content? These >>might be trivial questions, but I wish to get them clarified nevertheless. > >Sam, the best place that describes these core principles is the > Framework [1]. > >In summary, the core entities are Parties, Rights, and Content. >You need all three to make Rights Assertions. > > >Cheers...Renato >Chief Scientist, IPR Systems Pty Ltd > >[1] http://www.indecs.org/pdf/framework.pdf From thardjono@mediaone.net Wed May 23 19:33:45 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:33:45 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <5.0.0.25.2.20010523143342.02978dc0@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 10:10:44 -0400 >From: Michael Mealling >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >To: "Sam X. Sun (@S2000)" >Cc: Mark Baugher , ietf-idrm@lists.elistx.com >Reply-to: Michael Mealling >User-Agent: Mutt/1.1.2i >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >Hi Sam! > >On Wed, May 23, 2001 at 02:03:48AM -0400, Sam X. Sun (@S2000) wrote: > > Regarding the handle system, I think there are two sides of DRM that could > > take advantage of it. First is the metadata and content attribute > > association, as you mentioned in the DOI application. > > From what I remember this part of the handle service seemed easily >seperable from the resolution part of the system. The query methods >for the attribute value pairs were straight forward and secure but really >weren't tied to how resolution happened, right? > > > The other is the > > identity reference for "content holder" (e.g. consumer identity). > >I.e. you assign some identifier to the entities involved in the transaction? > > > What makes handle system unique in this case is that it provides a secured > > name resolution service (for name attribute binding), > >I wouldn't say that the handle system is unique in that regard. The entire >URI Resoluion process was built to be as secured as you wanted it to be. >Heck, since Bill built the handle resolution system to mirror the URN >resolution mechanism they're pretty much identical. > > > , and allows ownership to be > > defined per name (vs. URL, where the name administration belongs to the > site > > manager). This is particularly important for individuals to be able to > > manage their identity attributes, including their public keys. > >Can you explain that one further? Are you suggesting that URIs that >have domain-names somehow confer ownership semantics? We should be >very clear here since whether or not a URI is a name has everything to do >with how you actually use it and nothing to do with what it actually looks >like... > > > The point I was trying to make in my earlier message is that we probably > > need to pay equal attention for identity or trust management as we do for > > content management. And I want to understand better the nature of the > > identity used in DRM application before we move further into the framework. > >Same here. As yet I can't see a reason that URIs are no sufficient. You >have a requirement to identifiy all parties in the transaction but >that just means you assign a URI to the parties involved as well... > >-MM > >-- >-------------------------------------------------------------------------------- >Michael Mealling | Vote Libertarian! | urn:pin:1 >michael@neonym.net | | http://www.neonym.net > | | go:Michael Mealling From thardjono@mediaone.net Wed May 23 19:33:53 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:33:53 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- "content holder" vs. "content owner" Message-ID: <5.0.0.25.2.20010523143350.0297d470@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 11:16:09 -0400 >From: Thomas Hardjono >Subject: Re: [IDRM] DRM Taxonomy work -- "content holder" vs. "content owner" >X-Sender: thardjono@pop.ne.mediaone.net >To: "Sam X. Sun (@S2000)" , ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >OK, I'm still rather confused about the Content-Holder, but let me try a >very simple example: > > - Madonna issues a new song downloadable as MP3 through some > Content-Distributor. > > Here Madonna (or he record company/publisher) is the Content-Owner. > > - I download the song and pay $2 (reasonable I think :) > > Here I am the Content-Holder (where the Content is that MP3 file). > I only own my copy (1 copy) of that Content. I do not have further > rights. > >In this scenario, if I gave a copy of Madonna's MP3 song to my neighbor, >then clearly my neighbour has to (again) pay the Content-Owner (ie. Madonna >or her record company/publisher). > >Neither I nor my neighbour own the *rights* to that Content/MP3. > >Thus, I think the term Content-Holder means a holder of an instance >of a digital Content, where that holder is *not* the legal >owner of the copyright of the Content. > >Hmmmm, am I on track here? Isn't the Content-Holder = Consumer ? > >cheers, > >thomas >------ > >At 5/23/01||01:40 AM, Sam X. Sun (@S2000) wrote: >>My second question is regarding the content holder vs. content owner. >> >>When I say "content holder", I'm using it as a general term of "owner of an >>instance of digital content", or "a kind of digital content sharing some >>common attribute". The "content holder" can be "consumer", "distributor", >>"retailer", "publisher", and "content creator", depending on the "digital >>rights" he has and/or acquired for his copy of digital content. I tends of >>think of "consumer" as a relative term, depending on the view point. For >>example, "retailer" and "distributor" may all be treated as "consumer" (with >>special "distribution" rights) from a "publisher", and the "publisher" can >>generate money, directly or indirectly, from any kind of "consumer" of its >>content. >> >>I was trying to avoid using "content owner" but "content holder", fearing >>that the "content holder" is not necessarily the "owner of the content". >>Should we first try to clarify these terminologies? I guess this is one of >>the reasons Mark started this thread. >> >> >>Sam >> >>----- Original Message ----- >>From: "Thomas Hardjono" >>To: >>Sent: Saturday, May 19, 2001 3:17 PM >>Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >> >> >> > >> > Hi Sam, >> > >> > I don't think you are off-track. You have brought up some good issues >>which >> > I'll comment below (I'll send comments about Mark's posting separately). >> > >> > >> > At 5/19/01||10:47 AM, Sam X. Sun (@S2000) wrote: >> > >Hi, >> > > >> > >I think it's a good application model to classify in end-to-end DRM >> > >relationships in terms of content provider and distributor, and >>distributor >> > >and content consumer. They represent some real world scenarios that DRM >>will >> > >have to address. On the other hand, I wonder if we could further model >>the >> > >underlying DRM framework in terms of transactions of certain entities >>(e.g. >> > >digital content) among other kinds of entities (e.g. content holder), and >> > >the transaction may be reflected in terms of exchange/update of digital >> > >rights bound to each content instance acquired by the content holder. >> > > >> > >In other words, I wonder whether it's reasonable to categorize the >>entities >> > >that DRM framework has to deal with in terms of: >> > > >> > > 1. the digital content (per instance) >> > > 2. the content holder (current or potential) >> > > >> > > >> > >And think of the digital rights as state information of the digital >>content >> > >hold by content holder. From this, one may imagine building mechanisms >> > >within the framework to: >> > > >> > > * Associate rights per digital content acquired by the content >>holder >> > > * Identify content holder, along with its authentication attributes. >> > > * Exchange/update digital rights per digital content among content >> > >holders >> > > * Facilitate/monitor/trace legitimate digital contents for their >>proper >> > >use >> > > * Report illegal content upon showing up within the framework >>(doable?) >> > > etc... >> > >> > I'm unclear about the term "content holder" above. I assume you mean >> > the Consumer that actually uses (reads/views/plays) the Content, >> > since Content not in the Consumer's hands will not generate money. >> > >> > As I understand it, the Digital-Rights (or Rights-Metadata) can be >> > Content-specific only or can be tied to both the Content and the Consumer. >> > >> > The distinction becomes relevant when we talk about the Business Models. >> > Thus, say in one business model, the Content-Creator/Owner may >> > specify usage rights in the Rights-Metadata (without mentioning specific >> > Customers). Assuming the Content-Creator/Owner has a business >>relationship >> > with a Distributor, then perhaps it is up to the Distributor(s) to >> > create further Rights-Metadata that is Customer-specific (eg. for Customer >> > who are members of the video-club, say). >> > >> > WRT your second bullet above, when the Distributor starts dealing >> > with Consumers (i.e content holder) does the Consumer's authentication >> > attributes becomes extremely relevant. It here that I think individual >> > certificates will become a key issue. A Customer's certificate will >>become >> > more important and persistent comapred to his/her credit card number. >> > And accounting and tracking may also perhaps be based on certificates. >> > >> > In terms of the transferability of Contents, most systems I have seen >> > or read about deploy some kind of verification/checking each time >> > the Content's ownership is transffered. Thus, in basic terms, if I sell >> > my (encrypted) MP3 file on eBay, then the purchaser will have to register >> > with the Distributor (or the entity claiming to be the contact-point for >>that >> > Content) and obtain a copy of the key (or a derived version). >> > >> > This model does not really fit into the "pure" P2P distribution scheme, >> > but it ensures continuous revenue for the distributor (who gets >> > additional new customer info). This model also allos tracking of >> > moved/sold Contents on the net. >> > >> > >> > >> > >Assumptions here are that everyone can obtain a copy of digital content >> > >freely, but need to acquire (e.g. via purchase) adequate rights to be >>able >> > >to "use" it. Depending on the rights associated to the digital content >> > >acquired by the content holder, the content holder could act as a >>publisher, >> > >a distributor, a retailer, or end consumer. >> > >> > This idea is cool and reflects more of the pure P2P approach. I don't >> > know if the big players will like the notion of a Consumer (content >>holder) >> > taking the role of publisher/distributor/retailer. >> > >> > I think the term P2P itself has been overused and means different things >> > to different people. I used it to mean the non-hierarchical/flat >> > distributed system that runs democratically from one user's machine >> > to another. >> > >> > Other people seem to mean P2P as "group-sharing of files" regardless >> > of how the files are managed (ie. the files could be sitting on >> > a single machine/server with everyone connecting to that server). >> > This later view is similar to the mainframe usage model of the 70s. >> > >> > >> > >> > >A transaction of digital content >> > >from a retailer to consumer could be modeled as retailer (with the right) >>to >> > >generate a new instance of the digital content, assign it with consumer >> > >rights, and "give" it to the consumer (along with the consumer rights). >> > >> > OK, so here is an interesting question: can BlockBuster Video make >> > copies of videos (ie. a new instant of content) in their backroom >> > and lease them? (and I don't mean replacements for broken/stolen >> > videocassettes). >> > >> > >> > >> > >A consumer may later become a retailer after obtaining the "retail" >>rights >> > >for its copy of digital content... >> > >> > Hmmm... >> > >> > cheers, >> > >> > thomas >> > ------ >> > From thardjono@mediaone.net Wed May 23 19:34:04 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:34:04 -0400 Subject: [IETF-IDRM] Fwd: [IDRM] Fwd: Follow up on: XACML - Extensible Access Control Markup Language Message-ID: <5.0.0.25.2.20010523143401.02972d90@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 11:41:27 -0400 >From: Thomas Hardjono >Subject: [IDRM] Fwd: Follow up on: XACML - Extensible Access Control Markup > Language >X-Sender: thardjono@pop.ne.mediaone.net >To: ietf-idrm@lists.elistx.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > > >>Resent-Cc: recipient list not shown: ; >>MBOX-Line: From www-drm-request@w3.org Wed May 23 12:52:44 2001 >>X-Yahoo-Forwarded: from thardjono@yahoo.com to thardjono@mediaone.net >>X-Track: 1: 40 >>Resent-Date: Wed, 23 May 2001 08:43:38 -0400 (EDT) >>Date: Wed, 23 May 2001 13:39:39 +0100 >>From: David Parrott >>To: "MPEG-21 List \(E-mail\)" , www-drm@w3.org >>Cc: "'xacml@lists.oasis-open.org'" >>X-Lotus-FromDomain: REUTERS >>Subject: Follow up on: XACML - Extensible Access Control Markup Language >>Resent-From: www-drm@w3.org >>X-Mailing-List: archive/latest/95 >>X-Loop: www-drm@w3.org >>Sender: www-drm-request@w3.org >>Resent-Sender: www-drm-request@w3.org >>List-Id: >>List-Help: >>List-Unsubscribe: >> >> >> >>To: members of MPEG-21 and W3C-DRM mailing lists >>Cc: members of XACML mailing list (FYI) >> >>[This is a deliberate cross-posting on multiple lists, for the purpose >>of cross-fertilisation. Apologies if you receive multiple copies.] >> >>As previously promised to the members of the MPEG-21 and W3C-DRM >>mailing lists, this is an update on the activities of the OASIS/XACML >>(eXtensible Access Control Markup Language) Technical Committee >>following its first meeting (teleconf) on Monday 21 May 2001. >> >>The group charter (available at http://www.xacml.org/) includes >>the definition of "a core schema and corresponding namespace for the >>expression of authorization policies in XML against objects that are >>themselves identified in XML." (Note that the latter clause does not >>restrict policies to XML objects, just those objects to which a >>reference can be written in XML syntax.) The charter further states >>that "Issues to be addressed include, but are not limited to: fine >>grained control, the nature of the requestor, the protocol over which >>the request is made, content introspection, the types of activities >>authorized." >> >>There is a clear synergy between the aims of XACML and other work >>taking place in MPEG and other standards groups. To date the TC has >>identified a small number of potential contributing standards but the >>Web site makes no mention of MPEG-21, IETF, Open eBook Forum, or >>W3C(DRM) activities. At the kickoff meeting, the TC agreed to create >>a sub-committee with responsibility for liaison with other standards >>efforts. The sub-committee will help to scope the XACML work and >>determine whether it should contribute into any other standards >>activities, and if it could benefit from adopting the work of the >>other activities where appropriate. This is very positive. >> >>There is presently representation the XACML TC from the IETF. Thomas >>Hardjono of Nortel Networks is Chair of >>Internet Digital Rights Management Research Group of the IETF (see >>http://www.idrm.org/). Also, I (david.parrott@reuters.com) and a number >>of others are bridging several standards groups in the DRM space. It is >>clearly useful to coordinate activities as far as possible. >> >>The XACML TC has an aggressive schedule (from the XACML home-page): >> >>'The plan is to produce a "substantially complete" draft specification >> by 21 Dec 2001, with a final version ready to undergo the OASIS member >> approval process by 22 March 2002. The final version will be >> accompanied by reference implementations. Below are interim >> deliverable dates: >> >> statement of scope 29 June 2001 >> glossary 29 June 2001 >> bibliography 29 June 2001 >> use cases 24 Aug 2001 >> detailed requirements 21 Sep 2001 >> draft standard 01 Dec 2001 >> model examples for "native" and non-native XML targets of control 21 >> Dec 2001 >> reference implementations 22 March 2002' >> >>Of particular interest is the result of the initial scoping exercise >>to be undertaken via the XACML mailing list and due for completion at >>the end of next month. I envisage that the Standards Interoperability >>and Liaison sub-committee will have significant input during the >>scoping phase. >> >>The Chair of the XACML TC is Simon Blackwell >> who should be contacted regarding >>participation. NB: OASIS restricts participation in TCs to the OASIS >>membership. The archives of the XACML mailing list are publically >>available at: http://lists.oasis-open.org/archives/xacml/ >> >> >>Background on OASIS (from http://www.oasis-open.org/): >> >>OASIS, the Organization for the Advancement of Structured Information >>Standards, is a non-profit, international consortium that creates >>interoperable industry specifications based on public standards such >>as XML and SGML. OASIS members include organizations and individuals >>who provide, use and specialize in implementing the technologies that >>make these standards work in practice. >> >> >>Best Regards, >>/Dave. >> >>_ ______________________________________________________________ >>Dr David J. Parrott, Chartered Engineer. Chief Technology Office >> Reuters Limited, 85 Fleet Street, London EC4P 4AJ, UK. >> Direct Line: +44 (0)20 7542 9830, Fax: +44 (0)20 7542 8314 >> Email: David.Parrott@reuters.com, dparrott@acm.org >> >> >> >>----------------------------------------------------------------- >> Visit our Internet site at http://www.reuters.com >> >>Any views expressed in this message are those of the individual >>sender, except where the sender specifically states them to be >>the views of Reuters Ltd. From thardjono@mediaone.net Wed May 23 19:34:13 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:34:13 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... -- handle system Message-ID: <5.0.0.25.2.20010523143410.02971e30@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 13:50:34 -0400 >From: Michael Mealling >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... -- handle system >To: "Sam X. Sun (@S2000)" >Cc: Michael Mealling , ietf-idrm@lists.elistx.com >Reply-to: Michael Mealling >User-Agent: Mutt/1.1.2i >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >On Wed, May 23, 2001 at 01:10:19PM -0400, Sam X. Sun (@S2000) wrote: > > I agree with you that DRM doesn't have to stick with any specific > technology > > for its process. All we wanted here is to understand the process, and > > identify technologies that can be applied to it... > >Great! There's alot of stuff like this being handled in the RDF/Semantic Web >areas in the W3C so that's one place we really should be watching since >it'd be a shame for the IETF and the W3C to diverge here.... > > > In terms of Handle System and URN, I would say that they are quite > different > > now in terms of how they work and the issues that they want to address. > >Sure. From what Larry was talking about, the system is much more concerned >about the rights metadata than the identifier resolution process... > > > Handle system started about the same time PURL and URN started, trying to > > address persistence issue of URL namespace. But later we found that > > persistence is more of a social and/or management issue than a mere > > technical one. > >Agreed. But that doesn't negate the fact that if you know the identifier >is supposed to be persistent you can make a lot of safe assumptions... > > > While Handle System does provide a technical approach to > > encourage more persistent namespace management, we have put more focus on > > service security, > >Which is one thing this group will really need... > > > distributed name administration, > >What's being adminstered? Is that for provisioning of the identifier or >managing >the metadata associated with the object being identified? The first is >interesting (and actually what the PROVREG group is doing.) The second >is a metadata service feature.... > > > internationalization > > (i18n), and service scalability. It might be helpful if you can read the > > latest HS drafts to understand the difference... > >I'll go check 'em out. Has it changed that radically? > > > On the other hand, I see no > > reason why Handle System cannot work with URN. One way to do it is to > > register HS namespace as a namespace under URN, as we discussed earlier > last > > year. > >That should be fairly painless. I'll send you the template.... > > > The issues that we need to address are how to make sure that the NAPTR > > approach won't become a bottleneck, > >It really can't. You only do one lookp and the record has a time to live of >several _years_. From my analysis you end up doing the _exact_ same number of >lookups for NAPTR records in the degenerative case (which handles would be) >as you do for A records.... > > > and how to achieve service security over such approach. > >The same way you are now. URI resolution just gets you to the authoritative >server for that identifier. How secure it is after that point is up to you and >the types of protocols/services you require to do the task. > > > Maybe we should discuss these in a separate thread, or bring > > them to the URN working group... > >I think that would be best. We don't want to bug these guys with identifier >stuff to much. ;-) > > > Regarding URI and HS, I'm not sure if they are comparable. I tend to think > > that URI is a collection of name services, and Handle System is just a > > specific one, under a specific protocol. > >Semi-right. A URI is an identifier, nothing else. Some identifiers have >_default_ methods for resolving into a representation of the abstract >object they identifier but there is no requirement that it be the only method. > > > While some members of URI can be as > > secure as you want, others can be totally insecure. I wonder if it's > > appropriate to say a URI in general is secure, or carries any semantic > > meaning (a name, an address, an identifier, etc)? > >Correct. URIs themselves say nothing about security since they're just >identifiers. Its how you use them that ends up being secure or not secure. >I.e. if I use an http URI in some service where every single entity is >signed and encrypted then I'm using that URI securely. The URI itself >doesn't create or require security.... > > > In fact, because DNS is > > not secure as we know of today, that makes any name service based on DNS > > questionable in their security. > >Not true. While some aspects of DNSSEC are still being worked on. It is >very possible to have trusted DNS in normal operation. > > > The Handle System is designed to be > > independent of DNS, and to address the security and i18n issues that DNS is > > struggling to overcome. > >And the URI resolution mechanism I mentioned solve those problems as well. >(Besides, i18n issues aren't really identifier related issues anyway.) > > > It has the advantage that it's starting from > > scratch, and doesn't have to deal with the backward compatibility issues > > that DNS has to take care of... On the other hand, we are in the process of > > defining handle system URI syntax for handles to be used in web context. In > > that sense, Handle system defines a namespace under URI, and we are in > > agreement there. > >Not really. My suggestion is that any DRM shouldn't need to make requirements >about the identifier itself. Any URI should be able to be used to find out >about and get rights enabled access to any object. Digital Rights >Management has about zero to do with the identifier used to talk about >the object.... > > > In fact, I'm more inclined to think that Handle System is in par with DNS. > >I'm more inclined to think of the RESCAP Working Group actually. > > > In fact, if DNS can address security, i18n, access control on name > > attributes, and to allow individuals to manage the names they > registered, we > > probably won't need the Handle System. > >With the exception of that last item, this is _exactly_ what RESCAP was >chartered to do. That last item, in my opinion, is not a requirement of >digital rights management. Why do I have to use an identifier that is >registered with some third party? Most folks would like to be able to >manage the digital rights of http://www.joe-blow.com/music/my-music.midi >without having to create yet another identifier for it.... > > > On the other hand, people from DNS > > working group has refused to apply DNS as a general name service other than > > network-address translation, which makes us think that an independent name > > service would be helpful... > >Sure. Everyone should consider the DNS to be at the end of its usefullness. >It was never intended to be any of the things you listed there. >Where did the DNS come into this anyway? I don't think anyone has made >the suggestion that currently deployed DNS infrastructure can handle >any of this. This is why the URN working group did what it did. This >is why the IESG is creating uri.arpa as an infrastructure level Internet >technology for reliable, secure URI services such as caching/replication, >metadata, access control, policy, etc... > >There has been _considerable_ work done in the IETF in this particular area. >I'm just suggesting that this group use that work and not chuck all of it >in favor of one very verticle solution. Make the system modular and make >it use the identifier infrastructure that the IETF and the W3C are >standardizing on... > >-MM > >-- >-------------------------------------------------------------------------------- >Michael Mealling | Vote Libertarian! | urn:pin:1 >michael@neonym.net | | http://www.neonym.net > | | go:Michael Mealling From thardjono@mediaone.net Wed May 23 19:34:23 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:34:23 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework... -- handle system Message-ID: <5.0.0.25.2.20010523143420.02973a50@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 13:10:19 -0400 >From: "Sam X. Sun (@S2000)" >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... -- handle system >To: Michael Mealling >Cc: ietf-idrm@lists.elistx.com, Sam Sun >X-Mailer: Microsoft Outlook Express 5.50.4133.2400 >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >Hi Michael, > >I agree with you that DRM doesn't have to stick with any specific technology >for its process. All we wanted here is to understand the process, and >identify technologies that can be applied to it... > >In terms of Handle System and URN, I would say that they are quite different >now in terms of how they work and the issues that they want to address. >Handle system started about the same time PURL and URN started, trying to >address persistence issue of URL namespace. But later we found that >persistence is more of a social and/or management issue than a mere >technical one. While Handle System does provide a technical approach to >encourage more persistent namespace management, we have put more focus on >service security, distributed name administration, internationalization >(i18n), and service scalability. It might be helpful if you can read the >latest HS drafts to understand the difference... On the other hand, I see no >reason why Handle System cannot work with URN. One way to do it is to >register HS namespace as a namespace under URN, as we discussed earlier last >year. The issues that we need to address are how to make sure that the NAPTR >approach won't become a bottleneck, and how to achieve service security over >such approach. Maybe we should discuss these in a separate thread, or bring >them to the URN working group... > >Regarding URI and HS, I'm not sure if they are comparable. I tend to think >that URI is a collection of name services, and Handle System is just a >specific one, under a specific protocol. While some members of URI can be as >secure as you want, others can be totally insecure. I wonder if it's >appropriate to say a URI in general is secure, or carries any semantic >meaning (a name, an address, an identifier, etc)? In fact, because DNS is >not secure as we know of today, that makes any name service based on DNS >questionable in their security. The Handle System is designed to be >independent of DNS, and to address the security and i18n issues that DNS is >struggling to overcome. It has the advantage that it's starting from >scratch, and doesn't have to deal with the backward compatibility issues >that DNS has to take care of... On the other hand, we are in the process of >defining handle system URI syntax for handles to be used in web context. In >that sense, Handle system defines a namespace under URI, and we are in >agreement there. > >In fact, I'm more inclined to think that Handle System is in par with DNS. >In fact, if DNS can address security, i18n, access control on name >attributes, and to allow individuals to manage the names they registered, we >probably won't need the Handle System. On the other hand, people from DNS >working group has refused to apply DNS as a general name service other than >network-address translation, which makes us think that an independent name >service would be helpful... > > >Cheers, >Sam > >----- Original Message ----- >From: "Michael Mealling" >To: "Sam X. Sun (@S2000)" >Cc: "Mark Baugher" ; >Sent: Wednesday, May 23, 2001 10:10 AM >Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... > > > > Hi Sam! > > > > On Wed, May 23, 2001 at 02:03:48AM -0400, Sam X. Sun (@S2000) wrote: > > > Regarding the handle system, I think there are two sides of DRM that >could > > > take advantage of it. First is the metadata and content attribute > > > association, as you mentioned in the DOI application. > > > > >From what I remember this part of the handle service seemed easily > > seperable from the resolution part of the system. The query methods > > for the attribute value pairs were straight forward and secure but really > > weren't tied to how resolution happened, right? > > > > > The other is the > > > identity reference for "content holder" (e.g. consumer identity). > > > > I.e. you assign some identifier to the entities involved in the >transaction? > > > > > What makes handle system unique in this case is that it provides a >secured > > > name resolution service (for name attribute binding), > > > > I wouldn't say that the handle system is unique in that regard. The entire > > URI Resoluion process was built to be as secured as you wanted it to be. > > Heck, since Bill built the handle resolution system to mirror the URN > > resolution mechanism they're pretty much identical. > > > > > , and allows ownership to be > > > defined per name (vs. URL, where the name administration belongs to the >site > > > manager). This is particularly important for individuals to be able to > > > manage their identity attributes, including their public keys. > > > > Can you explain that one further? Are you suggesting that URIs that > > have domain-names somehow confer ownership semantics? We should be > > very clear here since whether or not a URI is a name has everything to do > > with how you actually use it and nothing to do with what it actually looks > > like... > > > > > The point I was trying to make in my earlier message is that we probably > > > need to pay equal attention for identity or trust management as we do >for > > > content management. And I want to understand better the nature of the > > > identity used in DRM application before we move further into the >framework. > > > > Same here. As yet I can't see a reason that URIs are no sufficient. You > > have a requirement to identifiy all parties in the transaction but > > that just means you assign a URI to the parties involved as well... > > > > -MM > > > > -- > > -------------------------------------------------------------------------- >------ > > Michael Mealling | Vote Libertarian! | urn:pin:1 > > michael@neonym.net | | >http://www.neonym.net > > | | go:Michael >Mealling From thardjono@mediaone.net Wed May 23 19:33:34 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Wed, 23 May 2001 14:33:34 -0400 Subject: [IETF-IDRM] Fwd: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt Message-ID: <5.0.0.25.2.20010523143331.0297d970@pop.ne.mediaone.net> >Date: Wed, 23 May 2001 10:00:13 -0400 >From: Michael Mealling >Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt >To: Mark Baugher >Cc: Michael Mealling , ietf-idrm@lists.elistx.com, > ssun@cnri.reston.va.us, llannom@cnri.reston.va.us >Reply-to: Michael Mealling >User-Agent: Mutt/1.1.2i >List-Owner: >List-Post: >List-Subscribe: >List-Unsubscribe: >List-Archive: >List-Help: , > > >On Tue, May 22, 2001 at 11:21:48PM -0700, Mark Baugher wrote: > > At 01:31 AM 5/23/2001 -0400, Michael Mealling wrote: > > >On Tue, May 22, 2001 at 10:26:05PM -0700, Mark Baugher wrote: > > > > My first comment is that there does not seem to be name-resolution > > > draft in > > > > the mix. Is this not to be published? I can see a lot of uses for a > > > > namespace that is not global, such as between a content provider > > > > (publisher) and service provider (distributor) that want to use the > > > > metadata facilities of handles to store rights information with the > > > content > > > > work and to identify one or more "official repositories" for the > content > > > > work. If you're requiring a global namespace but not publishing the > > > > resolution mechanisms, then this seems to be an impediment to many > > > > business-to-business uses. > > > > > >If you need name resolution then you should take a look at the > > >URI Resolution documents: > > >http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-03.txt > > >http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-04 > .txt > > >http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-04.txt > > > > As 5.3 of the draft concludes, the success of either urn or the Handle > > System do not depend on each other. I did not glean from the Handle > > System Overview I-D the idea that the Handle System would use > > URN resolvers. > >Right. I'm suggesting that instead of sticking to one URI scheme (handles) >that DRM should work for all URIs. And in the case where DRM needs >persistence it should only go as far as requiring URNs. > > > I guess we should ask Sam and Larry about that. > >I was at a meeting with them last year about this very subject and at least >the intent at that time was to register handles as a URN namespace. I haven't >heard whether that intent has changed but I also haven't seen the NID >registration document go by... > > > >Is there any reason why a DRM system needs a special namespace? I've > > >heard a persistence requirement from some and in that case you could > easily > > >use URNs. But in the general case, shouldn't a URI be sufficient for > > >identifying the resource that is having its rights digitally managed? > > > > I really don't know if persistent naming is a requirement for DRM on the > > Internet. > >I haven't seen a compelling need for it either... > > > One issue that people have is that it is difficult or not impossible to > > identify content works and uses of content works that are legitimate > > from those that are not. > >And the desire is to be able to tell that from the identifier? That's really >dangerous ground becuase items and their identifiers change. Building human >semantic hints into the identifier for an object makes that identifier >much more fragile. That is the number one reason why there is that silly '//' >in all http URIs. > > > One idea we have been discussing in the group is the need for an > > infrastructure that identifies legitimate repositories and legitimate > > uses of content works - or of any information assets to include > > the case of personal information that is used for the purposes of > > authentication. > >Sure. That's one of the intended functions of the URI Resolution process: >take an identifier and tell me who is authoritative for it and allow me >to ask them various questions via various protocols in order to do various >things... > > > The Handle System is one system that addresses > > these requirements for content-work publishing, in my opinion. You > > don't get this with URIs today. > >By themselves? No. That's not what they're intended to do. URIs just >identify. Its the systems that provide access to that object and emerging >metadata systems (like RESCAP and RDF) that tell you things about the >object prior to accessing it. > > > Will publishers, record labels, movie studios want the namespace and > > persistence features as well? I don't know. > >Apparently they do because handles inherit the persistence requirements >of URNs (mainly because at one point handles were URNs since Bill Arms >was part of the entire URN discussions from the beginning and URN >resolution framework was engineered to accomodate the handle system). > > > > From all of the examples I've ever seen any DRM system is really just > > >a special function metadata service with some strong encryption thrown > > >in for good measure.... > > > > There needs to be integrity checking and authentication of the information > > asset and its source. > >Sure. But that's a feature of the system you use to get access to the object >in question. It isn't really a feature of the metadata store that tells you >things about it (the metadata store better be able to tell you the things >you need to know to do that integrity checking but doing the integrity >checking itself is feature overloading). > > > If the work is encrypted, then this entails some > > authentication of the entity that's going to receive the key. Many people > > would include clearing systems as part of DRM. > >Ok. I guess I lump that under the access method. I guess what I'm getting >at is that there needs to be a more modular approach where by someone >can pick and choose what DRM components they need instead of having >to swallow the 'whole enchilada'. Then each of those components should >use as much existing technology as possible: > >1) resource identification -- should be just URIs in general. If an object >uses a DRM system then that's discovered during resolution... > >2) secure rights metadata service -- should be something a little more >open than the handle system. The stuff that the RESCAP working group is >working on could be a very good candidate. At the same time you probably >don't want to tie it to any particular protocol (lots of folks will want >to use SOAP). > >3) access control -- new DRM type services for accessing objects securely and >in a way that enforced the rights that are expressed in #2. > >-MM > >-- >-------------------------------------------------------------------------------- >Michael Mealling | Vote Libertarian! | urn:pin:1 >michael@neonym.net | | http://www.neonym.net > | | go:Michael Mealling From mbaugher@cisco.com Wed May 23 21:19:32 2001 From: mbaugher@cisco.com (Mark Baugher) Date: Wed, 23 May 2001 13:19:32 -0700 Subject: [IETF-IDRM] Re: [IDRM] DRM Taxonomy work -- "content holder" vs. "content owner" In-Reply-To: <5.0.0.25.2.20010523110531.01bab200@pop.ne.mediaone.net> References: <003601c0e34a$dba71860$0a00a8c0@S2000> <5.0.0.25.2.20010514155912.0185c780@pop.ne.mediaone.net> <4.3.2.7.2.20010517141924.068f98c8@mira-sjc5-6.cisco.com> <5.0.0.25.2.20010519144826.01b563f0@pop.ne.mediaone.net> Message-ID: <4.3.2.7.2.20010523123920.0410a5d0@mira-sjc5-6.cisco.com> Thomas, Sam I think Renato has a good point about working from an existing framework such as Indecs. Page 16 of the Indecs framework shows the legal view of "persons, "intellectual property," and "(intellectual property) rights." This is what I think what you and Sam are discussing. Our exchange will be better grounded if we can relate these concepts to what the products of related efforts. Indecs recognizes that only a person or collection of persons have legal status, but other types of parties that do not have legal status are important to intellectual property rights, such as "Modonna," "Lassie," or the "Rolling Stones." The Indecs Directory of Parties: Outline Specification (http://www.indecs.org/pdf/DirectoryofParties.pdf) encounters the problems of uniqueness, persistence, privacy, operations and governance that are germane to the current idrm email threads, taxonomy and handle system. Mark as Indecs, which represents multiple person-years of work. At 11:16 AM 5/23/2001 -0400, Thomas Hardjono wrote: >OK, I'm still rather confused about the Content-Holder, but let me try a >very simple example: > > - Madonna issues a new song downloadable as MP3 through some > Content-Distributor. > > Here Madonna (or he record company/publisher) is the Content-Owner. > > - I download the song and pay $2 (reasonable I think :) > > Here I am the Content-Holder (where the Content is that MP3 file). > I only own my copy (1 copy) of that Content. I do not have further > rights. > >In this scenario, if I gave a copy of Madonna's MP3 song to my neighbor, >then clearly my neighbour has to (again) pay the Content-Owner (ie. Madonna >or her record company/publisher). > >Neither I nor my neighbour own the *rights* to that Content/MP3. > >Thus, I think the term Content-Holder means a holder of an instance >of a digital Content, where that holder is *not* the legal >owner of the copyright of the Content. > >Hmmmm, am I on track here? Isn't the Content-Holder = Consumer ? > >cheers, > >thomas >------ > >At 5/23/01||01:40 AM, Sam X. Sun (@S2000) wrote: >>My second question is regarding the content holder vs. content owner. >> >>When I say "content holder", I'm using it as a general term of "owner of an >>instance of digital content", or "a kind of digital content sharing some >>common attribute". The "content holder" can be "consumer", "distributor", >>"retailer", "publisher", and "content creator", depending on the "digital >>rights" he has and/or acquired for his copy of digital content. I tends of >>think of "consumer" as a relative term, depending on the view point. For >>example, "retailer" and "distributor" may all be treated as "consumer" (with >>special "distribution" rights) from a "publisher", and the "publisher" can >>generate money, directly or indirectly, from any kind of "consumer" of its >>content. >> >>I was trying to avoid using "content owner" but "content holder", fearing >>that the "content holder" is not necessarily the "owner of the content". >>Should we first try to clarify these terminologies? I guess this is one of >>the reasons Mark started this thread. >> >> >>Sam >> >>----- Original Message ----- >>From: "Thomas Hardjono" >>To: >>Sent: Saturday, May 19, 2001 3:17 PM >>Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... >> >> >> > >> > Hi Sam, >> > >> > I don't think you are off-track. You have brought up some good issues >>which >> > I'll comment below (I'll send comments about Mark's posting separately). >> > >> > >> > At 5/19/01||10:47 AM, Sam X. Sun (@S2000) wrote: >> > >Hi, >> > > >> > >I think it's a good application model to classify in end-to-end DRM >> > >relationships in terms of content provider and distributor, and >>distributor >> > >and content consumer. They represent some real world scenarios that DRM >>will >> > >have to address. On the other hand, I wonder if we could further model >>the >> > >underlying DRM framework in terms of transactions of certain entities >>(e.g. >> > >digital content) among other kinds of entities (e.g. content holder), and >> > >the transaction may be reflected in terms of exchange/update of digital >> > >rights bound to each content instance acquired by the content holder. >> > > >> > >In other words, I wonder whether it's reasonable to categorize the >>entities >> > >that DRM framework has to deal with in terms of: >> > > >> > > 1. the digital content (per instance) >> > > 2. the content holder (current or potential) >> > > >> > > >> > >And think of the digital rights as state information of the digital >>content >> > >hold by content holder. From this, one may imagine building mechanisms >> > >within the framework to: >> > > >> > > * Associate rights per digital content acquired by the content >>holder >> > > * Identify content holder, along with its authentication attributes. >> > > * Exchange/update digital rights per digital content among content >> > >holders >> > > * Facilitate/monitor/trace legitimate digital contents for their >>proper >> > >use >> > > * Report illegal content upon showing up within the framework >>(doable?) >> > > etc... >> > >> > I'm unclear about the term "content holder" above. I assume you mean >> > the Consumer that actually uses (reads/views/plays) the Content, >> > since Content not in the Consumer's hands will not generate money. >> > >> > As I understand it, the Digital-Rights (or Rights-Metadata) can be >> > Content-specific only or can be tied to both the Content and the Consumer. >> > >> > The distinction becomes relevant when we talk about the Business Models. >> > Thus, say in one business model, the Content-Creator/Owner may >> > specify usage rights in the Rights-Metadata (without mentioning specific >> > Customers). Assuming the Content-Creator/Owner has a business >>relationship >> > with a Distributor, then perhaps it is up to the Distributor(s) to >> > create further Rights-Metadata that is Customer-specific (eg. for Customer >> > who are members of the video-club, say). >> > >> > WRT your second bullet above, when the Distributor starts dealing >> > with Consumers (i.e content holder) does the Consumer's authentication >> > attributes becomes extremely relevant. It here that I think individual >> > certificates will become a key issue. A Customer's certificate will >>become >> > more important and persistent comapred to his/her credit card number. >> > And accounting and tracking may also perhaps be based on certificates. >> > >> > In terms of the transferability of Contents, most systems I have seen >> > or read about deploy some kind of verification/checking each time >> > the Content's ownership is transffered. Thus, in basic terms, if I sell >> > my (encrypted) MP3 file on eBay, then the purchaser will have to register >> > with the Distributor (or the entity claiming to be the contact-point for >>that >> > Content) and obtain a copy of the key (or a derived version). >> > >> > This model does not really fit into the "pure" P2P distribution scheme, >> > but it ensures continuous revenue for the distributor (who gets >> > additional new customer info). This model also allos tracking of >> > moved/sold Contents on the net. >> > >> > >> > >> > >Assumptions here are that everyone can obtain a copy of digital content >> > >freely, but need to acquire (e.g. via purchase) adequate rights to be >>able >> > >to "use" it. Depending on the rights associated to the digital content >> > >acquired by the content holder, the content holder could act as a >>publisher, >> > >a distributor, a retailer, or end consumer. >> > >> > This idea is cool and reflects more of the pure P2P approach. I don't >> > know if the big players will like the notion of a Consumer (content >>holder) >> > taking the role of publisher/distributor/retailer. >> > >> > I think the term P2P itself has been overused and means different things >> > to different people. I used it to mean the non-hierarchical/flat >> > distributed system that runs democratically from one user's machine >> > to another. >> > >> > Other people seem to mean P2P as "group-sharing of files" regardless >> > of how the files are managed (ie. the files could be sitting on >> > a single machine/server with everyone connecting to that server). >> > This later view is similar to the mainframe usage model of the 70s. >> > >> > >> > >> > >A transaction of digital content >> > >from a retailer to consumer could be modeled as retailer (with the right) >>to >> > >generate a new instance of the digital content, assign it with consumer >> > >rights, and "give" it to the consumer (along with the consumer rights). >> > >> > OK, so here is an interesting question: can BlockBuster Video make >> > copies of videos (ie. a new instant of content) in their backroom >> > and lease them? (and I don't mean replacements for broken/stolen >> > videocassettes). >> > >> > >> > >> > >A consumer may later become a retailer after obtaining the "retail" >>rights >> > >for its copy of digital content... >> > >> > Hmmm... >> > >> > cheers, >> > >> > thomas >> > ------ >> > From jpetrone@cnri.reston.va.us Wed May 23 22:53:33 2001 From: jpetrone@cnri.reston.va.us (Jason Petrone) Date: Wed, 23 May 2001 17:53:33 -0400 Subject: [IETF-IDRM] Re: [IDRM] DRM Taxonomy work -- "content holder" vs. "content owner" In-Reply-To: <"from thardjono"@mediaone.net> References: <5.0.0.25.2.20010514155912.0185c780@pop.ne.mediaone.net> <4.3.2.7.2.20010517141924.068f98c8@mira-sjc5-6.cisco.com> <5.0.0.25.2.20010519144826.01b563f0@pop.ne.mediaone.net> <003601c0e34a$dba71860$0a00a8c0@S2000> <5.0.0.25.2.20010523110531.01bab200@pop.ne.mediaone.net> Message-ID: <20010523175333.I23694@cnri.reston.va.us> I think both terms 'content owner' and 'content holder' are both vague. I understand 'content' to mean 'original work'. Despite the misleading term 'intellectual property', it is not something a person can own. I think better terms are 'copyright owner' and 'instance owner'. A copyright owner is guaranteed 6 exclusive rights: reproduction, adaptation, distribution, performance, display, and digital audio transmission. In the example Madonna or her publishing company is the copyright owner. If you give me a copy of Madonna's mp3, I don't owe her anything. I am not infringing on any of the 6 rights copyright law grants her. However, you may have. It is possible to split up these rights. For example, Madonna can give YOU exclusive reproduction and distribution rights. Then both you and her would be copyright owners. However, she can also grant you the same rights under a non-exclusive license, and she will remain the sole copyright owner. So in addition to 'copyright owner' and 'work instance owner', we also have licensee, a person who holds non-exclusive rights for that work. Jason On Wed, May 23, 2001 at 11:16:09AM -0400, Thomas Hardjono wrote: > > OK, I'm still rather confused about the Content-Holder, but let me try a > very simple example: > > - Madonna issues a new song downloadable as MP3 through some > Content-Distributor. > > Here Madonna (or he record company/publisher) is the Content-Owner. > > - I download the song and pay $2 (reasonable I think :) > > Here I am the Content-Holder (where the Content is that MP3 file). > I only own my copy (1 copy) of that Content. I do not have further > rights. > > In this scenario, if I gave a copy of Madonna's MP3 song to my neighbor, > then clearly my neighbour has to (again) pay the Content-Owner (ie. Madonna > or her record company/publisher). > > Neither I nor my neighbour own the *rights* to that Content/MP3. > > Thus, I think the term Content-Holder means a holder of an instance > of a digital Content, where that holder is *not* the legal > owner of the copyright of the Content. > > Hmmmm, am I on track here? Isn't the Content-Holder = Consumer ? > > cheers, > > thomas From jpetrone@cnri.reston.va.us Wed May 23 23:06:32 2001 From: jpetrone@cnri.reston.va.us (Jason Petrone) Date: Wed, 23 May 2001 18:06:32 -0400 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt In-Reply-To: <"from mbaugher"@cisco.com> References: <"from <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> <20010523013144.B7549@bailey.dscga.com> <4.3.2.7.2.20010522230155.021b3670@mira-sjc5-6.cisco.com> Message-ID: <20010523180632.J23694@cnri.reston.va.us> On Tue, May 22, 2001 at 11:21:48PM -0700, Mark Baugher wrote: > The Handle System is one system that addresses these requirements for > content-work publishing, in my opinion. You don't get this with URIs today. > Will publishers, record labels, movie studios want the namespace and > persistence features as well? I don't know. Book publishers are beginning to use the handle system for registering works(www.doi.org). Music publishers in the United States are moving in that direction as well. The deposit forms they submit to the US Copyright Office will soon include an entry for a handle. Jason From mbaugher@cisco.com Wed May 23 23:19:49 2001 From: mbaugher@cisco.com (Mark Baugher) Date: Wed, 23 May 2001 15:19:49 -0700 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt In-Reply-To: <20010523100013.C7549@bailey.dscga.com> References: <4.3.2.7.2.20010522230155.021b3670@mira-sjc5-6.cisco.com> Message-ID: <4.3.2.7.2.20010523150144.02088758@mira-sjc5-6.cisco.com> Michael, At 10:00 AM 5/23/2001 -0400, Michael Mealling wrote: >Right. I'm suggesting that instead of sticking to one URI scheme (handles) >that DRM should work for all URIs. And in the case where DRM needs >persistence it should only go as far as requiring URNs. I agree and I don't think it's being debated whether multiple schemes will will supported for DRM. The Handle System has a number of interesting properties in addition to persistent naming such as associating rights metadata and a trust infrastructure with a content work. That's why it's being discussed on this list. I think that CNRI wants to publish these drafts as Informational Standards and this discussion hopefully will help the authors improve them through this process. > > One issue that people have is that it is difficult or not impossible to > > identify content works and uses of content works that are legitimate > > from those that are not. > >And the desire is to be able to tell that from the identifier? That's really >dangerous ground becuase items and their identifiers change. Building human >semantic hints into the identifier for an object makes that identifier >much more fragile. That is the number one reason why there is that silly '//' >in all http URIs. As I said above, there's more to the Handle System than the naming. > > Will publishers, record labels, movie studios want the namespace and > > persistence features as well? I don't know. > >Apparently they do because handles inherit the persistence requirements >of URNs (mainly because at one point handles were URNs since Bill Arms >was part of the entire URN discussions from the beginning and URN >resolution framework was engineered to accomodate the handle system). Hence the relevance to this list. > > > From all of the examples I've ever seen any DRM system is really just > > >a special function metadata service with some strong encryption thrown > > >in for good measure.... > > > > There needs to be integrity checking and authentication of the information > > asset and its source. > >Sure. But that's a feature of the system you use to get access to the object >in question. It isn't really a feature of the metadata store that tells you >things about it (the metadata store better be able to tell you the things >you need to know to do that integrity checking but doing the integrity >checking itself is feature overloading). The metadata needs authentication and integrity. There also needs to be information about any object to identify how the infrastructure to be used for authentication and integrity. > > If the work is encrypted, then this entails some > > authentication of the entity that's going to receive the key. Many people > > would include clearing systems as part of DRM. > >Ok. I guess I lump that under the access method. I guess what I'm getting >at is that there needs to be a more modular approach where by someone >can pick and choose what DRM components they need instead of having >to swallow the 'whole enchilada'. Then each of those components should >use as much existing technology as possible: Is the Handle System purely a vertical solution? If so, then why would the authors unbundle the protocol, naming, and service definitions in separate I-D's? >1) resource identification -- should be just URIs in general. If an object >uses a DRM system then that's discovered during resolution... > >2) secure rights metadata service -- should be something a little more >open than the handle system. The stuff that the RESCAP working group is >working on could be a very good candidate. At the same time you probably >don't want to tie it to any particular protocol (lots of folks will want >to use SOAP). Right now, there are many candidates for the service, specification, trust, and authorization. Since we are a Research Group and do not develop standards, all of these candidates are of interest to us. >3) access control -- new DRM type services for accessing objects securely and >in a way that enforced the rights that are expressed in #2. I'd call this "authorization" rather than access control. A rights-managed object has a finer-grained access at the level of individual rights. Mark >-MM > >-- >-------------------------------------------------------------------------------- >Michael Mealling | Vote Libertarian! | urn:pin:1 >michael@neonym.net | | http://www.neonym.net > | | go:Michael Mealling From rkoenen@intertrust.com Thu May 24 02:49:31 2001 From: rkoenen@intertrust.com (Rob Koenen) Date: Wed, 23 May 2001 18:49:31 -0700 Subject: [IETF-IDRM] RE: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <720AE932C238D411B4D100C04F10DA6B03041723@exchange.epr.com> > Someone releasing a published work, say, to a consumer may have > different criteria of trust. But does the distributor or > service provider > need to know who the person is who is getting the content work? > If it's encrypted then there will be some authentication. But what > gets authenticated and how? Maybe the software or hardware used > to access the work gets authenticated and no information gets released > about the individual at all. I think this is among the MPEG > IPMP Requirements. > Users (parties in the exchange of value) are considered to have their rights and interests, and these are all considered by MPEG-21 Rob From mbaugher@cisco.com Thu May 24 03:02:03 2001 From: mbaugher@cisco.com (Mark Baugher) Date: Wed, 23 May 2001 19:02:03 -0700 Subject: [IETF-IDRM] RE: [IDRM] DRM Taxonomy work -- drm framework... In-Reply-To: <720AE932C238D411B4D100C04F10DA6B03041723@exchange.epr.com> Message-ID: <4.3.2.7.2.20010523190027.041a7008@mira-sjc5-6.cisco.com> Rob At 06:49 PM 5/23/2001 -0700, Rob Koenen wrote: > > Someone releasing a published work, say, to a consumer may have > > different criteria of trust. But does the distributor or > > service provider > > need to know who the person is who is getting the content work? > > If it's encrypted then there will be some authentication. But what > > gets authenticated and how? Maybe the software or hardware used > > to access the work gets authenticated and no information gets released > > about the individual at all. I think this is among the MPEG > > IPMP Requirements. > > > > >Users (parties in the exchange of value) are considered >to have their rights and interests, and these are all considered >by MPEG-21 I was thinking specifically of Requirements 4 and 5 of your Section 5 in http://www.cselt.it/mpeg/standards/ipmp/index.htm#_ftn1 Mark >Rob From rkoenen@intertrust.com Thu May 24 03:30:30 2001 From: rkoenen@intertrust.com (Rob Koenen) Date: Wed, 23 May 2001 19:30:30 -0700 Subject: [IETF-IDRM] RE: [IDRM] DRM Taxonomy work -- drm framework... Message-ID: <720AE932C238D411B4D100C04F10DA6B0304173A@exchange.epr.com> > >Users (parties in the exchange of value) are considered > >to have their rights and interests, and these are all considered > >by MPEG-21 > > I was thinking specifically of Requirements 4 and 5 of your Section > 5 in http://www.cselt.it/mpeg/standards/ipmp/index.htm#_ftn1 Hmmm, well spotted. Yes, the approach is consistent across all MPEG's. DRM technology can be used to manage and protect the rights and interests of all parties, and this is reflected in the MPEG-4 and MPEG-21 requirements. Rob From renato@iprsystems.com Thu May 24 03:33:55 2001 From: renato@iprsystems.com (Renato Iannella) Date: Thu, 24 May 2001 12:33:55 +1000 Subject: [IETF-IDRM] Re: [IDRM] DRM Taxonomy work -- "content holder" vs. "content owner" In-Reply-To: <20010523175333.I23694@cnri.reston.va.us> Message-ID: <682480.3199696435@localhost> --On 23/5/01 5:53 PM -0400 Jason Petrone wrote: > I think both terms 'content owner' and 'content holder' are both vague. I > understand 'content' to mean 'original work'. Despite the misleading term > 'intellectual property', it is not something a person can own. I think > better terms are 'copyright owner' and 'instance owner'. This is where the principles come in very handy. The key idea is not define an entity such as a "copyright owner" as you are conflating two core entities: Parties and Rights. Indecs would say that "Party X has Rights Y". Indecs model also assigns "roles" to parties (eg Author, Illustrator, Publisher) and then these can be mapped to jurisdiction-based copyright laws. These give maximum flexibility for DRM assertions. For a animated summary of the indecs model, see slides 22-36 here: http://www.w3.org/2000/12/drm-ws/pp/indecs-rust.ppt Also, you can/must own "intellectual property"- otherwise we wouldn't all be here !! ;-)) Cheers...Renato Chief Scientist, IPR Systems Pty Ltd From mbaugher@cisco.com Fri May 25 05:36:43 2001 From: mbaugher@cisco.com (Mark Baugher) Date: Thu, 24 May 2001 21:36:43 -0700 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt In-Reply-To: <4.3.2.7.2.20010522230429.00bb0b88@mira-sjc5-6.cisco.com> References: <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> Message-ID: <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> Here are the remaining questions and comments from the draft-irtf-idrm-handle-system-00.txt. Regarding my previous comments,is it accurate to say that the Handle System protocols could in principle be used with a variety of different servers/resolvers including DDDS? I have five points. 1) Section 1, under "Secured Named Service" describes specific cryptographic mechanisms but "Distributed Administration Service" does not. By briefly mentioning specific security and cryptographic mechanisms in this document, rather than in the later documents where they are specified, I think you raise more questions than you can answer in an Overview document. 2) Section 2, para 2, suggests that a persistent name can never be moved between naming authorities. If all rights to a content work were completely transferred from a corporation operating naming authority x, to one operating naming authority y, then the content work will still have x in its name. This seems like a problem to me. The DOI Handbook makes a point about handles being "dumb numbers," but these handles reveal information that will persist even when no longer valid. 3) Section 4, para 3, last sentence, defines an enormous PKI for a global namespace and I have some doubts about providing a security service for referencing potentially any content item in the world. It is a scalability issue if the handle system is not designed for smaller-scale and private use or if the trust and security mechanisms cannot be tailored to the needs of individual organizations and national considerations. There are large political issues here. This is the main problem I have with the Handle System. We may have an opportunity to consider this at length when discussing the next two drafts. 4) Section 4, para 5, should discuss the assets to be protected (e.g. handle metadata), the risks to those assets (e.g. corruption of handle metadata), and the sources of threats (e.g. hackers seeking fame or criminals seeking fortune). I believe the sentence "To trust a Local Handle Service means to trust that it will correctly respond with data that was entered by the administrator" is a too general to be useful. 5) The document needs a security section and should follow the other guidelines for formatting and mandatory sections of RFC 2223. At 11:05 PM 5/22/2001 -0700, Mark Baugher wrote: >Oh, by the way, this note is commenting upon >draft-irtf-idrm-handle-system-00.txt and not >draft-irtf-idrm-handle-system-protocol-00.txt - I made a mistake in the >Subject line that I'll correct in subsequent responses. > >Mark >At 10:26 PM 5/22/2001 -0700, Mark Baugher wrote: >>I have a number of comments on this draft. I also plan to post comments >>on the two other handle drafts, draft-irtf-idrm-handle-system-def-00.txt >>and draft-irtf-idrm-handle-system-protocol-00.txt. I'll start with >>draft-irtf-idrm-handle-system-00.txt comments, a couple at a time since >>my other questions and comments may be resolved along the way. >> >>My first comment is that there does not seem to be name-resolution draft >>in the mix. Is this not to be published? I can see a lot of uses for a >>namespace that is not global, such as between a content provider >>(publisher) and service provider (distributor) that want to use the >>metadata facilities of handles to store rights information with the >>content work and to identify one or more "official repositories" for the >>content work. If you're requiring a global namespace but not publishing >>the resolution mechanisms, then this seems to be an impediment to many >>business-to-business uses. >> >>Mark From llannom@cnri.reston.va.us Fri May 25 14:28:11 2001 From: llannom@cnri.reston.va.us (Larry Lannom) Date: Fri, 25 May 2001 09:28:11 -0400 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt In-Reply-To: <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> References: <4.3.2.7.2.20010522230429.00bb0b88@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> Message-ID: <5.0.2.1.2.20010525082955.05a884c0@kaluha> I'll let Sam answer the hard questions, but I believe your second poi= nt goes fairly directly to the 'semantically meaningful naming author= ity issue.' If the naming authority moving from X to Y is 10.3692 the= n the revealed information is a little obscure. If you have a good me= mory or access to administrative logs you may be able to tell that th= e handle10.3692/abc used to be owned and administered by X but has no= w moved to Y. If the handle was JohnWileyAndSons.JournalDivision/abc = then the situation is a little more confusing. This has been the subj= ect of a good deal of discussion over the years and I strongly encour= age non-semantic naming authorities. The commercial publishing world,= as an example, instinctively understands and supports this approach = (cf. ISBNs) and in the DOI world we have already had at least one ins= tance of a block of handles moving from one owner to another with no = apparent problems (American Chemical Society selling a journal to Wil= ey). So there are two potential problems with the transfer of ownersh= ip of Handles or Handle NAs: 1) semantically meaningful NAs and 2) sp= litting a set of handles under one NA across two or more owners who w= ant to administer their handles on different local handle services - = this is possible because the granularity of ownership is at the indiv= idual handle level and a potential problem because clients are direct= ed to local services by the global root based on NA. This situation h= asn't arisen (all DOIs, e.g., are in a single local service) but coul= d be forbidden by local service policy (the DOI choice) or by providi= ng clients with non-deterministic answers. This potential problem was= a direct trade-off for 1) allowing local services and 2) putting own= ership granularity at the handle level. So far it seems like the righ= t choice. Larry At 09:36 PM 5/24/01 -0700, Mark Baugher wrote: >Here are the remaining questions and comments from the draft-irtf-id= rm-handle-system-00.txt. Regarding my previous comments,is it accura= te to say that the Handle System protocols could in principle be used= with a variety of different servers/resolvers including DDDS? > >I have five points. > >1) Section 1, under "Secured Named Service" describes specific cryp= tographic mechanisms but "Distributed Administration Service" does no= t. By briefly mentioning specific security and cryptographic mechani= sms in this document, rather than in the later documents where they a= re specified, I think you raise more questions than you can answer in= an Overview document. > >2) Section 2, para 2, suggests that a persistent name can never be = moved between naming authorities. If all rights to a content work we= re completely transferred from a corporation operating naming authori= ty x, to one operating naming authority y, then the content work will= still have x in its name. This seems like a problem to me. The DOI= Handbook makes a point about handles being "dumb numbers," but these= handles reveal information that will persist even when no longer val= id. > >3) Section 4, para 3, last sentence, defines an enormous PKI for a g= lobal namespace and I have some doubts about providing a security ser= vice for referencing potentially any content item in the world. It i= s a scalability issue if the handle system is not designed for smalle= r-scale and private use or if the trust and security mechanisms canno= t be tailored to the needs of individual organizations and national c= onsiderations. There are large political issues here. This is the m= ain problem I have with the Handle System. We may have an opportunit= y to consider this at length when discussing the next two drafts. > >4) Section 4, para 5, should discuss the assets to be protected (e.g= . handle metadata), the risks to those assets (e.g. corruption of han= dle metadata), and the sources of threats (e.g. hackers seeking fame = or criminals seeking fortune). I believe the sentence "To trust a Lo= cal Handle Service means to trust that it will correctly respond with= data that was entered by the administrator" is a too general to be u= seful. > >5) The document needs a security section and should follow the other= guidelines for formatting and mandatory sections of RFC 2223. > >At 11:05 PM 5/22/2001 -0700, Mark Baugher wrote: >>Oh, by the way, this note is commenting upon draft-irtf-idrm-handle= -system-00.txt and not draft-irtf-idrm-handle-system-protocol-00.txt = - I made a mistake in the Subject line that I'll correct in subsequen= t responses. >> >>Mark >>At 10:26 PM 5/22/2001 -0700, Mark Baugher wrote: >>>I have a number of comments on this draft. I also plan to post co= mments on the two other handle drafts, draft-irtf-idrm-handle-system-= def-00.txt and draft-irtf-idrm-handle-system-protocol-00.txt. I'll s= tart with draft-irtf-idrm-handle-system-00.txt comments, a couple at = a time since my other questions and comments may be resolved along th= e way. >>> >>>My first comment is that there does not seem to be name-resolution= draft in the mix. Is this not to be published? I can see a lot of = uses for a namespace that is not global, such as between a content pr= ovider (publisher) and service provider (distributor) that want to us= e the metadata facilities of handles to store rights information with= the content work and to identify one or more "official repositories"= for the content work. If you're requiring a global namespace but no= t publishing the resolution mechanisms, then this seems to be an impe= diment to many business-to-business uses. >>> >>>Mark From mbaugher@cisco.com Fri May 25 19:17:51 2001 From: mbaugher@cisco.com (Mark Baugher) Date: Fri, 25 May 2001 11:17:51 -0700 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt In-Reply-To: <5.0.2.1.2.20010525082955.05a884c0@kaluha> References: <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522230429.00bb0b88@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> Message-ID: <4.3.2.7.2.20010525110344.042b5088@mira-sjc5-6.cisco.com> Thanks for the clarification, Larry. I have another question. At 09:28 AM 5/25/2001 -0400, Larry Lannom wrote: >I'll let Sam answer the hard questions, but I believe your second point >goes fairly directly to the 'semantically meaningful naming authority >issue.' If the naming authority moving from X to Y is 10.3692 then the >revealed information is a little obscure. If you have a good memory or >access to administrative logs you may be able to tell that the >handle10.3692/abc used to be owned and administered by X but has now moved >to Y. If the handle was JohnWileyAndSons.JournalDivision/abc then the >situation is a little more confusing. This has been the subject of a good >deal of discussion over the years and I strongly encourage non-semantic >naming authorities. The commercial publishing world, as an example, >instinctively understands and supports this approach (cf. >ISBNs) and in the DOI world we have already had at least one instance of a >block of handles moving from one owner to another with no apparent >problems (American Chemical Society selling a journal to Wiley). So there >are two potential problems with the transfer of ownership of Handles or >Handle NAs: 1) semantically meaningful NAs and 2) splitting a set of >handles under one NA across two or more owners who want to administer >their handles on different local handle services - this is possible >because the granularity of ownership is at the individual handle level and >a potential problem because clients are directed to local services by the >global root based on NA. This situation hasn't arisen (all DOIs, e.g., are >in a single local service) but could be forbidden by local service policy >(the DOI choice) or by providing clients with non-deterministic answers. >This potential problem was a direct trade-off for 1) allowing local >services and 2) putting ownership granularity at the handle level. So far >it seems like the right choice. A big question for me is what happens when John Wiley, let's say they are naming authority "167," transfers ownership of a work to Springer-Verlag who are "203." Since the work is prefixed with 167 forever, doesn't that mean that John Wiley's naming authority will always get queried for this work? That the trust and security for this work will reside with a John Wiley server and not with a Springer server? Or will the John Wiley server always need to redirect the client to the Springer server? If so, hopefully Springer won't sell it or it won't be sold many times - or else the client will be chasing around the Internet for awhile. thanks, Mark >Larry > >At 09:36 PM 5/24/01 -0700, Mark Baugher wrote: > >Here are the remaining questions and comments from the > draft-irtf-idrm-handle-system-00.txt. Regarding my previous comments,is > it accurate to say that the Handle System protocols could in principle be > used with a variety of different servers/resolvers including DDDS? > > > >I have five points. > > > >1) Section 1, under "Secured Named Service" describes specific > cryptographic mechanisms but "Distributed Administration Service" does > not. By briefly mentioning specific security and cryptographic > mechanisms in this document, rather than in the later documents where > they are specified, I think you raise more questions than you can answer > in an Overview document. > > > >2) Section 2, para 2, suggests that a persistent name can never be > moved between naming authorities. If all rights to a content work were > completely transferred from a corporation operating naming authority x, > to one operating naming authority y, then the content work will still > have x in its name. This seems like a problem to me. The DOI Handbook > makes a point about handles being "dumb numbers," but these handles > reveal information that will persist even when no longer valid. > > > >3) Section 4, para 3, last sentence, defines an enormous PKI for a > global namespace and I have some doubts about providing a security > service for referencing potentially any content item in the world. It is > a scalability issue if the handle system is not designed for > smaller-scale and private use or if the trust and security mechanisms > cannot be tailored to the needs of individual organizations and national > considerations. There are large political issues here. This is the main > problem I have with the Handle System. We may have an opportunity to > consider this at length when discussing the next two drafts. > > > >4) Section 4, para 5, should discuss the assets to be protected (e.g. > handle metadata), the risks to those assets (e.g. corruption of handle > metadata), and the sources of threats (e.g. hackers seeking fame or > criminals seeking fortune). I believe the sentence "To trust a Local > Handle Service means to trust that it will correctly respond with data > that was entered by the administrator" is a too general to be useful. > > > >5) The document needs a security section and should follow the other > guidelines for formatting and mandatory sections of RFC 2223. > > > >At 11:05 PM 5/22/2001 -0700, Mark Baugher wrote: > >>Oh, by the way, this note is commenting upon > draft-irtf-idrm-handle-system-00.txt and not > draft-irtf-idrm-handle-system-protocol-00.txt - I made a mistake in the > Subject line that I'll correct in subsequent responses. > >> > >>Mark > >>At 10:26 PM 5/22/2001 -0700, Mark Baugher wrote: > >>>I have a number of comments on this draft. I also plan to post > comments on the two other handle drafts, > draft-irtf-idrm-handle-system-def-00.txt and > draft-irtf-idrm-handle-system-protocol-00.txt. I'll start with > draft-irtf-idrm-handle-system-00.txt comments, a couple at a time since > my other questions and comments may be resolved along the way. > >>> > >>>My first comment is that there does not seem to be name-resolution > draft in the mix. Is this not to be published? I can see a lot of uses > for a namespace that is not global, such as between a content provider > (publisher) and service provider (distributor) that want to use the > metadata facilities of handles to store rights information with the > content work and to identify one or more "official repositories" for the > content work. If you're requiring a global namespace but not publishing > the resolution mechanisms, then this seems to be an impediment to many > business-to-business uses. > >>> > >>>Mark From ssun@cnri.reston.va.us Sat May 26 06:09:21 2001 From: ssun@cnri.reston.va.us (Sam X. Sun (@S2000)) Date: Sat, 26 May 2001 01:09:21 -0400 Subject: [IETF-IDRM] [IDRM] Re: draft-irtf-idrm-handle-system-protocol-00.txt References: <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> Message-ID: <008101c0e5a2$074a33e0$0a00a8c0@S2000> Hi Mark, Alhough the question is a bit outdated, I think it helps to cover the loose end... and here is the answer to your earlier question: > > My first comment is that there does not seem to be name-resolution draft in > the mix. Is this not to be published? I can see a lot of uses for a > namespace that is not global, such as between a content provider > (publisher) and service provider (distributor) that want to use the > metadata facilities of handles to store rights information with the content > work and to identify one or more "official repositories" for the content > work. If you're requiring a global namespace but not publishing the > resolution mechanisms, then this seems to be an impediment to many > business-to-business uses. > The mechanism for handle resolution is specified in the handle system protocol draft, which defines the interface between handle system client and server software. How handle server operates on its handle records (either from its local database or some remote data center) is left open for individual implementation. The idea is to allow people to add handle protocol to any existing data services (e.g. Oracle database, web server, file system, etc), instead of mandating one way or another. For example, our prototype implementation of handle server uses a local database to store and manage handle records. But people from www.enpia.com and www.cidf.org are building handle servers using remotely located Oracle and Informix databases for their handles. The resolution process within the server is totally transparent to the client. This approach leaves the door open so that people can do all they want to make the server more efficient and don't have to re-enter all their data for such application. Thanks, Sam From ssun@cnri.reston.va.us Sat May 26 06:36:41 2001 From: ssun@cnri.reston.va.us (Sam X. Sun (@S2000)) Date: Sat, 26 May 2001 01:36:41 -0400 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt References: <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> Message-ID: <008a01c0e5a5$d8aaf160$0a00a8c0@S2000> Mark, These are very good points, and my comments are below... ----- Original Message ----- From: "Mark Baugher" To: Cc: ; Sent: Friday, May 25, 2001 12:36 AM Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt > Here are the remaining questions and comments from the > draft-irtf-idrm-handle-system-00.txt. Regarding my previous comments,is it > accurate to say that the Handle System protocols could in principle be used > with a variety of different servers/resolvers including DDDS? > > I have five points. > > 1) Section 1, under "Secured Named Service" describes specific > cryptographic mechanisms but "Distributed Administration Service" does > not. By briefly mentioning specific security and cryptographic mechanisms > in this document, rather than in the later documents where they are > specified, I think you raise more questions than you can answer in an > Overview document. This is good. I will add that to the next version of the draft. > > 2) Section 2, para 2, suggests that a persistent name can never be moved > between naming authorities. If all rights to a content work were > completely transferred from a corporation operating naming authority x, to > one operating naming authority y, then the content work will still have x > in its name. This seems like a problem to me. The DOI Handbook makes a > point about handles being "dumb numbers," but these handles reveal > information that will persist even when no longer valid. > Larry has addressed this, and I will follow up on that thread in a separate message... > 3) Section 4, para 3, last sentence, defines an enormous PKI for a global > namespace and I have some doubts about providing a security service for > referencing potentially any content item in the world. It is a scalability > issue if the handle system is not designed for smaller-scale and private > use or if the trust and security mechanisms cannot be tailored to the needs > of individual organizations and national considerations. There are large > political issues here. This is the main problem I have with the Handle > System. We may have an opportunity to consider this at length when > discussing the next two drafts. Would you be more specific on those doubts so that we can discuss them here? Basically, the whole section is to outline the handle system security service, and the paragraph (para 3) outlines how service integrity and client authentication are carried out. It is stated in the protocol draft that each local handle service (hosted by individual organization) can add additional local policy regarding access control. However, how it is done is to be decided by each individual deployment. We expect that to be something conforming to KeyNote (also called PolicyMaker earlier). Are you suggesting that we should point that out here? Also, I'm not understanding the political issues here, could you elaborate? It might be worth noting that handle system security is only to address the transport security, i.e. the secure data transport between the handle system client and server. It does leave the hook for checking out content credentials, but that's for applications to take advantage of. The handle system is not a PKI framework by itself, but we think applications can be built on top of it to make PKI deployment easier. > 4) Section 4, para 5, should discuss the assets to be protected (e.g. > handle metadata), the risks to those assets (e.g. corruption of handle > metadata), and the sources of threats (e.g. hackers seeking fame or > criminals seeking fortune). I believe the sentence "To trust a Local > Handle Service means to trust that it will correctly respond with data that > was entered by the administrator" is a too general to be useful. > What I will do is to make a separate section to address "security considerations" as you mentioned earlier, and add these into it. Could you help coming up with the words? I will rephrase the sentence "to trust a ..." to make it more specific. > 5) The document needs a security section and should follow the other > guidelines for formatting and mandatory sections of RFC 2223. > Section 4 was intended to cover this. I will make a separate section to address this specifically. Thanks, Sam From thardjono@mediaone.net Sat May 26 06:53:14 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Sat, 26 May 2001 01:53:14 -0400 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt In-Reply-To: <4.3.2.7.2.20010525110344.042b5088@mira-sjc5-6.cisco.com> References: <5.0.2.1.2.20010525082955.05a884c0@kaluha> <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522230429.00bb0b88@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> Message-ID: <5.0.0.25.2.20010526013115.0252bd30@pop.ne.mediaone.net> At 5/25/01||11:17 AM, Mark Baugher wrote: >Thanks for the clarification, Larry. I have another question. > >At 09:28 AM 5/25/2001 -0400, Larry Lannom wrote: >>I'll let Sam answer the hard questions, but I believe your second point >>goes fairly directly to the 'semantically meaningful naming authority >>issue.' If the naming authority moving from X to Y is 10.3692 then the >>revealed information is a little obscure. If you have a good memory or >>access to administrative logs you may be able to tell that the >>handle10.3692/abc used to be owned and administered by X but has now >>moved to Y. If the handle was JohnWileyAndSons.JournalDivision/abc then >>the situation is a little more confusing. This has been the subject of a >>good deal of discussion over the years and I strongly encourage >>non-semantic naming authorities. The commercial publishing world, as an >>example, instinctively understands and supports this approach (cf. >>ISBNs) and in the DOI world we have already had at least one instance of >>a block of handles moving from one owner to another with no apparent >>problems (American Chemical Society selling a journal to Wiley). So there >>are two potential problems with the transfer of ownership of Handles or >>Handle NAs: 1) semantically meaningful NAs and 2) splitting a set of >>handles under one NA across two or more owners who want to administer >>their handles on different local handle services - this is possible >>because the granularity of ownership is at the individual handle level >>and a potential problem because clients are directed to local services by >>the global root based on NA. This situation hasn't arisen (all DOIs, >>e.g., are in a single local service) but could be forbidden by local >>service policy (the DOI choice) or by providing clients with >>non-deterministic answers. This potential problem was a direct trade-off >>for 1) allowing local services and 2) putting ownership granularity at >>the handle level. So far it seems like the right choice. > >A big question for me is what happens when John Wiley, let's say they are >naming authority "167," transfers ownership of a work to Springer-Verlag >who are "203." Since the work is prefixed with 167 forever, doesn't that >mean that John Wiley's naming authority will always get queried for this >work? That the trust and security for this work will reside with a John >Wiley server and not with a Springer server? Or will the John Wiley >server always need to redirect the client to the Springer server? If so, >hopefully Springer won't sell it or it won't be sold many times - or else >the client will be chasing around the Internet for awhile. > >thanks, Mark Larry, Sam, I had a similar question about non-semantic naming authorities, and I have accepted the reasoning that Sam put forward (and now clarified again by Larry). In the case of moving NAs, Does it make sense to simply concatenate NA numbers as sub-NAs (parsing from right-to-left), creating a path upward to the root NA (ie. similar to CAs and jurisdictions)? cheers, thomas ------ From ssun@cnri.reston.va.us Sat May 26 07:05:04 2001 From: ssun@cnri.reston.va.us (Sam X. Sun (@S2000)) Date: Sat, 26 May 2001 02:05:04 -0400 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt References: <5.0.2.1.2.20010525082955.05a884c0@kaluha> <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522230429.00bb0b88@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> <5.0.0.25.2.20010526013115.0252bd30@pop.ne.mediaone.net> Message-ID: <00ab01c0e5a9$cff2e650$0a00a8c0@S2000> Hi Thomas, This is a very good point, and it's another way to deal with the situation Mark brought up. It can be realized by "homing" the sub-NA naming authorities to the handle service of their parent naming authority, all transparent to the client. Eventually, they can all be "homed" at the root handle service, which is the original model Bob Kahn had for the handle system. The issues to consider are that the handle service for the parent naming authority is willing and has the capacity to do it, and the sub-naming authorities are willing to delegate management of their handles (and handle data) via the parent handle service. Sam ----- Original Message ----- From: "Thomas Hardjono" To: Cc: Sent: Saturday, May 26, 2001 1:53 AM Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt > > At 5/25/01||11:17 AM, Mark Baugher wrote: > >Thanks for the clarification, Larry. I have another question. > > > >At 09:28 AM 5/25/2001 -0400, Larry Lannom wrote: > >>I'll let Sam answer the hard questions, but I believe your second point > >>goes fairly directly to the 'semantically meaningful naming authority > >>issue.' If the naming authority moving from X to Y is 10.3692 then the > >>revealed information is a little obscure. If you have a good memory or > >>access to administrative logs you may be able to tell that the > >>handle10.3692/abc used to be owned and administered by X but has now > >>moved to Y. If the handle was JohnWileyAndSons.JournalDivision/abc then > >>the situation is a little more confusing. This has been the subject of a > >>good deal of discussion over the years and I strongly encourage > >>non-semantic naming authorities. The commercial publishing world, as an > >>example, instinctively understands and supports this approach (cf. > >>ISBNs) and in the DOI world we have already had at least one instance of > >>a block of handles moving from one owner to another with no apparent > >>problems (American Chemical Society selling a journal to Wiley). So there > >>are two potential problems with the transfer of ownership of Handles or > >>Handle NAs: 1) semantically meaningful NAs and 2) splitting a set of > >>handles under one NA across two or more owners who want to administer > >>their handles on different local handle services - this is possible > >>because the granularity of ownership is at the individual handle level > >>and a potential problem because clients are directed to local services by > >>the global root based on NA. This situation hasn't arisen (all DOIs, > >>e.g., are in a single local service) but could be forbidden by local > >>service policy (the DOI choice) or by providing clients with > >>non-deterministic answers. This potential problem was a direct trade-off > >>for 1) allowing local services and 2) putting ownership granularity at > >>the handle level. So far it seems like the right choice. > > > >A big question for me is what happens when John Wiley, let's say they are > >naming authority "167," transfers ownership of a work to Springer-Verlag > >who are "203." Since the work is prefixed with 167 forever, doesn't that > >mean that John Wiley's naming authority will always get queried for this > >work? That the trust and security for this work will reside with a John > >Wiley server and not with a Springer server? Or will the John Wiley > >server always need to redirect the client to the Springer server? If so, > >hopefully Springer won't sell it or it won't be sold many times - or else > >the client will be chasing around the Internet for awhile. > > > >thanks, Mark > > Larry, Sam, > > I had a similar question about non-semantic naming authorities, and > I have accepted the reasoning that Sam put forward (and now clarified > again by Larry). > > In the case of moving NAs, Does it make sense to simply concatenate NA numbers > as sub-NAs (parsing from right-to-left), creating a path upward to the > root NA (ie. similar to CAs and jurisdictions)? > > cheers, > > thomas > ------ > > From ssun@cnri.reston.va.us Sat May 26 08:01:06 2001 From: ssun@cnri.reston.va.us (Sam X. Sun (@S2000)) Date: Sat, 26 May 2001 03:01:06 -0400 Subject: [IETF-IDRM] Re: [IDRM] DRM Taxonomy work -- drm framework... -- handle system References: <5.0.0.25.2.20010514155912.0185c780@pop.ne.mediaone.net> <4.3.2.7.2.20010517141924.068f98c8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010521095254.04469ee8@mira-sjc5-6.cisco.com> <006001c0e34e$2cc005b0$0a00a8c0@S2000> <20010523101044.D7549@bailey.dscga.com> <00bd01c0e3ab$3e970010$5b041b0a@S2000> <20010523135034.K7549@bailey.dscga.com> Message-ID: <00b701c0e5b1$a3913af0$0a00a8c0@S2000> Michael, I'll address those issues that I think are related to this thread and discuss the others with you offline... My comments are below... ----- Original Message ----- From: "Michael Mealling" (skip...) > > In terms of Handle System and URN, I would say that they are quite different > > now in terms of how they work and the issues that they want to address. > > Sure. From what Larry was talking about, the system is much more concerned > about the rights metadata than the identifier resolution process... > Not totally right. Metadata is only one application of it. The handle system is just a general purpose global name service. The handle system protocol supports both handle resolution and administration. > > distributed name administration, > > What's being adminstered? Is that for provisioning of the identifier or managing > the metadata associated with the object being identified? The first is > interesting (and actually what the PROVREG group is doing.) The second > is a metadata service feature.... It's totally different from what PROVREG group is doing. It's about managing handle and the handle data, not necessarily the metadata. > > > internationalization > > (i18n), and service scalability. It might be helpful if you can read the > > latest HS drafts to understand the difference... > > I'll go check 'em out. Has it changed that radically? > Yes, it's a total redesign from the earlier version. The objective, the data model, and the protocol are all different. > > On the other hand, I see no > > reason why Handle System cannot work with URN. One way to do it is to > > register HS namespace as a namespace under URN, as we discussed earlier last > > year. > > That should be fairly painless. I'll send you the template.... > Thanks. I will study that after I get it. > > The issues that we need to address are how to make sure that the NAPTR > > approach won't become a bottleneck, > > It really can't. You only do one lookp and the record has a time to live of > several _years_. From my analysis you end up doing the _exact_ same number of > lookups for NAPTR records in the degenerative case (which handles would be) > as you do for A records.... > > > and how to achieve service security over such approach. > > The same way you are now. URI resolution just gets you to the authoritative > server for that identifier. How secure it is after that point is up to you and > the types of protocols/services you require to do the task. > > > Maybe we should discuss these in a separate thread, or bring > > them to the URN working group... > > I think that would be best. We don't want to bug these guys with identifier > stuff to much. ;-) > I will leave this for our offline discussion... (skip....) > > > In fact, because DNS is > > not secure as we know of today, that makes any name service based on DNS > > questionable in their security. > > Not true. While some aspects of DNSSEC are still being worked on. It is > very possible to have trusted DNS in normal operation. I won't agree with you. First of all, I remember from your colleague (Mark?) saying that the specification from DNSSEC is not compatible with current operation. Secondly, its deployment to individual boxes is still a long shot, especially for those existing boxes. I don't think it's appropriate to develop a system depending on something that will be in normal operation in some unknown future. > > > The Handle System is designed to be > > independent of DNS, and to address the security and i18n issues that DNS is > > struggling to overcome. > > And the URI resolution mechanism I mentioned solve those problems as well. > (Besides, i18n issues aren't really identifier related issues anyway.) > My understanding is that the DDDS (or URN/RDS) service is based on DNS. I'm not sure how you solve the security problem without DNSSEC in place. Could you elaborate? Regarding i18n, I don't agree it has nothing to do with identifier. Otherwise there wouldn't be a bof in URI i18n earlier. The problem is that we can't find a satisfying solution. When you build an end-to-end system like handle system, i18n must be addressed. Otherwise, we are heading to the same troubles that IDNS (International Domain Name) working group are dealing with... > > It has the advantage that it's starting from > > scratch, and doesn't have to deal with the backward compatibility issues > > that DNS has to take care of... On the other hand, we are in the process of > > defining handle system URI syntax for handles to be used in web context. In > > that sense, Handle system defines a namespace under URI, and we are in > > agreement there. > > Not really. My suggestion is that any DRM shouldn't need to make requirements > about the identifier itself. Any URI should be able to be used to find out > about and get rights enabled access to any object. Digital Rights > Management has about zero to do with the identifier used to talk about > the object.... > Mark has addressed this, and I won't repeat here. > > In fact, I'm more inclined to think that Handle System is in par with DNS. > > I'm more inclined to think of the RESCAP Working Group actually. > Besides that they prefer to start with a brand new approach with separate protocols for resolution and administration, and decide to base their protocols on DNS, there are many similarities to what RESCAP people want to address and what handle system has already addressed. There used to be some requirement drafts from that working group, but none of them are listed in their website. Do you have the latest on that? Maybe you can tell them more about the handle system... > > In fact, if DNS can address security, i18n, access control on name > > attributes, and to allow individuals to manage the names they registered, we > > probably won't need the Handle System. > > With the exception of that last item, this is _exactly_ what RESCAP was > chartered to do. That last item, in my opinion, is not a requirement of > digital rights management. Why do I have to use an identifier that is > registered with some third party? Most folks would like to be able to > manage the digital rights of http://www.joe-blow.com/music/my-music.midi > without having to create yet another identifier for it.... > You don't have to create another identifier if you decides to make the name coincide with the location of the digital object. > > On the other hand, people from DNS > > working group has refused to apply DNS as a general name service other than > > network-address translation, which makes us think that an independent name > > service would be helpful... > > Sure. Everyone should consider the DNS to be at the end of its usefullness. > It was never intended to be any of the things you listed there. > Where did the DNS come into this anyway? I don't think anyone has made > the suggestion that currently deployed DNS infrastructure can handle > any of this. This is why the URN working group did what it did. This > is why the IESG is creating uri.arpa as an infrastructure level Internet > technology for reliable, secure URI services such as caching/replication, > metadata, access control, policy, etc... > > There has been _considerable_ work done in the IETF in this particular area. > I'm just suggesting that this group use that work and not chuck all of it > in favor of one very verticle solution. Make the system modular and make > it use the identifier infrastructure that the IETF and the W3C are > standardizing on... Same here... > > -MM > > -- > -------------------------------------------------------------------------- ------ > Michael Mealling | Vote Libertarian! | urn:pin:1 > michael@neonym.net | | http://www.neonym.net > | | go:Michael Mealling From ssun@cnri.reston.va.us Sat May 26 08:02:57 2001 From: ssun@cnri.reston.va.us (Sam X. Sun (@S2000)) Date: Sat, 26 May 2001 03:02:57 -0400 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt References: <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522230429.00bb0b88@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010525110344.042b5088@mira-sjc5-6.cisco.com> Message-ID: <00ca01c0e5b1$e60ce230$0a00a8c0@S2000> Mark, By default, all handles under a naming authority are managed by a single handle service (or at least we encourage it being that way so that people can use the cached service information). But this is not a requirement. Handles under a naming authority can actually be managed by different handle services. When this happens, a flag in the service information (see Service Definition draft) must be set to reflect this. The service information must also set its TTL to zero so that all caching services know not to use it when resolving different handles (under the same naming authority) at a later time. As you can see, the downside of this approach is that it undermines the caching functionality for handles under the naming authority (up to the service information), and that's why we don't recommend it. Another way to do it is via aliasing (or redirection), which does have the potential that client will be chasing around if the ownership changes many times, which you have pointed out. Sam ----- Original Message ----- From: "Mark Baugher" To: "Larry Lannom" Cc: ; Sent: Friday, May 25, 2001 2:17 PM Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt > Thanks for the clarification, Larry. I have another question. > > At 09:28 AM 5/25/2001 -0400, Larry Lannom wrote: > >I'll let Sam answer the hard questions, but I believe your second point > >goes fairly directly to the 'semantically meaningful naming authority > >issue.' If the naming authority moving from X to Y is 10.3692 then the > >revealed information is a little obscure. If you have a good memory or > >access to administrative logs you may be able to tell that the > >handle10.3692/abc used to be owned and administered by X but has now moved > >to Y. If the handle was JohnWileyAndSons.JournalDivision/abc then the > >situation is a little more confusing. This has been the subject of a good > >deal of discussion over the years and I strongly encourage non-semantic > >naming authorities. The commercial publishing world, as an example, > >instinctively understands and supports this approach (cf. > >ISBNs) and in the DOI world we have already had at least one instance of a > >block of handles moving from one owner to another with no apparent > >problems (American Chemical Society selling a journal to Wiley). So there > >are two potential problems with the transfer of ownership of Handles or > >Handle NAs: 1) semantically meaningful NAs and 2) splitting a set of > >handles under one NA across two or more owners who want to administer > >their handles on different local handle services - this is possible > >because the granularity of ownership is at the individual handle level and > >a potential problem because clients are directed to local services by the > >global root based on NA. This situation hasn't arisen (all DOIs, e.g., are > >in a single local service) but could be forbidden by local service policy > >(the DOI choice) or by providing clients with non-deterministic answers. > >This potential problem was a direct trade-off for 1) allowing local > >services and 2) putting ownership granularity at the handle level. So far > >it seems like the right choice. > > A big question for me is what happens when John Wiley, let's say they are > naming authority "167," transfers ownership of a work to Springer-Verlag > who are "203." Since the work is prefixed with 167 forever, doesn't that > mean that John Wiley's naming authority will always get queried for this > work? That the trust and security for this work will reside with a John > Wiley server and not with a Springer server? Or will the John Wiley server > always need to redirect the client to the Springer server? If so, > hopefully Springer won't sell it or it won't be sold many times - or else > the client will be chasing around the Internet for awhile. > > thanks, Mark > > > > >Larry > > > >At 09:36 PM 5/24/01 -0700, Mark Baugher wrote: > > >Here are the remaining questions and comments from the > > draft-irtf-idrm-handle-system-00.txt. Regarding my previous comments,is > > it accurate to say that the Handle System protocols could in principle be > > used with a variety of different servers/resolvers including DDDS? > > > > > >I have five points. > > > > > >1) Section 1, under "Secured Named Service" describes specific > > cryptographic mechanisms but "Distributed Administration Service" does > > not. By briefly mentioning specific security and cryptographic > > mechanisms in this document, rather than in the later documents where > > they are specified, I think you raise more questions than you can answer > > in an Overview document. > > > > > >2) Section 2, para 2, suggests that a persistent name can never be > > moved between naming authorities. If all rights to a content work were > > completely transferred from a corporation operating naming authority x, > > to one operating naming authority y, then the content work will still > > have x in its name. This seems like a problem to me. The DOI Handbook > > makes a point about handles being "dumb numbers," but these handles > > reveal information that will persist even when no longer valid. > > > > > >3) Section 4, para 3, last sentence, defines an enormous PKI for a > > global namespace and I have some doubts about providing a security > > service for referencing potentially any content item in the world. It is > > a scalability issue if the handle system is not designed for > > smaller-scale and private use or if the trust and security mechanisms > > cannot be tailored to the needs of individual organizations and national > > considerations. There are large political issues here. This is the main > > problem I have with the Handle System. We may have an opportunity to > > consider this at length when discussing the next two drafts. > > > > > >4) Section 4, para 5, should discuss the assets to be protected (e.g. > > handle metadata), the risks to those assets (e.g. corruption of handle > > metadata), and the sources of threats (e.g. hackers seeking fame or > > criminals seeking fortune). I believe the sentence "To trust a Local > > Handle Service means to trust that it will correctly respond with data > > that was entered by the administrator" is a too general to be useful. > > > > > >5) The document needs a security section and should follow the other > > guidelines for formatting and mandatory sections of RFC 2223. > > > > > >At 11:05 PM 5/22/2001 -0700, Mark Baugher wrote: > > >>Oh, by the way, this note is commenting upon > > draft-irtf-idrm-handle-system-00.txt and not > > draft-irtf-idrm-handle-system-protocol-00.txt - I made a mistake in the > > Subject line that I'll correct in subsequent responses. > > >> > > >>Mark > > >>At 10:26 PM 5/22/2001 -0700, Mark Baugher wrote: > > >>>I have a number of comments on this draft. I also plan to post > > comments on the two other handle drafts, > > draft-irtf-idrm-handle-system-def-00.txt and > > draft-irtf-idrm-handle-system-protocol-00.txt. I'll start with > > draft-irtf-idrm-handle-system-00.txt comments, a couple at a time since > > my other questions and comments may be resolved along the way. > > >>> > > >>>My first comment is that there does not seem to be name-resolution > > draft in the mix. Is this not to be published? I can see a lot of uses > > for a namespace that is not global, such as between a content provider > > (publisher) and service provider (distributor) that want to use the > > metadata facilities of handles to store rights information with the > > content work and to identify one or more "official repositories" for the > > content work. If you're requiring a global namespace but not publishing > > the resolution mechanisms, then this seems to be an impediment to many > > business-to-business uses. > > >>> > > >>>Mark > From mbaugher@cisco.com Sat May 26 17:05:03 2001 From: mbaugher@cisco.com (Mark Baugher) Date: Sat, 26 May 2001 09:05:03 -0700 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt In-Reply-To: <5.0.0.25.2.20010526013115.0252bd30@pop.ne.mediaone.net> References: <4.3.2.7.2.20010525110344.042b5088@mira-sjc5-6.cisco.com> <5.0.2.1.2.20010525082955.05a884c0@kaluha> <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522230429.00bb0b88@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> Message-ID: <4.3.2.7.2.20010526090148.040b71b8@mira-sjc5-6.cisco.com> Hi Thomas, At 01:53 AM 5/26/2001 -0400, Thomas Hardjono wrote: >In the case of moving NAs, Does it make sense to simply concatenate NA numbers >as sub-NAs (parsing from right-to-left), creating a path upward to the >root NA (ie. similar to CAs and jurisdictions)? This won't work for a persistent name. Mark >cheers, > >thomas >------ > From thardjono@mediaone.net Tue May 29 02:56:25 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Mon, 28 May 2001 21:56:25 -0400 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt In-Reply-To: <4.3.2.7.2.20010526090148.040b71b8@mira-sjc5-6.cisco.com> References: <5.0.0.25.2.20010526013115.0252bd30@pop.ne.mediaone.net> <4.3.2.7.2.20010525110344.042b5088@mira-sjc5-6.cisco.com> <5.0.2.1.2.20010525082955.05a884c0@kaluha> <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522230429.00bb0b88@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> Message-ID: <5.0.0.25.2.20010528213717.027518d0@vhqpostal.verisign.com> Yes, Mark, I realize that it won't work :) .. I was rather soliciting ideas about solutions. I think identifiers/names/URIs can be guaranteed to be unique and persistent forever (literally). Just think about ISBN numbers. An ISBN number will not be "recycled", in the sense that the number will be associated with the book long after the author is gone. As far as I understand, each country has a body/authority to which an ISBN number can be requested. However, in the digital world, the location of the work on the Internet may change. Perhaps the notion of unique naming & naming-authority should be decoupled from the system that manages the Records pointing to locations. If a naming-authority is "acquired" by another naming-authority, then perhaps only the legal ownership should change. The NA numbers stay the same, only physically managed by a different company/organization. (The same analogy applies to one CA acquiring another. Another analogy is when a company who owns a block of IP addresses acquires another company with a different block of address.) cheers, thomas ------ At 5/26/01||09:05 AM, Mark Baugher wrote: >Hi Thomas, > >At 01:53 AM 5/26/2001 -0400, Thomas Hardjono wrote: > >>In the case of moving NAs, Does it make sense to simply concatenate NA >>numbers >>as sub-NAs (parsing from right-to-left), creating a path upward to the >>root NA (ie. similar to CAs and jurisdictions)? > >This won't work for a persistent name. > >Mark > > >>cheers, >> >>thomas >>------ From mbaugher@cisco.com Tue May 29 16:11:03 2001 From: mbaugher@cisco.com (Mark Baugher) Date: Tue, 29 May 2001 08:11:03 -0700 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt In-Reply-To: <008a01c0e5a5$d8aaf160$0a00a8c0@S2000> References: <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> Message-ID: <4.3.2.7.2.20010529080749.048e2fd0@mira-sjc5-6.cisco.com> Hi Sam, http://search.ietf.org/internet-drafts/draft-rescorla-sec-cons-03.txt provides some suggestions on writing security sections and I'd be happy to help. Regarding point 3, below, we can discuss this better in the context of the next two drafts. I need to go back and review some of the points you mentioned in your note. Mark At 01:36 AM 5/26/2001 -0400, Sam X. Sun (@S2000) wrote: >Mark, > >These are very good points, and my comments are below... > >----- Original Message ----- >From: "Mark Baugher" >To: >Cc: ; >Sent: Friday, May 25, 2001 12:36 AM >Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt > > > > Here are the remaining questions and comments from the > > draft-irtf-idrm-handle-system-00.txt. Regarding my previous comments,is >it > > accurate to say that the Handle System protocols could in principle be >used > > with a variety of different servers/resolvers including DDDS? > > > > I have five points. > > > > 1) Section 1, under "Secured Named Service" describes specific > > cryptographic mechanisms but "Distributed Administration Service" does > > not. By briefly mentioning specific security and cryptographic mechanisms > > in this document, rather than in the later documents where they are > > specified, I think you raise more questions than you can answer in an > > Overview document. > >This is good. I will add that to the next version of the draft. > > > > > 2) Section 2, para 2, suggests that a persistent name can never be moved > > between naming authorities. If all rights to a content work were > > completely transferred from a corporation operating naming authority x, to > > one operating naming authority y, then the content work will still have x > > in its name. This seems like a problem to me. The DOI Handbook makes a > > point about handles being "dumb numbers," but these handles reveal > > information that will persist even when no longer valid. > > > >Larry has addressed this, and I will follow up on that thread in a separate >message... > > > 3) Section 4, para 3, last sentence, defines an enormous PKI for a global > > namespace and I have some doubts about providing a security service for > > referencing potentially any content item in the world. It is a >scalability > > issue if the handle system is not designed for smaller-scale and private > > use or if the trust and security mechanisms cannot be tailored to the >needs > > of individual organizations and national considerations. There are large > > political issues here. This is the main problem I have with the Handle > > System. We may have an opportunity to consider this at length when > > discussing the next two drafts. > >Would you be more specific on those doubts so that we can discuss them here? >Basically, the whole section is to outline the handle system security >service, and the paragraph (para 3) outlines how service integrity and >client authentication are carried out. It is stated in the protocol draft >that each local handle service (hosted by individual organization) can add >additional local policy regarding access control. However, how it is done is >to be decided by each individual deployment. We expect that to be something >conforming to KeyNote (also called PolicyMaker earlier). Are you suggesting >that we should point that out here? Also, I'm not understanding the >political issues here, could you elaborate? > >It might be worth noting that handle system security is only to address the >transport security, i.e. the secure data transport between the handle system >client and server. It does leave the hook for checking out content >credentials, but that's for applications to take advantage of. The handle >system is not a PKI framework by itself, but we think applications can be >built on top of it to make PKI deployment easier. > > > > 4) Section 4, para 5, should discuss the assets to be protected (e.g. > > handle metadata), the risks to those assets (e.g. corruption of handle > > metadata), and the sources of threats (e.g. hackers seeking fame or > > criminals seeking fortune). I believe the sentence "To trust a Local > > Handle Service means to trust that it will correctly respond with data >that > > was entered by the administrator" is a too general to be useful. > > > >What I will do is to make a separate section to address "security >considerations" as you mentioned earlier, and add these into it. Could you >help coming up with the words? I will rephrase the sentence "to trust a ..." >to make it more specific. > > > > 5) The document needs a security section and should follow the other > > guidelines for formatting and mandatory sections of RFC 2223. > > > >Section 4 was intended to cover this. I will make a separate section to >address this specifically. > > >Thanks, >Sam From mbaugher@cisco.com Tue May 29 16:15:44 2001 From: mbaugher@cisco.com (Mark Baugher) Date: Tue, 29 May 2001 08:15:44 -0700 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt In-Reply-To: <00ca01c0e5b1$e60ce230$0a00a8c0@S2000> References: <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522230429.00bb0b88@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010525110344.042b5088@mira-sjc5-6.cisco.com> Message-ID: <4.3.2.7.2.20010529081219.04897f08@mira-sjc5-6.cisco.com> Sam, At 03:02 AM 5/26/2001 -0400, Sam X. Sun \(@S2000\) wrote: >Mark, > >By default, all handles under a naming authority are managed by a single >handle service (or at least we encourage it being that way so that people Maybe I'm confused here, but I'm thinking of two organizations, they might be publishing companies who are competitors, that serve as naming authorities for their respective publications. One of the competitors transfers ownership rights to the other and now one naming authority is referenced in the name of the work while a second naming authority has all rights to the work. So I'm not considering the case of two services under one naming authority but two different naming authorities. Mark >can use the cached service information). But this is not a requirement. >Handles under a naming authority can actually be managed by different handle >services. When this happens, a flag in the service information (see Service >Definition draft) must be set to reflect this. The service information must >also set its TTL to zero so that all caching services know not to use it >when resolving different handles (under the same naming authority) at a >later time. As you can see, the downside of this approach is that it >undermines the caching functionality for handles under the naming authority >(up to the service information), and that's why we don't recommend it. > >Another way to do it is via aliasing (or redirection), which does have the >potential that client will be chasing around if the ownership changes many >times, which you have pointed out. > > >Sam > > >----- Original Message ----- >From: "Mark Baugher" >To: "Larry Lannom" >Cc: ; >Sent: Friday, May 25, 2001 2:17 PM >Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt > > > > Thanks for the clarification, Larry. I have another question. > > > > At 09:28 AM 5/25/2001 -0400, Larry Lannom wrote: > > >I'll let Sam answer the hard questions, but I believe your second point > > >goes fairly directly to the 'semantically meaningful naming authority > > >issue.' If the naming authority moving from X to Y is 10.3692 then the > > >revealed information is a little obscure. If you have a good memory or > > >access to administrative logs you may be able to tell that the > > >handle10.3692/abc used to be owned and administered by X but has now >moved > > >to Y. If the handle was JohnWileyAndSons.JournalDivision/abc then the > > >situation is a little more confusing. This has been the subject of a good > > >deal of discussion over the years and I strongly encourage non-semantic > > >naming authorities. The commercial publishing world, as an example, > > >instinctively understands and supports this approach (cf. > > >ISBNs) and in the DOI world we have already had at least one instance of >a > > >block of handles moving from one owner to another with no apparent > > >problems (American Chemical Society selling a journal to Wiley). So there > > >are two potential problems with the transfer of ownership of Handles or > > >Handle NAs: 1) semantically meaningful NAs and 2) splitting a set of > > >handles under one NA across two or more owners who want to administer > > >their handles on different local handle services - this is possible > > >because the granularity of ownership is at the individual handle level >and > > >a potential problem because clients are directed to local services by the > > >global root based on NA. This situation hasn't arisen (all DOIs, e.g., >are > > >in a single local service) but could be forbidden by local service policy > > >(the DOI choice) or by providing clients with non-deterministic answers. > > >This potential problem was a direct trade-off for 1) allowing local > > >services and 2) putting ownership granularity at the handle level. So far > > >it seems like the right choice. > > > > A big question for me is what happens when John Wiley, let's say they are > > naming authority "167," transfers ownership of a work to Springer-Verlag > > who are "203." Since the work is prefixed with 167 forever, doesn't that > > mean that John Wiley's naming authority will always get queried for this > > work? That the trust and security for this work will reside with a John > > Wiley server and not with a Springer server? Or will the John Wiley >server > > always need to redirect the client to the Springer server? If so, > > hopefully Springer won't sell it or it won't be sold many times - or else > > the client will be chasing around the Internet for awhile. > > > > thanks, Mark > > > > > > > > >Larry > > > > > >At 09:36 PM 5/24/01 -0700, Mark Baugher wrote: > > > >Here are the remaining questions and comments from the > > > draft-irtf-idrm-handle-system-00.txt. Regarding my previous comments,is > > > it accurate to say that the Handle System protocols could in principle >be > > > used with a variety of different servers/resolvers including DDDS? > > > > > > > >I have five points. > > > > > > > >1) Section 1, under "Secured Named Service" describes specific > > > cryptographic mechanisms but "Distributed Administration Service" does > > > not. By briefly mentioning specific security and cryptographic > > > mechanisms in this document, rather than in the later documents where > > > they are specified, I think you raise more questions than you can answer > > > in an Overview document. > > > > > > > >2) Section 2, para 2, suggests that a persistent name can never be > > > moved between naming authorities. If all rights to a content work were > > > completely transferred from a corporation operating naming authority x, > > > to one operating naming authority y, then the content work will still > > > have x in its name. This seems like a problem to me. The DOI Handbook > > > makes a point about handles being "dumb numbers," but these handles > > > reveal information that will persist even when no longer valid. > > > > > > > >3) Section 4, para 3, last sentence, defines an enormous PKI for a > > > global namespace and I have some doubts about providing a security > > > service for referencing potentially any content item in the world. It >is > > > a scalability issue if the handle system is not designed for > > > smaller-scale and private use or if the trust and security mechanisms > > > cannot be tailored to the needs of individual organizations and national > > > considerations. There are large political issues here. This is the >main > > > problem I have with the Handle System. We may have an opportunity to > > > consider this at length when discussing the next two drafts. > > > > > > > >4) Section 4, para 5, should discuss the assets to be protected (e.g. > > > handle metadata), the risks to those assets (e.g. corruption of handle > > > metadata), and the sources of threats (e.g. hackers seeking fame or > > > criminals seeking fortune). I believe the sentence "To trust a Local > > > Handle Service means to trust that it will correctly respond with data > > > that was entered by the administrator" is a too general to be useful. > > > > > > > >5) The document needs a security section and should follow the other > > > guidelines for formatting and mandatory sections of RFC 2223. > > > > > > > >At 11:05 PM 5/22/2001 -0700, Mark Baugher wrote: > > > >>Oh, by the way, this note is commenting upon > > > draft-irtf-idrm-handle-system-00.txt and not > > > draft-irtf-idrm-handle-system-protocol-00.txt - I made a mistake in the > > > Subject line that I'll correct in subsequent responses. > > > >> > > > >>Mark > > > >>At 10:26 PM 5/22/2001 -0700, Mark Baugher wrote: > > > >>>I have a number of comments on this draft. I also plan to post > > > comments on the two other handle drafts, > > > draft-irtf-idrm-handle-system-def-00.txt and > > > draft-irtf-idrm-handle-system-protocol-00.txt. I'll start with > > > draft-irtf-idrm-handle-system-00.txt comments, a couple at a time since > > > my other questions and comments may be resolved along the way. > > > >>> > > > >>>My first comment is that there does not seem to be name-resolution > > > draft in the mix. Is this not to be published? I can see a lot of uses > > > for a namespace that is not global, such as between a content provider > > > (publisher) and service provider (distributor) that want to use the > > > metadata facilities of handles to store rights information with the > > > content work and to identify one or more "official repositories" for the > > > content work. If you're requiring a global namespace but not publishing > > > the resolution mechanisms, then this seems to be an impediment to many > > > business-to-business uses. > > > >>> > > > >>>Mark > > From ssun@cnri.reston.va.us Wed May 30 13:35:20 2001 From: ssun@cnri.reston.va.us (Sam X. Sun (@S2000)) Date: Wed, 30 May 2001 08:35:20 -0400 Subject: [IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt References: <4.3.2.7.2.20010524173144.04035ee8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522230429.00bb0b88@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010522222428.021b2c50@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010525110344.042b5088@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010529081219.04897f08@mira-sjc5-6.cisco.com> Message-ID: <007701c0e904$fda342d0$0a00a8c0@S2000> Mark, I was confused your scenario with the multiple primary (service) configuration. So ignore my earlier message on this, and let me know what do you think of the following... Basically, I think there are two ways to address the ownership change over time. One is via the "handle alias", as described in the second draft "HS namespace and service definition" (see http://www.idrm.org/draft-irtf-idrm-handle-system-def-01.txt). In section 3.2.4, it says "When a resource identified by a handle transfers from one organization to another, a new handle for the resource may be created. To avoid inconsistency and broken references, the handle used before the ownership transfer may be changed to a handle alias and its HS_ALIAS value pointed to the newly created handle". Each handle alias can have its administrator defined in terms of the new ownership so that they can be managed by its owner, not the handle service where the handle alias is residing on. Multiple aliases may be created if the ownership changes hands many times. Each handle alias should be referring to the handle that points to the final resource, to avoid clients chasing the aliases around. Thus in the case you described earlier, when John Wiley (suppose whose naming authority is 167) transfers ownership of a work referenced by handle 167/1 to Sprinter-Verlag (suppose whose naming authority is 203), Sprinter-Verlag can create a new handle as 203/678 for that work, while John Wiley has to convert 167/1 into a handle alias (for 203/678), and add John Wiley as the administrator for 167/1 as part of the ownership transfer. Clients accessing the work through 167/1 may make note of the ownership transfer via the handle alias. Another way to deal with ownership change is to "relocate" both naming authorities (i.e. 167 and 203) onto the same handle service. Under this scenario, all we need to do (for ownership transfer) is to add Sprinter-Verlag as the administrator as the administrator for the John Wiley handle (e.g. 167/1). Does these may sense? Thanks, Sam ----- Original Message ----- From: "Mark Baugher" > Sam, > > At 03:02 AM 5/26/2001 -0400, Sam X. Sun \(@S2000\) wrote: > >Mark, > > > >By default, all handles under a naming authority are managed by a single > >handle service (or at least we encourage it being that way so that people > > Maybe I'm confused here, but I'm thinking of two organizations, they might > be publishing companies who are competitors, that serve as naming authorities > for their respective publications. One of the competitors transfers ownership > rights to the other and now one naming authority is referenced in the name > of the work while a second naming authority has all rights to the work. So > I'm not considering the case of two services under one naming authority but > two different naming authorities. > > >can use the cached service information). But this is not a requirement. > >Handles under a naming authority can actually be managed by different handle > >services. When this happens, a flag in the service information (see Service > >Definition draft) must be set to reflect this. The service information must > >also set its TTL to zero so that all caching services know not to use it > >when resolving different handles (under the same naming authority) at a > >later time. As you can see, the downside of this approach is that it > >undermines the caching functionality for handles under the naming authority > >(up to the service information), and that's why we don't recommend it. > > > >Another way to do it is via aliasing (or redirection), which does have the > >potential that client will be chasing around if the ownership changes many > >times, which you have pointed out. > > > > > >Sam > > > > > >----- Original Message ----- > >From: "Mark Baugher" > >To: "Larry Lannom" > >Cc: ; > >Sent: Friday, May 25, 2001 2:17 PM > >Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt > > > > > > > Thanks for the clarification, Larry. I have another question. > > > > > > At 09:28 AM 5/25/2001 -0400, Larry Lannom wrote: > > > >I'll let Sam answer the hard questions, but I believe your second point > > > >goes fairly directly to the 'semantically meaningful naming authority > > > >issue.' If the naming authority moving from X to Y is 10.3692 then the > > > >revealed information is a little obscure. If you have a good memory or > > > >access to administrative logs you may be able to tell that the > > > >handle10.3692/abc used to be owned and administered by X but has now > >moved > > > >to Y. If the handle was JohnWileyAndSons.JournalDivision/abc then the > > > >situation is a little more confusing. This has been the subject of a good > > > >deal of discussion over the years and I strongly encourage non-semantic > > > >naming authorities. The commercial publishing world, as an example, > > > >instinctively understands and supports this approach (cf. > > > >ISBNs) and in the DOI world we have already had at least one instance of > >a > > > >block of handles moving from one owner to another with no apparent > > > >problems (American Chemical Society selling a journal to Wiley). So there > > > >are two potential problems with the transfer of ownership of Handles or > > > >Handle NAs: 1) semantically meaningful NAs and 2) splitting a set of > > > >handles under one NA across two or more owners who want to administer > > > >their handles on different local handle services - this is possible > > > >because the granularity of ownership is at the individual handle level > >and > > > >a potential problem because clients are directed to local services by the > > > >global root based on NA. This situation hasn't arisen (all DOIs, e.g., > >are > > > >in a single local service) but could be forbidden by local service policy > > > >(the DOI choice) or by providing clients with non-deterministic answers. > > > >This potential problem was a direct trade-off for 1) allowing local > > > >services and 2) putting ownership granularity at the handle level. So far > > > >it seems like the right choice. > > > > > > A big question for me is what happens when John Wiley, let's say they are > > > naming authority "167," transfers ownership of a work to Springer-Verlag > > > who are "203." Since the work is prefixed with 167 forever, doesn't that > > > mean that John Wiley's naming authority will always get queried for this > > > work? That the trust and security for this work will reside with a John > > > Wiley server and not with a Springer server? Or will the John Wiley > >server > > > always need to redirect the client to the Springer server? If so, > > > hopefully Springer won't sell it or it won't be sold many times - or else > > > the client will be chasing around the Internet for awhile. > > > > > > thanks, Mark > > > > > > > > > > > > >Larry > > > > > > > >At 09:36 PM 5/24/01 -0700, Mark Baugher wrote: > > > > >Here are the remaining questions and comments from the > > > > draft-irtf-idrm-handle-system-00.txt. Regarding my previous comments,is > > > > it accurate to say that the Handle System protocols could in principle > >be > > > > used with a variety of different servers/resolvers including DDDS? > > > > > > > > > >I have five points. > > > > > > > > > >1) Section 1, under "Secured Named Service" describes specific > > > > cryptographic mechanisms but "Distributed Administration Service" does > > > > not. By briefly mentioning specific security and cryptographic > > > > mechanisms in this document, rather than in the later documents where > > > > they are specified, I think you raise more questions than you can answer > > > > in an Overview document. > > > > > > > > > >2) Section 2, para 2, suggests that a persistent name can never be > > > > moved between naming authorities. If all rights to a content work were > > > > completely transferred from a corporation operating naming authority x, > > > > to one operating naming authority y, then the content work will still > > > > have x in its name. This seems like a problem to me. The DOI Handbook > > > > makes a point about handles being "dumb numbers," but these handles > > > > reveal information that will persist even when no longer valid. > > > > > > > > > >3) Section 4, para 3, last sentence, defines an enormous PKI for a > > > > global namespace and I have some doubts about providing a security > > > > service for referencing potentially any content item in the world. It > >is > > > > a scalability issue if the handle system is not designed for > > > > smaller-scale and private use or if the trust and security mechanisms > > > > cannot be tailored to the needs of individual organizations and national > > > > considerations. There are large political issues here. This is the > >main > > > > problem I have with the Handle System. We may have an opportunity to > > > > consider this at length when discussing the next two drafts. > > > > > > > > > >4) Section 4, para 5, should discuss the assets to be protected (e.g. > > > > handle metadata), the risks to those assets (e.g. corruption of handle > > > > metadata), and the sources of threats (e.g. hackers seeking fame or > > > > criminals seeking fortune). I believe the sentence "To trust a Local > > > > Handle Service means to trust that it will correctly respond with data > > > > that was entered by the administrator" is a too general to be useful. > > > > > > > > > >5) The document needs a security section and should follow the other > > > > guidelines for formatting and mandatory sections of RFC 2223. > > > > > > > > > >At 11:05 PM 5/22/2001 -0700, Mark Baugher wrote: > > > > >>Oh, by the way, this note is commenting upon > > > > draft-irtf-idrm-handle-system-00.txt and not > > > > draft-irtf-idrm-handle-system-protocol-00.txt - I made a mistake in the > > > > Subject line that I'll correct in subsequent responses. > > > > >> > > > > >>Mark > > > > >>At 10:26 PM 5/22/2001 -0700, Mark Baugher wrote: > > > > >>>I have a number of comments on this draft. I also plan to post > > > > comments on the two other handle drafts, > > > > draft-irtf-idrm-handle-system-def-00.txt and > > > > draft-irtf-idrm-handle-system-protocol-00.txt. I'll start with > > > > draft-irtf-idrm-handle-system-00.txt comments, a couple at a time since > > > > my other questions and comments may be resolved along the way. > > > > >>> > > > > >>>My first comment is that there does not seem to be name-resolution > > > > draft in the mix. Is this not to be published? I can see a lot of uses > > > > for a namespace that is not global, such as between a content provider > > > > (publisher) and service provider (distributor) that want to use the > > > > metadata facilities of handles to store rights information with the > > > > content work and to identify one or more "official repositories" for the > > > > content work. If you're requiring a global namespace but not publishing > > > > the resolution mechanisms, then this seems to be an impediment to many > > > > business-to-business uses. > > > > >>> > > > > >>>Mark > > > > From thardjono@mediaone.net Thu May 31 14:05:04 2001 From: thardjono@mediaone.net (Thomas Hardjono) Date: Thu, 31 May 2001 09:05:04 -0400 Subject: [IETF-IDRM] [IDRM] Fwd: Patents & Copyright Message-ID: <5.0.0.25.2.20010531090424.027f5990@pop.ne.mediaone.net> --- begin forwarded text Date: Wed, 30 May 2001 10:54:19 -0700 Reply-To: Hayek Related Research Sender: Hayek Related Research =46rom: List Host Organization: @Home Network Subject: Is It Hayek? -- Patents & Copyright, a debate To: HAYEK-L@MAELSTROM.STJOHNS.EDU >> Is It Hayek << -- Patent law / Copyright Symposium on patents & copyright -- A Debate, on the web at: http://www.insightmag.com/archive/200105229.shtml >From the debate: Q: Do patents and copyrights undermine private property? Yes: They are a burden to marketplace transactions and discourage business startups. By Ilana Mercer and N. Stephan Kinsella Property and liberty are intricately linked. In fact proper= ty, not representative government or majority rule, exemplifies freedom. Property is a sphere in which the individual can be free of government; the historical role of private property as countervail= ing to the power of the state cannot be overstated. Equally strong is the relationship between strong private-property rights and prosperity= . If nothing else, the dismal economic failure of socialism has demonstrated what transpires when private ownership of the means of production is abolished. The insidious and persistent encroachment on property by th= e modern welfare state has, however, resulted in a complete confusio= n about the nature of ownership. By undermining the ethical foundati= ons upon which property rests, the welfare state has made it morally acceptable to give people access to property they don=EDt own. Property grabs run the gamut from taxation, welfare programs, forfeitures, and environmental and antitrust legislation to the mo= re subtle interference with freedom of contract inherent in minimum-wage laws and affirmative hiring. Copyright and patent grants of privilege are another form o= f property infringement =F3 courtesy of the state. While they have t= heir origins in a much earlier privilege given to =ECfriends of the cro= wn,=EE in their modern incarnation they blend in with the welfare state=EDs wealth-distributing impetus. Far from being =ECnatural=EE property= rights grounded in the common law, patent and copyright are monopoly privileges granted solely by state legislation. Copyright gives authors of original works (e.g., books) the exclusive rights to copy the work or to prepare =ECderivative work= s=EE based on the original. A patent gives an inventor the right to sto= p others from making, using or selling the patented invention. In bo= th cases, the holder of this right is given legal control over how ot= hers use their property. As the author of a differently hued Gone with = the Wind recently found out, the copyright holder can stop you from using your own paper and ink to publish a novel that reproduces th= e copyrighted work or one based on its plot. The estate of Margaret Mitchell, author of Gone with the Wind, is suing Alice Randall to block her from publishing the parody The Wind Done Gone. Randall tells the famous tale from the perspective of black slaves. The mere act of creation =F3 composing a song, penning a no= vel or inventing a mousetrap =F3 gives the creator control over the ta= ngible property of others. In addition to allowing the author partially t= o control the paper, ink, computer and photocopies of others, copyri= ght in particular restricts not only our rights to our property, but t= o our very bodies. Consider the choreographer of a dance who gets the right to stop another from moving his body in a certain fashion. First Amendment rights to freedom of speech also are compromised. A recent court order obtained by factions of the entertainment industry decreed that source code (a computer program) is not protected free speech, and the studios have a righ= t to suppress it. What next? Do we unleash the force of the law against= a devotee who recites computer code on a street corner? It gets worse. You don=EDt have to be guilty of copyright v= iolation to be constrained; doing something that might result in some third party making prohibited copies will suffice. A particularly rank example of prior-restraint legislation is the Audio Home Recording Act of 1992. Manufacturers of digital-recording devices are compelled by law to incorporate technology that prevents copying; they are penalized in anticipation of possible infractions. Manufacturers also are made to pony up royalties in lieu of each device of blank media sold. Ditto for consumers who pay through excise taxes. Patents, however, take the cake. The patent holder can prev= ent others from practicing invention even if, as is quite common, they arrive at the process quite independently. Happen to think of a ne= w way to tune your car engine to get better gas mileage? Better hope someone else does not have a patent on that technique; he could st= op you from twiddling with your own 1967 Mustang in your own garage. Thinking of dashing off a quick software-filing program to streamline your business? Think again. =ECSoftware-driven, multiho= st storage solutions for powering advanced business applications,= =EE are being patented at a furious rate. Stripped of baffle gab, this mou= thful means that for the privilege of filing, albeit electronically, you= will have to pay extortion money to a patent holder. It gets scarier when yo= u consider that 20,000 software patents are issued annually. Price-inflating patent monopolies have grave consequences f= or undeveloped nations, as the latest patent imbroglio unfurling in S= outh Africa suggests. The government of South Africa enacted legislatio= n to allow parallel importing of, and domestic production of, generi= c AIDS drugs to help deal with the AIDS crisis. The multinational pharmaceutical kingpins moved in to enforce their patent monopolie= s, plunging South Africa into a life-and-death battle. South African firms presumably have not stolen their equipm= ent. Neither have they trespassed or broken an entry to obtain the molecular combinations for AZT, 3TC or ddI. These are in the publi= c domain. So why should South Africans be prohibited from making these drugs? Given that it=EDs generally a bad thing, through legislatio= n, to transfer control of property from owner to nonowner, what possibly is the justification for such laws? Most proponents view intellectual property (IP) as a matter= of utility. Without such laws, the argument goes, we would be deprive= d of clever inventions and beautiful works of art. To utilitarians, = the =ECcosts=EE of monopoly privileges, not least the violation of pro= perty rights, are outweighed by their benefits. Utilitarians turn a blind eye to the staggering sums compan= ies spend on the fees of patent attorneys who prepare, file and defend patent applications, mostly for defensive purposes. Litigation cos= ts millions. Mergers between companies often occur for no other reaso= n than to settle patent disputes or to allow the merging parties to compete with a rival with a large patent armory. Submarine patents can emerge at any time, only to sink a high-tech company. The thre= at of patents increases overall business risk and can torpedo margina= l or startup companies. If patents and copyright are essential to innovation, as the mantra goes, how is it that day dawns and the perfume maker who owns no odor-rights still is marketing high-end perfume that can be knocked off? Philosophers persist in writing t= heir tomes, mathematicians toil at solving age-old riddles and physicis= ts don=EDt tire from probing the universe. How does all this creativi= ty continue without the reward of a monopolistic ownership in the ensuing ideas? And why is it fair for the law to protect practical gizmos but not more abstract ideas such as Einstein=EDs equation E=3Dmc2? So far, we=EDve highlighted how intellectual-property right= s interfere with the freedom of others to use their own bodies or th= eir justly acquired property in certain ways. But why should they not = be accorded this right? Why should tangible goods be the proper objec= ts of property rights instead of intangibles such as the ideas IP law= s protect? Here we arrive at the nub of the issue. =ECHe who receives an idea from me,=EE wrote Thomas Jeffers= on, himself an inventor, =ECreceives instruction himself without lesse= ning mine; as he who lights his taper at mine, receives light without darkening me.=EE Jefferson was very definitely not articulating th= e fatuous =ECinformation-wants-to-be-free=EE argument made by the le= ft regarding IP. He was, however, enunciating what is the essence of ownable property. Ownable property is only that which is economically scarce.= And by economic scarcity we mean that, absent clear demarcation, conflict will arise as to who owns the resource. Land, cars, print= ing presses, paper and ink are scarce in the sense that if we remove t= hem from you, you no longer have them. Our use of an item conflicts wi= th your use of it. While an abundance of computers can be had on the market, our use of this particular personal computer excludes your use of it. If we could conjure computers with a genie gesture, the= y would be abundant, not scarce, and it would be immaterial if this = one were removed. However valuable, ideas are not economically scarce: Our listening to a piece of music doesn=EDt conflict with or exclude y= our doing the same. A copy made of a book doesn=EDt remove from its author the configuration of ideas that is the book. Ideas, very pl= ainly, can be jointly consumed without dissipating. Of course, the end product of an idea =F3 to wit, a book or= a compact disc =F3 is very definitely scarce. True to John Locke, we say that if you purchase the book or buy the CD, you are its right= ful sole owner. Proponents of IP, however, say that some distant autho= r or musician partially may colonize your book and CD and tell you how to use them. How do we allay the fear that without patent and copyright = we would all perish? Consider this: How many tears would you shed if Bill Gates were worth only several =F3 not dozens of =F3billions? = Since Microsoft owes a good portion of its wealth to the copyright monopoly, this would be the upshot of its removal. If the company relied only on profits from initial sales and from support service= s, would that be so bad? Being =ECfirst on the market=EE is its own reward. The vari= ous spin-offs and short-term advantages that accrue to innovators who develop new products provide sufficient incentive and profit to re= nder patent protection unnecessary. Removal of patent protection often can accelerate research-and-development efforts. No sooner had Eli Lilly been stripped of its patent protection for Prozac than the company pledged a renewed commitment to innovation. This was reflected in investor confidence and climbing stock prices. Innovators can and do =ECfence=EE their products. As IP sch= olar Tom Palmer points out, concerts and circuses are fenced-in events with =ECtickets sold and checked at the door.=EE There already are assorted blank recording media on the market that scramble signals beyond recognition, making reproduction impossible. Bundling of products is a viable option as are tie-ins: the= se arrangements wed a product to a service. Television broadcasts already are tied to advertising, as are so many other goods. Computer programs are bundled with manuals or service features. The customer would rather purchase the product and get access to free maintenance than resort to copying. Contracts, of course, inherently are free-market friendly. = Unlike IP rights, they are voluntary and bind only parties to the agreeme= nt. There are leasing arrangements, too. Companies can enforce their property rights in the end product of the idea, the tangible good.= They then lend the thing out subject to conditions specified in a contr= act. Patent and copyright clearly undermine private property. A staunch defense of private property must lead to anti-intellectual-property conclusions. [The views expressed in this article are the personal opini= ons of the authors and should not be attributed to any other entity.] Mercer is a free-lance editorial writer based in Seattle and write= s on intellectual property for the National Post and Ideas on Libert= y. Kinsella has written widely on patent law and is vice president specializing in intellectual property at Applied Optoelectronics Inc. in Sugarland, Texas. No: Ownership of ideas and a market system are the only reliable incentives for productivity. By James DeLong A decade ago the topic of intellectual property (IP) =F3 pa= tents on inventions; copyrights on books, music, movies and software; trademarks on brand names; secrets such as formulas for soft drink= s =F3 was a snoozing backwater of the law. Now it is hot! Cool! Ther= e! The driving force behind the obsession is simple: money. Financial markets are dependent on IP. In 1978, the book value of tangible property owned by publicly traded companies equaled 83 percent of the value of these companies=ED stocks and bonds. By 19= 98, this tangible book value was only 31 percent of total value, meani= ng that 69 percent of the total came from IP and good will. (Some of = the market value actually came from moonshine, but 1998 preceded the biggest inflation of the NASDAQ bubble.) Concern about IP is magnified by the Napster software for swapping music over the Internet. It demonstrates the vulnerabilit= y of IP in the digital age and threatens to implode the recording indus= try. Concern, perhaps panic, also is reinforced by ongoing lawsuits ove= r DeCSS, the software that decodes the encryption system that protects movies on DVD disks. With DeCSS rocketing around the Internet, Hollywood fears the worth of any movie put onto a DVD disk will be zero. Consumers should fear this, too, because it would mean no m= ore movies on DVD, but they have not glommed on to this part of the deal yet. Their current reaction to both DeCSS and Napster is: = =ECHey! Free stuff.=EE The obsession with IP is triggering intense debates= at both the micro and the macro levels. At the micro level, the debate jumps around among many topi= cs. Because we do not let people copyright =ECfacts,=EE such as sports= scores or stock quotations, how do we encourage investment in creation of useful databases? Is it legitimate to allow patents on =ECbusiness methods,=EE such as Amazon=EDs one-click method of ordering? How d= o we treat information residing in the head of an employee who leave= s a firm =F3 and should law distinguish between information acquired = =ECon company time=EE and a worker=EDs own creative idea? There are issues of parodies and book reviews and improvements on existing inventions and the doctrine of patent equivalents and a zillion other nuts-and-bolts problems. If all cr= eativity draws on a huge =ECcultural commons,=EE as indeed it does, how do = we decide how much people should be allowed to fence off as their own? At the macro level, discussion is more fundamental: Should = IP be recognized at all? Some analysts of a libertarian bent reject the = basic legitimacy of property rights in the products of the intellect. To= explain why I think they are wrong, it is useful to reprise the thinking b= ehind our recognition of the human right to own and use property. Tough human institutions are like tough trees: They have mu= ltiple roots and draw stability from the combination. The idea of propert= y is one of the toughest of human institutions, existing in all culture= s across the ages, so we would expect to find it supported by a dense root system. A big root is the concept of Lockean justice. Ownership of one=EDs own self and effort is the most basic of human rights. Sin= ce material things are produced when people mix their labor with natu= ral resources, the idea that one owns the fruits of this effort is pow= erful. Accompanying this concept of justice is the pragmatic truth= that ownership creates incentives for productivity. People might garden= for fun, or hunt, dig ditches or write symphonies, but not much. Even = if they wanted to, they would have to make a living, which reduces ti= me and energy available for creativity on the side. Giving the producer a property right in the output of his e= ffort, or letting him earn pay in exchange for producing it, is the only sur= e way to foster these activities, outside of compulsion. Property rights also are important for efficient allocation= of resources. If something is scarce, the best way to ensure that it = is put to its most productive use is to assign it to an owner motivated t= o find this best use. Property rights are a keystone of a complex market system that allocates resources among myriad investment and production possibilities. If society declares that crops belong to= the grower but that petroleum belongs to all in common, it will produc= e too many crops and no oil. If it denies economic returns to IP, it= will invest too little in creating it. Political reasons favor recognizing property. Democracy wor= ks best, and probably only, if citizens are invested in the stability= of the polity and have something to lose if its politics run off the rail= s. Investment in the form of electronic bits or worker know-how will serve as well as land or money. And we have an interest in promoting human autonomy. To the greatest extent possible, people should be free to live their live= s as they damn well please. It is impossible to imagine such freedom except in the context of a society in which ownership of resources liberates people from control by others. Again, intangible resourc= es will do the job as well as material ones. All these bases for endorsing the institution of property a= pply full force to the concept of IP, except for one: the point about alloca= ting scarce resources. A pasture needs an owner. If it is a commons use= d by everyone, it soon will be exhausted and the sheep will starve, followed by their owners. IP is different because many people can use it at once. You= can play a song without interfering with my playing of exactly the sam= e song at the same time. Millions of others can join us, each at his= own device. This also is true of patents =F3 you can copy the design o= f my machine without taking it from me. We can all graze our sheep on t= he same intellectual commons without exhausting it. Or, to paraphrase Thomas Jefferson, you can light your candle from mine without taki= ng my light. This is indeed a powerful difference between physical and intellectual property. It greatly influences analysis of many knot= ty micro issues. But it does not justify total rejection of intellect= ual property because the other roots remain. Lockean justice still demands that I own the product of my = labor. We still need to give people incentives to produce. We still need market signals that people should invest in producing intellectual= as well as physical capital, and we still need the level of the retur= ns to this investment to reflect at least roughly the rate of return to = society. The health of democratic government and the fostering of hu= man autonomy are still served by intellectual property as well as by physical property. Opponents of IP make some additional arguments, but none are satisfactory. One is that creators can protect their = work by contract and do not need the support of property law. But intellectual property must be disclosed to third parties who are n= ot bound, and after that it is loose in the world. This contention also assumes a perfectly functioning legal = system and low transaction costs. Neither is realistic. Besides, to say t= hat a creator has the right to limit disclosure seems to concede the cen= tral point =F3 that he has a right of some sort. Opponents sometimes argue that IP interferes with others= =ED abilities to use their physical properties, as when your copyright= on a book limits my use of my printing press. But so what? Society constantly is resolving conflicts over uses of property, and there= is no reason to say that tangible property automatically trumps intangib= le. Finally, opponents say creativity will find a way and that = products of the mind still will be cranked out even without ownership. This= is partly true, but neither the quantity nor the quality will approac= h that produced by property rights and a market system. Patronage sometimes is cited as an alternative, but to advo= cate reliance on the whims of billionaires and dukes or, worse, the National Endowments or National Public Radio, is an odd position for libertarians. Nor is sponsorship =FD la broadcast TV an answer= . That industry does not sell a product to consumers; instead, it se= lls eyeballs to advertisers, a very different model that results in programming at the lowest common denominator. In =ECfree=EE television, the amount spent on a show for my= viewing is limited to the profit a sponsor can make from selling me a box of detergent, which probably is about 10 cents. As a consumer, I am better off with pay television. Then th= ose of like mind can combine and offer to pay $2 or $100 for a product th= at suits our tastes. It is no accident that The Sopranos, a subtle an= d masterful work, is on pay TV. But this works only if the creator h= as a mechanism for selling to me, which means a property right. Napster partisans are in a comparable situation. Intellectual-property opponents are correct in thinking that music= still will exist, even if it isn=EDt paid for. But it will be from a few= bands that can pack =EDem in on a tour, plus 100,000 versions of the kazoo gr= oup that rehearses in the garage on Saturday because they must hold down real jobs during the week. I prefer Bruce Springsteen, the New York Philharmonic and a plethora of other professional musicians who are paid so that thos= e with the most talent are drawn into the business and then freed to= be devoted full time to music. And I will fight those who, in the nam= e of a misguided concept of liberty, would deny me my right to pay them. DeLong is a senior fellow in the Project on Technology & Innovation at the Competitive Enterprise Institute in Washington. He also is the author of Property Matters. ----------