RE: [MEDIA_PIPELINE_TF] Content protection proposal

I agree with a minimalist approach to DRM issues. Support for DRMs of all kinds is adequate. The key event is one nice addition. Perhaps an identifier in the "key required" event would be good so that presence/absence of the appropriate key is handled early and failures quit faster.

Thanks!
-Paul

Q me<qto://talk/pg2483>


From: Jan Lindquist [mailto:jan.lindquist@ericsson.com]
Sent: Thursday, December 15, 2011 4:17 AM
To: Mark Watson
Cc: public-web-and-tv@w3.org WG
Subject: RE: [MEDIA_PIPELINE_TF] Content protection proposal

Hello Mark,

It is important to not strickly look at the API but the architecture. The sequences for Marlin in CSP specification do include communication between DRM client software and DRM server but it does not require communication like in the CI+ based DRM. If there are questions or concerns we should ask directly to OIPF CSP group for expert advise.

My view of type is that it simply indicates the format of the message. The message does not need to be parsed by the web page and can be simply forwarded to the DRM system in the backend.

I agree that an event for when a key is required is enough. What is not clear in the proposal is the ability of the webpage to know which DRM system is available in the client. Your proposal is a hit and miss case which is not optimal. The webpage will have to take content with different DRM encrypted content and one at a time get an error until one indicates missing key error which "implies" that the correct DRM system was used but the key needs to be retrieved.

Regards,
JanL

________________________________
From: Mark Watson [mailto:watsonm@netflix.com]
Sent: den 14 december 2011 18:03
To: Jan Lindquist
Cc: public-web-and-tv@w3.org WG
Subject: Re: [MEDIA_PIPELINE_TF] Content protection proposal

On Dec 14, 2011, at 5:33 AM, Jan Lindquist wrote:


Hello Mark,

I do not agree with the assertion in the introduction that OIPF requires the web page to understand the commands set of every DRM. I believe the command set you have proposed is equivelent in nature that of OIPF.

As I understand it, the only calls available in OIPF have parameters of the form ( "type", "message" ) and the set of possible types is DRM-specific. The web page needs to know the command set of the DRM and needs to construct the message contents appropriately. This command set could include anything, but for the limited set I have been able to obtain information about it doesn't include passing of the actually DRM key exchange messages (these are stated in the OIPF architecture to flow directly between DRM client agent and DRM server over a DRM-specific protocol, which is what I'd like to avoid).



Can you explain how a WebPage will be aware of the DRM system that is available in the UA?

It won't. It will be aware of the DRM systems that the service supports, which I expect would be a small list. It would try each of those in preference order until one of them worked.

Actually, it's been pointed out to me that we do need an event to trigger the start of the key exchange. I think I will start with a plain onkeyneeded event with no parameters, and then the flow would progress as described. Potentially, that onkeyneeded event could contain a list of the DRM system ids in the intersection of those supported by the client and those suitable for the media, which would avoid the need for the try-and try-again code on the page. But that's just an optimization.

...Mark



Regards,
JanL

________________________________
From: Mark Watson [mailto:watsonm@netflix.com]
Sent: den 8 december 2011 20:03
To: public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org> WG
Subject: [MEDIA_PIPELINE_TF] Content protection proposal
All,

I have placed a more detailed proposal for the content protection mechanism we proposed at the Berlin workshop here: http://www.w3.org/2011/webtv/wiki/MPTF/Netflix_Content_Protection

I look forward to comments/discussion.

Best,

Mark