Re: [SUMMARY] Do we need loadSession?

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. 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.

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.

...Mark