[Bug 25200] Add optional "licenseType" parameter to createSession()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25200

Joe Steele <steele@adobe.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steele@adobe.com

--- Comment #1 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #0)
> === Background ===
> The license requests for persistent licenses may be different from normal
> "streaming" licenses. Since license requests are generated as a result of
> createSession(), applications must be able to indicate the desired type as
> part of the call. (This doesn't make sense as a property of the MediaKeys
> object because it does not apply to other methods or even all sessions.)
> 
> 
> === Proposal ===
> I propose the following change:
> enum LicenseType { "streaming", "persistable" };
> MediaKeySession createSession(DOMString contentType, Uint8Array initData,
> optional LicenseType licenseType = "streaming");

Licenses for content may be "persistable" regardless of whether the content is
being streamed or played offline. When you are saying "streaming" it seems like
you mean specifically "streamed VOD content with ephemeral licenses". This is
only one of at least three types of streaming I can think of: VOD, live, and
linear (aka a network channel). There are probably more. And all of those
stream types can use persistent or non-persistent licenses. 

I suggest using the term "ephemeral" instead of "streaming" when you are
referring to licenses. 

> 
> We would also add the following step to the createSession() algorithm:
> If the content decryption module corresponding to the keySystem attribute
> does not support the licenseType, throw a NOT_SUPPORTED_ERR exception and
> abort these steps.
> 
> The |licenseType| parameter is only an indication of the license type
> desired. The CDM may reject the request (by firing an error) and the license
> server must accept the request before such a license is issued.
> 
> Other types of licenses could be added to the enum in the future if a need
> arises.
> "streaming" is the normal licenses EME currently supports. Naming
> suggestions welcome.

See above. 

> 
> Note: Without adding such a |licenseType| parameter to isTypeSupported(),
> try/catch of the createSession() call would be the only way to determine
> whether the license type is supported. The parameter list for
> isTypeSupported() is already getting long (bug 24873), though.
> 
> 
> === Persisting Licenses ===
> The proposal above addresses the license request, the actual persisting of
> the license is unspecified.
> 
> There are two potential ways to persist the license
> 1) In the CDM
> 2) In the app using existing storage APIs.
> 
> In case #1, the license would be persisted as the result of an update()
> call, and loadSession() can later be used to load it.
> In case #2, update() would be called when the licenses is needed and the CDM
> would treat the license like any other ("streaming") license. loadSession()
> would not be used since the license/session is never stored in the CDM.
> 
> Without further specification, it is ambiguous how the license will be
> handled (and applications may not even have the option to implement case #2
> if the CDM automatically stores the license). This is undesirable since
> applications should manage stored sessions regardless of where they are
> stored.

I think telling the CDM it cannot cache licenses regardless of what the policy
says is fine (although ultimately not very useful). However without some more
nuanced idea of what a session is other than a collection of cached key server
responses, this seems hard to manage. 

> 
> Options to address this include:
> A) Use different license types by replacing "persistable" with "persisted"
> for case #1 and some other value for case #2.
> B) Add an explicit store()/persist() method on MediaKeySession().
> 
> In both cases, the CDM would decide whether persisting of the license is/was
> necessary based on its contents.
> 
> Option B has the advantages of being more explicit.
> The application will know whether the CDM will persist the license,
> something that it otherwise wouldn't know for sure without then trying to
> load the session. (This is even more relevant with Promises (bug 25199)
> where the result of the method can be reported directly.*)
> In addition, an explicit method provides a place to document the storage
> algorithm without polluting update(). This is similar to what we have with
> loadSession().

I like the idea of store() much more when you can be specific about what is
being stored. The current concept of a "session" being stored is not specific
enough. This also applies to the release() method. However I think the idea of
asking the CDM whether it supports persistent licenses at all is useful,
because a developer can capture the error and use that to gate license
management logic in the application.

> 
> * Without Promises, errors are reported asynchronously and could have come
> from the update() or the store() call. In this case, calling loadSession()
> is more definitive.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 31 March 2014 20:29:06 UTC