Extended DRM requirements for content distribution -- 31 Oct 2012

<Shinji> • RRSAgent, draft minutes

Introduction

<inserted> Scribe: naomi

toru: welcome to the DRM requirements
... two goal - about DRM contents
... second is how to proceed to solve the problem
... prepared presentation which contains overview of DRM
... and usecases
... welcome to questions and comments

Kiyoshi: proposor of this session
... motivation of this session is for next IPTV
... services needs a new platform
... expected to use HTML5 browser
... there are discussions EME
... HTML5 WG
... want to clarify the issues of current problems and want to discuss the business situation
... simple DRM issues
... 1. content protection
... has commercial issue like premium contents
... should be important of DRM issue

<Shinji> Main discussion 2 point: Content potation and Copyright protection

Kiyoshi: 2. contents issue
... needs permissions of holder
... EME
... simple way to the content description and workflow
... it's a simple model for the content protection
... exchanged model should cover another extention model
... many issues remains for DRM
... copy right protection
... content package for distributing contents
... but we don't know how to protect the contents
... second, copy control for the multiscreen devices
... such as TV and tablets
... remains how to manage content control
... 3. content protection issue
... special devices like security device
... security issues might be solved by @@@
... usefulness for the content protection

Slides

masayuki: will talk about extended DRM
... three usecases
... Use case 1: multi-keys for package
... music or closed caption or movie
... keys for each contents is important
... all cases contents should be packaged in HTML5
... use case 2: multi-screen - private to private (home use case)
... movable/copyable content from TV/STV to tablet / smart phones
... he/she can enjoy contents using mobiles in everywhere
... smartphone outside

<Shinji> Use case 2 multi-screen (in Home case and Home to Public(outside of the Home))

masayuki: can enjoy contents but some contents should be prohibite
... PUblic to private (signage use case) - premier content from Signage to smart phone
... Use case 3: Dongle as a service portal

<timeless> s/• RRSAgent, draft minutes//

masayuki: Dongle has two interfaces
... important as 00
... basic function of Dongle - Android-based set top box of USB stick size
... GPU and Wi-fi based on SoC
... HDMI and micro USB interface
... USB based power supply (500mA)
... writes software can be on Dongle
... can be use a smartphone as a controller
... unit case in Japan
... NTT has group companies such as DoCoMo
... selling special cell phone like Disney'
... has special contents from Disney

<Shinji> Use case 3: Dongle as a small STB (Android Base, Full HD, HDMI I/F)

masayuki: technical issues
... how to prohibiyt to cache decrypted sub-content?
... how to protect a copyright in case of output to external devices
... how to control functions like fast-forward in playing streaming content

<Shinji> Technical issue (Multi-key, Multi-screen, Dongle(security module))

masayuki: second issue
... Dongle (as asecure device)
... how to define the interface
... before and after pug-in
... EME extensions
... questions?

Questions

kaz: please provide explanation about EME
... additional idea or approach

<timeless> scribe: timeless

adrianba: my question is
... what needs to change
... to EME
... to support Multiple Keys
... we believe it already supports multiple keys
... the diagram already supports multiple key exchanges
... what part do you think is missing?

kaz: EME extension idea
... is already discussed within Media Task force of WebTV IG
... and brought to HTML WG

adrianba: and David and Mark

kaz: they're wondering what should be added to this idea

masayuki: have they already discussed multiple QQ cases

adrianba: here we have generate key request, and key request

[ adrianba walks to screen and points out ]

adrianba: those are two separate key exchanges
... the design of the api supports multiple media key sessions
... and it supports sending data back to the license service
... for negotiating the key
... we support that
... it's the responsibility of the UA, Media Stack, Content Decryption module
... to apply the different keys to different pieces of media
... one key

kiyoshi: in your scope
... ability to do many kinds of cases
... and types of combinations
... not sure what should be done in your discussion

adrianba: there's a set of bugs
... on the specification
... those are the topics we're currently discussing

