- From: <bugzilla@jessica.w3.org>
- Date: Sat, 29 Mar 2014 01:12:54 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25200
Bug ID: 25200
Summary: Add optional "licenseType" parameter to
createSession()
Product: HTML WG
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P3
Component: Encrypted Media Extensions
Assignee: adrianba@microsoft.com
Reporter: ddorwin@google.com
QA Contact: public-html-bugzilla@w3.org
CC: mike@w3.org, public-html-media@w3.org
=== 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");
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.
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.
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().
* 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 Saturday, 29 March 2014 01:12:56 UTC