Re: [EME] Heartbeat support

I think to answer these questions we really need to understand what a "session" is.

A session represents some state in the CDM. This state may include keys, licenses and other information that needs to be handled securely by the CDM. This state has a lifecycle - it is created when a keymessage is first sent by the CDM, it's updated by messages coming to the CDM through addKey and it can be destroyed (at some point). When it's destroyed a proof of that destruction may be generated (secure stop).

We could leave it at that. This would leave decisions on when to create a new session and when to use an existing one to the keysystem. Scripts would need to support both additional message exchanges on an existing session and multiple sessions associated with a single media element. Scripts need not know whether the CDM is doing "heartbeats" or "key rotation" or something else.

Or, we could be more prescriptive. The main reason I can think of for wanting more than one session is if there is some reason for the state information in the sessions to have different lifecycles - specifically, to be independently updated and independently destroyed. If the life cycles of several pieces of state information are to be strongly coupled, then these pieces of information could usefully all reside in the same session.

Based on the above, there seems no reason to have multiple sessions for heartbeat. A single piece of state information is being updated with a new expiry time with each heartbeat ack.

For key rotation, it depends whether it's a requirement to formally destroy the old keys when new ones are provided. If it's sufficient to guarantee destruction of the old keys only when the whole thing is done, then it could be a single session. If the key rotation scheme involves both some long-term stream key *and* some short-term rotating keys (which are somehow combined), with the long-term one delivered at the beginning, then again, perhaps this is best modeled as a single session that is being updated with the new short-term keys as they rotate.

Perhaps addKey() should become some kind of "keyUpdate" method on the session object, to represent the semantics that it updates the session state somehow. Key updates can include actual new keys (key rotation) or just new ancillary data (expiry time for heartbeat).

So, I'm leaning toward favoring a single, updatable, session unless the use-case really requires separate lifecycle management for separate state instances in the CDM.

…Mark


On Jun 11, 2012, at 11:12 PM, David Dorwin wrote:

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?