Re: [EME] Heartbeat support

On Jun 13, 2012, at 7:39 AM, Yang Sun wrote:

The idea of single key single session

I don't think anyone is assuming a one-to-one relationship between keys and sessions. Are you proposing that ?

only has meaning when the key is used for the encrypted media, but the keep-alive message really does not need a key used for the encrypted media, so we should differentiate the keep-alive message with "real" key.

Why ?


For the key rotation, I do not know for the keep-alive message, there will be a new key or using existing key in the keymessage().

If using existing key, why key rotation happnes?
If usinga new key, can we using a temporary namespace key,since it has nothing relationship with CDM.
Does the key in keymessage will have something relative with CDM on device?

I didn't understand these last two sentences - could you elaborate ?

What we're trying to achieve here is an API where the purpose of the message exchanges is well-defined as being to establish the necessary state in the CDM to decrypt the media. But the actual contents of that state: keys, key metadata, licenses, how many, whether they expire, whether they rotate etc. is all up to the keysystem. There's no real reason for the script to know why the CDM wants to exchange messages with its peer server - other than the 'to establish decryption state' - the script just facilitates the exchange.

…Mark


On Wed, Jun 13, 2012 at 12:03 AM, Martin Soukup <martin.soukup@irdeto.com<mailto:martin.soukup@irdeto.com>> wrote:
I think Option 1 is simpler for the application developer and is consistent with the idea that a single key has a single session. If the rotation of keys will generate new sessions, however, I believe that the heartbeat mechanism should be consistent and be treated as a new key request since as an application developer I shouldn’t need to differentiate between what kind of requests are being made.

Similar to the question that came up on the call, how does the keymessage identify the media element?

Martin

From: David Dorwin [mailto:ddorwin@google.com<mailto:ddorwin@google.com>]
Sent: June-12-12 2:12 AM
To: public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: [EME] Heartbeat support

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16738

Some content providers require a heartbeat from the client device. Implementations often involve a message being generated by the decryption module and being ACK'd by the server. The APIs in the proposal were designed to allow such additional features without requiring API changes. However, there are multiple ways heartbeat might be implemented, and it probably makes sense to provide guidance to avoid fragmentation.

The current draft mentions two potential implementations at http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#faq-heartbeat:
 1) Use keymessage to continue the current session
 2) Start a new message exchange procedes in exactly the same way as the initial message exchange, with the exception that the Key System and Session ID are known when the needkey event is sent.

In option 1, keymessage would be used to provide the heartbeat, which must be ACK'd by the server. The thought is that this ACK would be provided via addKey(). Assuming we make the change in https://www.w3.org/Bugs/Public/show_bug.cgi?id=16548,  addKey() is always a response to a keymessage event, so that is somewhat consistent with existing use cases.

Option 2 is very consistent with the initial key request, but seems overly complex for a periodic heartbeat related to the same license.

If we feel heartbeat is common enough, another option would be to add explicit support for heartbeat, as is the case for key release. However, unlike key release, heartbeat can be handled within the existing APIs, and we want to avoid adding specific features to the API as much as possible.

Mark has provided his input in the bug. Does anyone else have a preference?



--
Yang
Huawei