telecom companies,
a content provider,
device vendors,
publishers,
software vendors,
standardization organizations,
Web application providers
researchers,
the Japanese Government.
Please see the
the top of the minutes for the detail.
During the workshop, we had very interesting demonstrations of actual
digital TV services by Japanese public and commercial broadcasters,
and six panel sessions consisting of brief presentations of the
attendees' position statements followed by dedicated discussions on
use cases and requirements for smarter integration of Web and TV.
The topics for the panel sessions were:
Existing Digital TV approaches
Proposals for smarter integration of Web and TV from vendors' viewpoints
Proposals for smarter integration of Web and TV from research viewpoints
The role of HTML5 in the Web on TV, esp. expectation for HTML5 as UI
The role of HTML5 in the Web on TV, esp. TV as the hub within home network
The role of HTML5 in the Web on TV, esp. Device APIs for TV
During the afternoon break on the second day, we held a vote on use
cases and requirements proposed at the workshop so that we could
prioritize them and identify potential new languages and language
extensions.
One representative from each participating organization was chosen and
voted on their preferred use cases and requirements using five points.
The top 9 categories of the use cases and requirements, roughly in
order from most interest to least, were:
APIs for TV functions: 41 points
Richer user experience: 37 points
Smarter integration with CE (Consumer Electronics): 32 points
Content rights: 12 points
Personalization: 8 points
TV as broadcasting service (rather than a device): 8 points
Accessibility: 7 points
Relationship with existing approaches: 7 points
Security: 4 points
for the detail of
the vote results.
During the summarization session, we discussed the possible next steps
about how to deal with the above use cases and requirements, and the
conclusion from the session includes the following:
There was a consensus to create an Interest Group to discuss the
details of the use cases and requirements presented during the
The time frame for the expected group is by the end of the year
(=Christmas).
Yosuke Funahashi from Tomo-Digi and Masahito Kawamori from NTT
volunteered to be the co-Chairs for the Interest Group.
HyeonJae Lee from LG also expressed his interest in being a co-Chair
for the group.
Charles McCathieNevile from Opera volunteered to help them generate
a draft charter for the group.
Kazuyuki Ashimura from W3C will help them as the W3C staff contact.
We will soon create a mailinglist for detailed discussion on the
details of the next steps, e.g., how to form the proposed Interest
All the workshop attendees are encouraged to join the W3C and
participate in the proposed Interest Group.
The above mailing list for the discussion on the next steps
has been created as a public list,
To subscribe to the list, send an email to
with the word "subscribe" in the subject line.
for the list is accessible on-line.
The subscribers of the list will review the use cases and requirements
presented during the workshop and discuss how to form the proposed
Interest Group.
Note that the possibility of creating a Working Group rather than a
Interest Group for the expected requirements is not excluded even
though the consensus during the workshop was to initiate the efforts
with an Interest Group.
are also available on the W3C Web server.
Workshop Organizing Committee
$Id: summary.html,v 1.21
19:15:20 ashimura Exp $扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
6th Pre-ICIS SIGHCI Workshop Summary
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口Amazon CAPTCHA
请输入您在这个图片中看到的字符：
& , , Inc. or its affiliatesDRM-Workshop Summary Report
[] [Minutes]
W3C Workshop on Digital Rights Management for the Web
22-23 January 2001
Workshop Report
, Hewlett-Packard
Laboratories, IPR Systems
Created: 19 March 2001 Updated: 17 May 2001
The W3C Digital Rights Management (DRM) Workshop, held on 22-23 January
2001, brought together 65 leading DRM practitioners to discuss and debate DRM
in general and what role W3C should take in this increasingly important area.
From the 41 position papers submitted, the program committee chose 25 formal
presentations covering areas such as Privacy, Identifiers, Architectures,
Social and Legal Requirements, Publishers Requirements, Standards and
Interoperability, Security and Trust, and Multimedia and Mobile issues. Each
session was followed by open and vigorous discussion.
There was some agreement that W3C should initiate a new activity in this
area and there were a number of specific topics that were discussed as
candidates. A topic of specific interest was the creation of a 'rights
language'. The MPEG standards group is also looking into this, and proposed
that W3C and MPEG form a joint alliance and to work on this problem together.
Additionally, there was some objection against W3C involvement in the area of
DRM. Some felt that W3C lacked the necessary types of members, like content
owners, and experience in semantic and legal issues. Their view was that W3C
should only play a liaison role.
W3C will now take these recommendations and discuss it internally before
making any formal decisions.
all the Position Papers from the Attendees and the Program including the
and the . At the closing
session, there was a brainstorming going on, which was condensed to a bullet-list. This bullet-list doesn't contain any indication on the
amount of support on each point. It is provided as a result of strong feedback
from participants.
Workshop Key Points
The key points raised at the Workshop included:
Definitions
During the discussion, multiple definitions of DRM occurred. DRM needs
a consistent definition that takes the focus away from the current
security/encryption/enforcement views. This is also necessary to acquire
a realistic scope for the work to undertake.
There were a considerable amount of voices requiring, that a system
should work offline as online: DRM must be about the "digital management
of rights" not the "management of digital rights".
DRM is also processing personal information. It needs to treat
consumer as a "first-class" object. That is, a consumer's profile have
access usage conditions, and other (user-) rights linked to it.
The default legal rule is "free flow of information". So the
"rule-of-thumb" is to support this
and to make it easy for users to act
lawfully in case of restrictions to the default.
Accessibility
It is a human right to access the information you need. This principle
implies that humans with disabilities that require the use of additional
tools to access information should not be disadvantaged by any DRM
technology. Often access-technologies and their technology are seen as
an attack to the content, thus preventing e.g. screen readers to access
this content. The access points needed for access-technology should be
provided to enable fair access to all content.
Access to information is regarded as paramount
and the rights of
originators, publishers, consumers, and corporations need to work in
balance. There was consensus that DRM should not prevent Libraries and
other cultural institutions from continuing to collect and preserve
World's knowledge and digital artifacts. This balance can be seen to be
working for physical artefact, but this will be harder to determine with
new technology. There is some anxiety that the current balance may be
off and that actual privileges (like those of Libraries) are not
supported in such a system. This aspect hasn't been discussed broadly
until now.
Publishers
Machines are "users" too and need DRM services. There was some
concern, that DRM with lacking interoperability will raise the
transformation costs. Most publishers reported, that DRM should serve in
a first step to provide a metadata system to identify rights and link
them to a rightsholder thus giving them a better overview of their
To learn about DRM issues use "simulated interoperability".
Architecture
Interoperability is a key DRM requirement (see discussion below)
A digital Rights Language is seen as a good first step for DRM
standardisation (see discussion below).
DRM needs a Trust Infrastructure (see discussion below).
Multimedia
MPEG is addressing DRM needs and W3C should work closely with them. If
W3C would start an activity in this area, there must be a formal liaison
Identifiers
The identification of content is a critical requirement for DRM
systems. There are numerous identification systems available for
specific content communities and many are also incompatible. DRM
demands that identifiers be unique, persistent, and resolvable and
there was some tension around the best solution. While there was
suggestion for a system using a special repository, others stated,
that identifying of objects could be done with the current URI-System.
Currently there is no single system that can provide all needed
features for all sectors. MPEG is currently addressing this issue with
the Digital Item Identification and Description.
DRM Interoperability
Some participants presented a shared architectural model or abstract
framework they claim is required, if only for people to fully understand the
depth and breadth of the rights management arena. The position papers
concerning this subject
they considered a layered,
abstract model that consisting of policy expression, transmission,
interpretation/enforcement, and thus introduced "multiple" levels of
well-defined interoperability.
These framework papers are of most concern to DRM. When asked, most
participants defined "interoperability" as what we have called "format-level
interoperability" - the ability of a DRM mechanism to
successfully interpret
a package from an alien mechanism. Few speakers discussed other levels of
interoperability, and when they did they referred to this as "simulated
interoperability" (a term borrowed from the AAP/Anderson Consulting
report on eBooks and DRM).
In our current thinking, rights Interoperability mirrors the three
suggested levels of data interoperability, including: syntax, objects, and
semantics. Base-level syntax (eg XML) and vocabulary primitives populate the
complex schema definitions for a variety of useful objects for
rights messaging occurs the semantics of using these
objects in various rights Applications are defined in the top layer, including
tying primitive language elements used for enforcement to specific hardware or
software components.
MPEG's presentation of their MPEG-21 "Digital Item Declaration Model"
proposal, which goes beyond DRM, suggests another pathway to interoperability,
which is consistent with a call for a higher-level framework. It is important
for W3C to be engaged in that activity, while working toward a framework
DRM Languages
It is clear that user domains (eg eBook trading, sub-rights trading,
streaming music, etc.) each require sets of Rights Primitives that those
domains wish do useful things with. Although people often conceptualize and
refer to these primitives as "rights languages", what they are in fact
referring to are "rights data dictionaries".
This is because the interested
parties generally want the declared vocabulary primitives to be bound to some
some human-readable definition (or "semantic").
MPEG has recently re-issued a Call
for Requirements for a Rights Data Dictionary and a Rights Expression
Language. This is consistent with the above view of rights primitives being
defined in a dictionary and the Rights Expression Language being a mechanism
for the transmission of these semantics. Representatives from MPEG have made
an invitation to W3C to form a
joint working group to address this issue.
This is an very important step for the entire DRM community that
respond to.
Trust Infrastructure
To summarize a few concerns about Trust infrastructures from the
What will "it" look like?
Who should manage trust?
How will trust be "interoperable?
What are the social/legal issues (eg liability)?
How to deal with trusted components (hardware/software)?
Most participants believe that not only must there be a trust
infrastructure upon which applications (commerce and otherwise)
they imagine that there will actually be several, providing different
value-added trust services. The trust concerns expressed tended to be more
practical - for example, who will run these authoritative trust services?
Private companies? Governments? Industry organizations (.g publishers
associations, authors' collectives, etc)?
If there are multiple, parallel trust infrastructures, who will create and
manage the "directories" that will enable interoperation? Or will these "trust
backbones" take a form where this is unnecessary - where the semantics of the
certifications are obvious? Regardless of how it is built, there is concern
over liability - who is liable for a failed "chain of trust?"
But the issue of PKI and trust-structures is not a special case of DRM.
E-Commerce and all kinds of services in the digital world depend on trust
structures. Trust-structures are actually such a big task, that they should be
considered outside a DRM-Activity. A Rights Language and an architectural
model shall be able to connect to the Trust-Systems developed elsewhere (IETF,
ETSI, CEN).
Related Activities
Rights management covers a broad technical space, so obviously there are
several consortia hosting activities that will influence the field. The
following is a short list:
MPEG-4: IPMP (Intellectual Property Management and Protection)
MPEG-7 Multimedia Description Schemes and Systems Layer
MPEG-21 Digital Item Identification and Description
W3C: XML-signatures, XML-encryption, XML-protocol
W3C: RDF, DAML and other "Semantic Web" projects
OpenEBook Forum: Previous EBX work on trust infrastructure and current
"Rights & Rules WG"
&indecs&-Framework, DOI, ONIX
None of these activities solves the rights management interoperability and
standardization problem, but each *suggests* a piece of the solution. For
example, MPEG-4 IPMP may come close to standardizing DRM APIs, but doesn't
treat many other aspects of the problem (such as rights vocabularies, etc). In
particular, none of these deals with what we think of as the essential first
step for the Web: the simple expression and communication of IPR information
and policies. However, some efforts have commenced to develop
rights languages (e.g. ODRL and XrML)
As some of the position papers pointed out, the role of the W3C can be to
recommend a framework or generalized architecture model that stitches this
world together. It is the responsibility of those who think this way to
provide leadership, to recommend more specifically how this can be done.
Next Steps
There were opinions voicing, that the W3C is the best existing forum to
define a forward-looking Framework. There was also concern that this may not
be as clear to the broader W3C. Rights management presents a broad set of
problems. , and a "Web-is-Everything and Everything-is-the-Web" view, if
present, would surely generate conflicts in process and politics. Note that
the same could be said of MPEG processes and politics (for example); such is
the nature of the digital, networked environment. Most comments did not want
to see the scope limited to the Web.
The creation of a "Rights Management Framework," would need a setup with
work split between a small number of specialized WG's, and a larger number of
formal links to related efforts: within W3C, MPEG, IETF, OpenEBook,
&indecs& and Industry.
The Framework WG, as a Coordination Group would in part be responsible for
mapping the relevance of these related efforts into the Framework and
recommending integration best practice.
The Rights Management Framework
would provide the context for other efforts and help to
disagreement and misunderstanding on the scope of the specialized WGs.
The specialized WG's - possibly just one, but perhaps several - would
address individual missing pieces, such as a rights expression language -
while some will see this as essentially a set of rights primitives with
agreed-upon semantics (eg a rights data dictionary mapped onto an XML Schema),
others will see this as including object definitions. Both interpretations are
correct, but at different levels.
Overall, the DRM Workshop can only be classified as an overwhelming
success. The enthusiastic support from the attendees and the desire to move
forward in addressing DRM issues can only be a win-win situation for all
concerned.
Last update $Date:
16:41:16 $ by $Author: rigo $}