Re: [SUMMARY] Do we need loadSession?

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

> 
> On Tue, Aug 26, 2014 at 3:30 PM, Joe Steele <steele@adobe.com> wrote:
> 
> 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.
> 
> So, would you still expose usable key ids on the Session ? Or on the MediaKeys object ? Or something else (a new KeyGroup object?) ?

I would still expose them on the MediaKeySession, so they can be associated with the initData.

> 
> If we are going to have a concept of a group of keys, identified by some blob (==initData in your case) it makes sense to have some object to represent that group. This object can be re-created from the blob, possibly combined with some CDM state. In the case no new messaging is required, then whether you consider that creation of a new object containing the same keys, or persistence and retrieval of the original object is moot. As far as I am concerned those are the same thing.

The end result is the same, but they have different implications to the CDM. In the case of using sessionID, the CDM has to have infrastructure to manage these persistent sessions. It has to maintain a mapping of session IDs to whatever we decide the application cares about in a session. Similarly the application has to maintain a mapping layer, mapping session IDs to whatever information it cares about. Rather than create two mapping layers, I suggest we only have one. The application can build one if needed (most will not need) and the CDM can avoid the overhead entirely allowing the DRM to manage the things that can be persistent. 

> 
> Next question is whether that object that represents a group of keys needs to be distinct from the session concept that we need for messaging. Some DRMs at least have stateful messaging where there needs to be some context for the processing of the returning messages, so we do need this message context object (session).

The session is a holder for ephemeral state related to those keys - e.g. how long has this key been alive? when will it expire? what is the current content policy to enforce? The initData is the identifier for the group of keys or key return receipts. Any other state is outside the scope of the session. It may be affected by what goes on while the session is alive, but it is not exposed to the application. 

> 
> I don't see a need for a distinct object: keys are only initially created as a result of message exchanges and it seems reasonable to say that the smallest granularity of key grouping we need is the group that were created in a single message exchange. Any higher level grouping can be handled by the application.

> 
> So, we need a session object at it might as well be this same object which represents the set of keys created by the messaging in that session. Session ID is nothing other than a blob that can be used later to recreate the Session object (or to make a new one representing the same keys, if you refer).
> 
> Long story short: why can't you set sessionId == initData in your implementation ?
> 
> We could rename sessionID, make it into an ArrayBuffer, if that would help.
> 
> We could even allow sessionID to change (maybe using the new observable stuff) which would admit (but not require) an implementation where any persistent state was actually stored in this blob (encrypted), which would then avoid the need for the CDM to have access to disk (at least for this purpose and modulo non-graceful shut-down issues ...).
> 
> There would still be a distinction in the API between initData and (renamed) sessionId. The application knows that the initData is the thing that came from the file, with a format depending on the file format. The (renamed) sessionId may equal the initData for some CDMs, but for others it may be some other kind of internal identifier for some CDM state.

That is an interesting idea. One potential problem I can see is that if you open two sessions using the same initData, how would the browser distinguish between the two sessions for sending messages? Another is that the browser would have to assume the "session ID” could be large (e.g. multiple kilobytes). But if those are both dealt with, this could work. In fact, I could try this out by base64-encoding my initData today without changing the type at all. Hmmm.

> 
> ...Mark
> 
> 
> 
> 
>  
> 
>> 
>> ...Mark
>> 
> 
>