glenn: have you looked at the EME spec

<ddorwin> Open EME bugs: http://tinyurl.com/7tfambo

glenn: and determined if it will satisfy your needs for multi key
... and if not

shigeo: i'd like to clarify
... this is a problem of extending the spec of EME
... or is this another thing out of scope of EME
... some communication carriers are not satisfied with EME

john: are you saying that the EME spec doesn't provide adequate content protection?

shigeo: DRM system itself isn't the problem
... my general understanding is that DRM is outside of EME
... EME is a kind of interface

adrianba: we're not proposing
... to standardize a DRM system
... in this diagram
... the Content Decryption Module
... encapsulates the way to interface a particular protection system
... to EME
... using EME, you can use whatever content protection mechanism you have available
... it's true that EME doesn't guarantee any particular level of protection
... that's provided by the protection system
... if that's the only part that's missing
... we say that's missing by design
... we're asking
... for the scenarios/UCs listed here
... does the spec address them
... or for the stuff that's missing
... what do we need to add?

shigeo: 2 goals
... DRM/solution
... my question to NTT
... you're saying it's a problem of EME or something else?

toru: our starting point is UCs
... the method
... i'm not sure if it will be EME or not
... I'm aware of EME
... i'd like to discuss UCs
... if the 3 UCs are solved by EME
... then, that's great
... we're asking if EME covers these three UCs

shigeo: can you go back to the UCs?

toru: 1. Packaged contents UCs
... 2. Merged Content UCs
... 3. Dongle model UCs

ddorwin: it seems like a lot of these are Policy or CDM protection capabilities
... which is out of scope
... or interop
... In the final page
... being media stack
... but, each device has a browser+media stack
... there's nothing special there
... protection layer underneath
... application layer owned by you

Shinji: technical issues
... Merged Packaged Content
... we can get license include key
... secure model
... browser extension DRM can separate
... we are afraid to
... interface of web browser and DRM
... we'd rather make a tamper resistant thing in the Dongle
... i'm not sure about EME issue
... we think EME may be hard to solve these problems
... we want to discuss
... tomorrow, friday
... to talk in more detail on
... Dongle for tamper resistence

glenn: if i understand correctly
... you're concerned about
... how content
... is processed and stored and further transmitted
... after it is already in the browser implementation
... while it's an issue in the big picture for DRM as a system
... it isn't exposed to the application content/JS/authors directly
... it's an implementation issue for the Browser/CDM module
... which is outside the scope of the EME activity
... they define CDM as an abstraction
... not concretely
... my question is
... to what extent is the issue you're discussing in scope for W3C as a standards body
... W3C traditionally doesn't get into the implementation details of browsers
... what a browser does later is up to the browser
... it's within the browser/after it gets to the browser

markw: Mark Watson, Netflix
... some of these are out of scope for EME
... not just because they're out of scope for EME
... we let the CDM exchange data with the server side DRM
... you add a key, the message exchange can have anything it want
... whether output protection should be engaged, or whatever
... i think a lot of the things you're asking for are functional requirements on the CDM
... take them to the DRM vendors
... one thing i'd say about transferring content from one device to another
... you have 2 options
... transfer in encrypted form
... and have the EME operate on the target form
... or you can have a device where the browser decrypts
... and then some other scheme is applied to transfer to the other display
... and then it's up to that other scheme to deal with it
... communication between devices before they're decrypted by EME

Kiyoshi: this highlighted module

[ EME extensions slide ]

Kiyoshi: if you say this is already covered in EME discussion
... we must study more
... if you have additional comments on UCs
... or additional UCs
... or additional discussion points
... please let us know

glenn: UCs of multiple key exchange is clearly in scope for EME
... output control, second screen mode, sharing
... is below CDM --- out of scope
... as EME is currently defined
... no one in W3C has proposed attempting to standardize interface between UA and CDM

