[Minutes Overview] [Workshop Home] [Previous:Architecture/Infrastructure] [Next:Critics]
Please refer to the position-papers and slides for authoritative answers. The following minutes are only a snapshot of Presentations and Discussions
See also the [Slides (ppt)] and the Position Paper
DRM (Digital Rights Management) is a much used and abused - term. DRM
refers to those technologies which have been specifically developed for
managing digital rights. We prefer the term digital trading platforms
.
And we prefer the term users
to customers
. We have the concept
of fluid malleable content moving from computer to computer.
An organization setting up DRM needs to consider:
Licensing by its very nature is complex. Organisations and their business processes do not remain static. Solutions should not place restrictions on the licensing process, which is the embodiment of a business process. Organisations need to update & incorporate new licensing requirements when necessary. One can express rights in XML, but the trick is turning those rights from one situation to another.
How to users access your content? Content is in many forms, you package and protect it, deliver to many devices and platforms (CDS, mobile phones, computers, etc).
There is more than one encryption technology available. Encryption independence can provide organisations with the flexibility they require. Content can then be secured for different client platforms using different encryption technologies. One should use the appropriate form of encryption for the form of licensing you want to use.
Meanwhile there are currently a range of incompatible DRM technologies. Organisations change and DRM will get hacked, can be none stable. Different types of content need to be secured Users (and publishers) must be assured that they're not buying (into) the Betamax model!
DRM should be able to protect any type of content. It should be able to enforce IPR using original file formats: Is this possible? Yes! Give the user the choice of their player/reader (within the constraints of the publisher's T's & C's)
Trust is essential in e-commerce. Say it is you, prove it is you using POK (Proof of Knowledge), smart cards and biometrics. DRM should work with or in parallel with these technologies
Encryption is not always possible or required. Watermarks work in some contexts, you don't always need encryption, e.g., SDMI (Secure Digital Music Initiative). Watermarking and similar technology provides traceability outside of the DRM domain
There is also a need for flexible payment methods. There are many systems, like credit cards, info trade, online currencies. Authentication is also needed. Users may use different payment methods at different times.
DRM is not an island -- organizations already have many computer system elements in place and don't want to change them in the face of adding DRM, They want to integrate with current infrastructure. DRM should enable rapid publishing of secure content. It should not be prescriptive outside of its own domain.
This leads to the following model:
A further requirement is the ease of use
, which is considered
important. DRM should be easy to use and easy to implement, for both, user and
publisher. Access to the information should be easy, but remain secure. All
this should not lead to prohibitive prices. A solution should be scalable to
be able to run on systems like Amazon and Yahoo. Finally, a system should be
adaptable to changes as DRM, encryption, payment and e-commerce technologies
come and go.
See also the [Slides (ppt)] and the Position Paper
Iverson said, that W3C's opportunity in DRM would be to develop a DRM-Language and vocabulary. This language would be the basis of a framework focused on interoperability, a horizontal framework that is open. He put forward the following requirements:
What the market doesn't want is the creation of one single comprehensible DRM-Standard.
When we say preserve the users' rights
, we mean: Individuals have
the right to freely build, distribute and manage their own creations &
collections. Individuals have the right to annotate, configure, comment upon
& criticize the works of others. This can constitute the creation of new
works worthy of the same status as the original work. And, this can be
accomplished by a persistent reference, so that the rights of both creators
are respected.
Amateur or Professional: Copyright law makes no distinction, and individuals
will demand equal footing. An interoperable Digital Item/Manifest scheme is a
key mechanism for accomplishing this.
There is a lot of work on persistent Digital Item/Manifests: W3C XML
packaging called for a manifest format, MPEG-21 has produced a draft on
Digital Item Declaration
. These and other concepts and initiatives have
significant overlap. Take MP3 as an example: metadata, some is in the file,
some is not (you have the ID3 but also need digest
and
signature
).
Iverson showed a digital items structure represented as a file-directory
tree, but pointed out that not all structure is well represented in the
directory. Notes that items have multiple representations, that they are not
static. Things need to be configurable. So you end up with complex item, with
sub-items, and this is the thing you want to annotate. You want to package
that complex object in a form that an agent
can deal with. This is what
a digital item declaration does, in XML. There ought to be one digital item
declaration, that is interoperable. If you derive/create a new work, that
builds on the old, the reference to the manifest for the first item is
included. MPEG could use DOI identifiers as references.
The requirements for the declaration have been set in W3C XML Packaging. For more on the digital item concept, look at the MPEG web site in the MPEG-21 section. ONIX has something like this, stipulated for hard goods. MPEG-21 has a requirement to have a manifest.
See also the [Slides (ppt)] and the Position Paper
Mooney presented on the DOI-EB (DOI for eBooks), on challenges to interoperability, which it presents. DOI-EB is part of the work of International DOI Foundation.
He called the term eBook a misnomer, a marketing term. It is not really an
analog to a paper book. Should say e-publication.
Better: a
monographic work in electronic form.
Remarks on selling vs licensing. Mooney made various points, one key one was: if you encrypt, it is less like a sale and more like a license.
AAP (American Association of Publishers) had ordered a study from Accenture
(former Anderson Consulting) on DRM. The AAP report treats interoperability,
defined as the condition achieved when two or more technology systems can
exchange works in a way satisfactory to both systems.
But the providers of
DRM technology may be reluctant to adopt standards because this may be viewed
as weakening patent rights. Still, the AAP did set out an interoperability
requirements.
Mooney compared this effort to the EBX (eBook eXchange) interoperability
goal: read any eBook from any publisher on any device.
. There are diff
EBX client and server implementations. The required design is so that a server
from one vendor can authenticate a client from another vendor. Also
distribution, transfer protocols and the format of Vouchers and Credentials
are standardized to ensure interoperability. But so far technology providers
fail to see business value in this set of goals.
The presentation was concluded by the question, whether there is a form of interoperability that is not threatening. Mooney thought that the answer is interoperable metadata, including rights info. But there is no standardized language for metadata yet and we need one.
Digital object architecture can be compared in ways to traditional library paper items. The system is a resolution system for resource discovery, repository/collections. It is only a resolution system. Handles can also resolve to typed data (a la MIME types). The Types are extensible and it is expected that type registries exist (repository access protocol). There are two possible query-types: Given a handle,
There is no limit on the size of the data, but an assumption that the system will be write-occasionally but read-often.
The Handle System is a collection of handle services in a two-level hierarchy: One service (at the top of the hierarchy) is known as theglobal handle service. A handle service consists of one or more replicated sites, each of which may have one or more servers.
The generic handle resolution follows this schema:
DRM as far as I can see the talks here is talking about expressions syntax semantics enforcement protection detection action
In all of these, it may be one vs many, i.e., more than one syntax. You
also have national law considerations. This complexity of topic made me think
in terms of a continuum: what action should W3C take, where on the continuum?
W3C should:
ignore the topic
own the problem
discuss it
Question: How big is the handle namespace?
Answer: It is controled by global, non-semantic identifier to avoid naming issues
Craig Schutz (Access Ticket): In the Intel system, does XML info travel with the data? As the content moves, description can change or can be annotated, configured. Things can be added/removed and it ultimately lands on consumer device, and has value on this device
Rob Koenen: You have unique identifiers that help
Answer: The info can be encapsulated with content, or sent independently
Question: What about security ?
Answer:It can be encrypted, signed etc.
Question: Is the file readable by anyone on any system ?
Answer:Given a piece of content available in four languages: If a manifest moves into particular region where only two languages are available, other options are removed, i.e. the manifest is rewritten. The concern that you will see things that you don't want to see can be dealt with by reconfiguration
Question: Are there access rights issues? Or is it only information about an asset.
Answer: Stuff that is put inside is supposed to be descriptive information. You can form description scheme that is encrypted and put it inside and sign the whole thing
Question: This is very closely related to to the
meta-container concept that I think Renato Iannella addressed. It is a
XML-based wrapper.
The useful transformations described beforehand are exactly what caching proxy
people are doing in the IETF/extensible caching services. You described a
particular format, that people find useful. How does that map onto questions
that we are trying to answer in this workshop ? Could you address the role of
package formats in this area ?
Answer: Package is an overloaded term. I prefer manifest. Scott Foshee talked about differences between atomic items and aggregated. You can't think in an atomic world to solve the issue at hand. W3C has slipped into thinking that everything is a document. What this thing is trying to do is to create concept of digital item that can contain other items. I wanted to address question whether this isn't simply RDF packaging. There are semantics here that RDF can't address. What we're doing is saying that these are the semantics - doesn't matter how it is represented (XML Schema, RDF, MPEG-21)
Renato Iannella: Sequencing learning objects, that's actually intellectual property. Having a manifest for this would be very important.
Note: People who are doing legal descriptive labels are the rights owners. There is no a way of ensuring the accuracy of these description, e.g. copyright that never ends. We don't know how to combine rights in document consisting of several different media/composite work. If I want to reproduce a single image, who do I contact ?
Vaughn Iverson (Intel): At each level, the information has to be completely unambigious. E.g. this photograph has been taken by this person, these rights are controlled by that person. Anybody in the distribution chain needs to be able to discover (know) this
Question: How do you address changes in status, e.g. Reed-Elsevier purchases other company
Answer: This is not something that the description scheme deals with.
Vaughn Iverson (Intel): What if things happen in the digital space, if things happen, that individuals don't like, if jurisdiction can change? What happens then ?
Godfrey Rust (<indecs>): I remember, when in the UK legislation on copyright changed. Suddenly some recordings came back in copyright. How do you know that it is now 70 years after death of the creator? This was a nightmare to figure out, what is protected and what isn't. How will updating work? That's why we introduced automation. We identified a need for precise identification of items.
Melissa Smith-Levine (Library of Congress): As an example, we accumulate in an archive, say, web sites. There is a real problem of the accuracy of the information we collect which will govern what we can do later.
Question: Knowing what representation is accurate, and what changes over time is really challenging.
Answer: One of the central EBX goals was to enable the
paradigme: when I buy a book i can read it
. This should count no matter
I buy it from a publisher or from somebody second hand.
IFPI: In the end, the consumer decides whether they want to accept the model. With different DRMs that are not interoperable, consumer are forced to install several systems. We want interoperability of DRMs and content so that consumer gets best experience with least effort.
Answer: The Discussion of content formats may be orthogonal to DRM discussion.
Charles Myers (Adobe): DRM is an underlying technology that should be applicable to any format. The market place should figure out what format is best. It is not our job to figure out the format.
Rob Koenen (MPEG): when you talk about interoperability, you also need to deal with format.
Jonathan D. Hahn: (Versaware) DRM format may not be a precise term.
Vaughn Iverson (Intel):If you spent 4 hours surfing you agreed to more binding legal agreements, than somebody a hundred years ago agreed to in a lifetime. DRM needs to be dirt-simple, consumers need to understand what they agree to. It can't be too complex.
Note: You want to read the content, not the license.
Danny Weitzner (W3C): On the formats discussion: Several levels of indirection above chosing a single format. We are more talking about interoperability of DRM.
See the process-document for more information.
[Minutes Overview] [Workshop Home] [Previous:Architecture/Infrastructure] [Next:Critics]
Created by Rigo Wenning February 2001
Last update $Date: 2001/05/17 17:39:51 $ by $Author: rigo $