[IETF-IDRM] Fwd: Re: [IDRM] DRM Taxonomy work -- drm framework...

[Thomas Hardjono]

>Date: Sat, 19 May 2001 15:17:51 -0400
>From: Thomas Hardjono <thardjono@mediaone.net>
>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: <mailto:ietf-idrm-help@lists.elistx.com>
>List-Post: <mailto:ietf-idrm@lists.elistx.com>
>List-Subscribe: <mailto:ietf-idrm-request@lists.elistx.com?body=subscribe>
>List-Unsubscribe: <mailto:ietf-idrm-request@lists.elistx.com?body=unsubscribe>
>List-Archive: <http://lists.elistx.com/archives/ietf-idrm>
>List-Help: <http://lists.elistx.com/elists/admin_email.shtml>,
>  <mailto:ietf-idrm-request@lists.elistx.com?body=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
>------