Kiyoshi: we think of output control
... UC is very sensitive
... after decryption image/audio
... is distributed
... this is very dangerous point for content
... we want to talk about this

glenn: if a UA/browser
... wants to work with something
... then they'll need to be certified with that vendor
... that's outside the scope of EME

john: i was going to say something similar to glenn
... DRM has rules for protecting content
... treatment of output, etc.
... that's within scope of DRM system
... one DRM system might have higher robustness rules
... different ways of expressing output protections
... as markw was describing
... EME was designed to be able to talk to different DRMs
... in an interoperable way
... so it's opaque to the application
... but the security of the system is based on the security of the CDM
... the security concerns
... should be brought to the DRM provider
... you can say you like EME
... but express concern about CDM

Toru: what kind of place would be suitable for discussing this issue?
... we need to add some functionality to discuss second screen
... where should we go?

glenn: ITU

[ laughter ]

Masahito: assuming EME is the standard platform
... is EME the platform?

<kaz> s/HH:/masahito:/

Masahito: we may need something in addition to this
... "Is EME _the_ framework?"

john: i think there are multiple UCs here
... i think each UC
... a JS app, would it have to behave differently to realize a UC?
... if it would have to
... as adrianba asked, what can you not do today?
... if it's something that can't be done today
... then talking to EME is the right place
... but some UCs, like Dongle
... strike me as not web-specific
... they're talking about a DRM tech
... i don't see it, personally, as a web question
... as a DRM tech choice
... if i had a dongle based DRM tech
... i could develop a CDM
... and the CDM would be used by EME
... and that's how the dongle would be used by EME
... but that wouldn't require changes to EME
... imagine i have a DRM system that uses a Secure Processor
... i have the same DRM system on another device w/o Secure Processor
... the difference is transparent to the EME interface
... logically, in an abstract sense, the dongle is like a secure processor
... i'd argue, that it'd be disadvantageous to allow the hardware architecture of the DRM
... to dictate specifics of the EME interface
... it'd be disadvantageous to allow that to surface to the EME interface

adrianba: to extend what john said
... EME is designed to provide the interfaces to facilitate communication between the DRM platform and the License Service
... for the same DRM system, different deployments will want to use different methods of communication to the license service
... EME supports that
... question i'd like to ask before "is there some place to go to ask your questions"
... is: go through the UCs using EME
... and give us feedback
... "we can do 99% of the UCs using EME"
... "but we can't do this"
... if the piece you can't do,
... then maybe there's a need to be discussed in Web&TV IG
... at W3C
... which collected our Requirements
... if there were requirements that were missed
... then i'd recommend that as the venue to continue the discussion
... i'd request you understand scope of EME
... and understand your scenario
... to see how they're addressed
... keeping in mind what john, ddorwin, markw said
... that the DRM is out of scope

masayuki: i agree with
... the part that dongle being a physical thing
... connected/disconnected
... Is there a more discussion point
... to make a best use of physical item?

adrianba: i think john addressed some of your question
... I'd say, how you determine if the hardware device is physically connected or not
... is within scope of CDM and interface to platform
... it's out of scope for work we're doing @W3C
... one thing you mind come back to us with
... is "there's a set of errors that can be communicated to the App via the EME spec"
... "to indicate why there's a failure"
... a failure reason may be "hardware device isn't physically present"
... feedback you could provide is "it's not very easy to build an application to clearly communicate to the that that's the specific problem"
... so we want to improve the failure reporting from EME
... that's an example

toru: thank you very much

[ applause ]

masahito: i'm a CoChair of Web&TV IG
... it'd make sense for us to re-review what we had and the EME proposal
... thank you

<kaz> [ adjourned ]

s|s/FF/Kiyoshi:/||

trackbot, end meeting

trackbot, bye

s|s/FF/Kiyoshi:/x||

- DRAFT -

Extended DRM requirements for content distribution

31 Oct 2012

Attendees

Contents

Introduction

Slides

Questions

Summary of Action Items

Scribe.perl diagnostic output