- From: <bugzilla@jessica.w3.org>
- Date: Fri, 06 Dec 2013 23:57:14 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24025 Bug ID: 24025 Summary: Add optional configuration parameter to MediaKeys constructor Product: HTML WG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Encrypted Media Extensions Assignee: ddorwin@google.com Reporter: ddorwin@google.com QA Contact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-media@w3.org There are use cases where configuration information is necessary, or at least enables a more optimal user experience (by eliminating additional round trips to the server) and reduced burden on servers. I propose adding an *optional* key system configuration parameter to the MediaKeys constructor. Note that this parameter is intended to be used for configuring the key system and *not* to provide data from the application to be sent as part of message event(s). Use cases/values might include robustness options, offline, server certificates used to protect user identifiers, etc. Note that such values are just requests to the CDM and do not replace the server’s verification of the client or requirements in the license. Without such configuration capabilities, an extra round trip to the license server would be necessary for a) the CDM to request data be provided in a response and/or b) the server to specify additional configuration parameters to be used when generating a license request. While some of the configuration values might be key system-specific, we should continue to strive for interoperability across key systems as well as ease of writing applications that support multiple key systems. To that end: 1) Configuration values should generally be optional, especially for simple online streaming cases. 2) We should enable/encourage use of consistent configuration values across key systems. For #1, this means that use of this parameter should be optional for applications and key system implementations should allow such configuration values to be requested by the CDM and/or set by the server. As examples, the CDM could ask for a certificate in a message event or the server could respond with a configuration request in the response provided to update(). This might require an extra round trip and/or key request generation, but it would be opaque to the application and not require addition of key system specific logic to the application. If an application chooses, it can provide the potentially key system-specific configuration to the MediaKeys constructor to reduce the latency. For #2, we should define the parameter to be JSON. That way, the configuration names are open and can hopefully be consistent across key systems. For example, if a key system wants a configuration option for offline, it should use '"offline": true'. (I'm not sure where it makes sense to document such options.) An alternative for some configuration parameters would be to extend the key system name. However, this adds complexity to the user agent (to handle all the permutations); does not scale to multiple options being used simultaneously; and does not support some values, including non-trivial pieces of data like certificates. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 6 December 2013 23:57:18 UTC