Re: [EME] Heartbeat support

The idea of single key single session 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.

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?

On Wed, Jun 13, 2012 at 12:03 AM, Martin Soukup <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]
> *Sent:* June-12-12 2:12 AM
> *To:* 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