W3C home > Mailing lists > Public > public-html-media@w3.org > December 2013

[Bug 24025] New: Add optional configuration parameter to MediaKeys constructor

From: <bugzilla@jessica.w3.org>
Date: Fri, 06 Dec 2013 23:57:14 +0000
To: public-html-media@w3.org
Message-ID: <bug-24025-5436@http.www.w3.org/Bugs/Public/>
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 on the CC list for the bug.
Received on Friday, 6 December 2013 23:57:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:01 UTC