Re: [SUMMARY] Do we need loadSession?

On Aug 20, 2014, at 4:35 PM, Mark Watson <watsonm@netflix.com> wrote:

> 
> On Wed, Aug 20, 2014 at 3:46 PM, Joe Steele <steele@adobe.com> wrote:
> 
> [steele] I think that applications should not be managing “sessions”. I believe that sessions should be ephemeral constructs.
> 
> 
> ​Let's think through the consequences of this. If a session is truely "ephemeral" then it contains no state that might ​need to be persistent cross-session (I mean browser session). [If it did contain such state, there would need to be a way to have the session save that state and later load it back into another session. I'm not sure there is a meaningful distinction between that and "persisting the session". If two sessions have the same state they are fundamentally the same thing, like electrons ;-) ]
> 
> So, then, a session is no more than a temporary context for managing an exchange of messages. Any new potentially-persistable state that results from the message exchange is logically not part of the session, it is just new CDM state that is created as a result of the message exchange. A consequence is that things like usableKeyIds should be exposed on MediaKeys, not on MediaKeySession. When you created a MediaKeys object, the usableKeyIds for any persisted content keys would appear (perhaps after a keyschange event).
> 
> The kind of application control of persistence suggested by David would require the ability at the MediaKeys level to remove keys by key ID, or to signal that the whole MediaKeys object is one whose keys should be deleted and not persisted when the object is destroyed.
> 
> In this model, secure proof of key release needs to be an explicitly defined feature - it's not something which can be built using other general-purpose primitives. For example, the keyschange event (now on MediaKeys) could carry a map of ( keyID -> proof of release ) for all the released keys.
> 
> However, there is some value in grouping the keys for a single content item in some way on the API: if I want to fetch keys for five content items in parallel, I likely have five initData, need five sessions and get back five sets of keys with key ids. It's important to know which keys are for which content item. One way is if the keys are part of the session and if there is some identifier for that group of keys (the sessionId) - back to the persistable-session model.

Another way is that you know any keys retrieved are related to the initData used to retrieve them. Since for every session ID there is a single related initData. The application can track using the initData them not the session ID. Then there is no need for the idea of a 'persistable’ session since an initData should always be associated with the keys that were retrieved using it.

> If we want to fulfill this requirement with truely ephemeral sessions I guess we could have the session expose a readonly attribute listing the keyIds that were delivered in that session, but this seems messy.

I don’t think you need to use the key IDs at all if you use the initData as I describe. 

> 
> Unless I am mistaken, all the DRMs either already do or imagine that they will manage multiple keys for a single content item together - a bundle of keys - either a license with multiple keys or a sequence of them for key rotation. And where keys - or proof or key release messages - are persisted these will also likely be managed in the same bundles. I'd always understood sessions to be the vehicle for exposing this bundling on our API.

I agree with everything you said about keys except for using sessions as the vehicle for exposing them. I see no need for that. Keys or bundles of keys can be managed by referring to them using the initData rather than the session ID. That has a much more natural (to me) mapping to the underlying DRM mechanisms. 

I would prefer we have a mechanism that clearly indicates what the expectations are (i.e. generateKeyRequest, loadKeys, releaseKeys) rather than a session concept where the behavior depends on whatever the CDM decides.

> 
> ...Mark
>