Re: [SUMMARY] Do we need loadSession?

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?) ?

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.

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

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.

...Mark






>
>
> ...Mark
>
>
>