RE: [NEW] Media Task Force Wiki

Thanks for restating the problem. That is exactly what I intend.
The immediate playback is supported but just persisting or removal without viewing is not supported (those will work as the functionality in any key systems but need unnecessary crypto operation depending on the key systems).
I'm looking forward to the usecases updated.

From: Joe Steele [mailto:steele@adobe.com]
Sent: Wednesday, June 11, 2014 5:04 PM
To: Maruyama, Shinya; David Dorwin
Cc: <public-html-media@w3.org>
Subject: RE: [NEW] Media Task Force Wiki


Let me restate the problem I think you are referring to.



I believe you are saying that supporting the "Persisted/Offline" use case requires that the licenses downloaded are protected in some cryptographic manner?



The downloaded keys should be cryptographically bound to the licenses and the policies they include (if any). This is a natural requirement when acquiring the keys. However some license delivery protocols rely on encrypting the channel e.g. HTTPS. In those cases, the CDM will have to apply additional protections to the acquired license when saving, to avoid the keys being exposed on the users system and the binding between keys and policies being broken. I believe CDMs which cannot apply these protections should not support this use case. This problem is outside the scope of EME though.



It is a little confusing that the use case says "Supported". I believe the intent here was to say that the EME spec supports this use case, not that supporting this use case is required for any particular UA/CDM combination. David - correct me if I am wrong here.



I am trying to update the use cases now without confusing things even more. I will clarify this point.



Joe



________________________________
From: Maruyama, Shinya <Shinya.Maruyama@jp.sony.com<mailto:Shinya.Maruyama@jp.sony.com>>
Sent: Monday, June 2, 2014 6:02 PM
To: David Dorwin
Cc: <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: RE: [NEW] Media Task Force Wiki

I assume the DRM which requires two step cryptographic operations:

1: Acquire the license via the secure channel requiring cryptographic operations
   - the license obtained from the protocol is already protected in DRM specific way to be persisted as-is (No additional protection for the robustness is needed)
i.e. content key in the license are already encrypted/signed with the provisioned key (device key, user key etc) by server side
2: Validate the acquired license to make content keys usable for playback
   - verify the signature of the license with using provisioned key
   - decrypt the encrypted content keys with using provisioned key

Currently these two steps need to be done all at once within the update() method where the license is acquired.
Therefore, when supporting the usecases below unnecessary crypto operations would be needed for step-2:
Case-1: user just wants to acquire the license without viewing (step-2 above is not needed)
Case-2: user just wants to remove the persisted license without viewing (step-2 above is not needed)

I understand some DRM support making the keys usable by the one step (content keys are immediately made available by the step-1 above).
But even in the DRM, when license including decrypted keys is persisted, I think CDM need to protect the license in some robustness way requiring crypto operations. This would be a sort of step-2 above after license is persisted. The Case-1 might not be a problem for this kind of DRMs but case-2 would be a problem for the DRMs in general.


From: David Dorwin [mailto:ddorwin@google.com]
Sent: Tuesday, June 03, 2014 8:47 AM
To: Maruyama, Shinya
Cc: <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: Re: [NEW] Media Task Force Wiki

Yes, #2 supports that model. It's also possible that the license will be persisted and used for immediate playback. For example, the user might start watching while the movie downloads in the background.

Can you provide more details on an implementation for which this would be a problem? Wouldn't expensive cryptographic operations have already been initiated to generate the license request?

David

On Wed, May 21, 2014 at 11:34 PM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com<mailto:Shinya.Maruyama@jp.sony.com>> wrote:
Additional questions.

The Application models #2 seems like the 'to-go' use case where license is acquired just to persist for later use.
In the persisting step, it would be better to suppress making keys available because it requires cryptographic operations but it's not possible because the algorithm of createSession does not specify that way (persisting license(s) always happens in conjunction with deriving keys).

I'm not sure if I understand the intent of the application model #2 but I wonder if some implementer might want to support the case above.

Thanks,
Shinya

From: Maruyama, Shinya [mailto:Shinya.Maruyama@jp.sony.com<mailto:Shinya.Maruyama@jp.sony.com>]
Sent: Monday, May 19, 2014 2:55 PM
To: David Dorwin; Joe Steele
Cc: <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: RE: [NEW] Media Task Force Wiki

Thank you for adding use cases and application models.
They looks like great step in order to proceed to discussions for several open/pending issues.

Looking through the use cases, I just have a question whether we should have a separate use case of removing persisted license.
Removal of the license is mentioned in Application Models #2 but it is the use case where the license is removed with/after viewing the content.

Assuming the case of removing the persisted license without viewing, it might be better to support just loading license as separate step from making keys available, which requires cryptographic operations.

If we support this use case, a possible option is, for example, to add a separate method 'run()' to run the session;
- loadSession() just load persisted licenses
- run() make keys available to content decryption
- remove() can be called before run()

Thanks,
Shinya

From: David Dorwin [mailto:ddorwin@google.com]
Sent: Wednesday, May 14, 2014 11:32 AM
To: Joe Steele
Cc: <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: Re: [NEW] Media Task Force Wiki

As I said I would do in the telecon this morning, I documented the primary application models on the wiki. Since the Media_Task_Force wiki may eventually have other EME and non-EME information, I created a separate page for the EME use cases: https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases. I left the existing use cases as is, but they should probably be moved to the new page. (I believe the first two are covered by the first application model.)

David

On Tue, Apr 22, 2014 at 8:10 AM, Joe Steele <steele@adobe.com<mailto:steele@adobe.com>> wrote:
We setup a new wiki page to capture use cases, external references and other useful information: https://www.w3.org/wiki/HTML/Media_Task_Force

David pointed out on the call this morning this may have been automatically archived by folks as it was part of the last minutes email.

The goal is to list use cases for EME and categorize them. This way we can have a clearer idea of what is supported and what is NOT supported. I have added a few use cases up there already you may recognize.

Please take a few minutes to review and contribute.

Joe Steele