Re: [MEDIA_PIPELINE_TF] Content protection proposal

On Dec 15, 2011, at 1:16 AM, Jan Lindquist wrote:

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.

In http://www.oipf.tv/docs/OIPF-T1-R2-Functional_Architecture-v2_1-2011-03-15.pdf section 6.14, is states "In the terminal-centric approach, the CSP function in the OITF and the CSP-T Server functional entity on the Provider Network exchange messages related to service and content protection over the UNIS-CSP-T reference point". I interpret the UNIS-CSP-T reference point as referring to a direct communication between DRM agent at the client and a DRM server, over IP. Is that wrong ? Is it anticipated that this communication be fed through the onDrmMessage methods ?


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.

It just seems more complex than necessary. There should only be one thing that a web page Javascript needs to do with a message from the DRM client: pass it to the server side. And there should only be one thing that it does with a message back from the server side: pass it to the DRM client.

The presence of the "type" fields - and in particular the possibility for each DRM to define messages types for any and every purpose - leaves things wide open and suggests very strongly that we will end up with DRM-specific message handling on the web page, which is what I would like top avoid.


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.

I wouldn't call it hit and mis, since that implies an element of chance, but I agree it is not optimal by some measures. The page would try each DRM supported by the service in preference order until the startKeyAcquire method returned true or until it ran out of supported DRMs. No chance involved. I don't imagine services supporting more than a few DRMs.

But we could supplying the list of DRMs both supported by the client and the media in the onkeyrequired event. The client then has to search through these to find it's preferred one. This actually requires more and more complex Javascript than the first option.

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.

Ah, so hear you are assuming the web page has access to multiple distinct copies of the content protected by different DRMs. This is something to be avoided at all costs by having all DRMs support a Common Encryption format.

But I agree it may be of value to have the possibility to get the supported system ids for this purpose. I will add that to the window.mediakeys interface, though, not to the HTMLMediaElement.

...Mark


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<mailto: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