I support this proposal.

Rather than a JSON string, shouldn't the new parameter just be a Javascript object (i.e. Dictionary in IDL) ?

That makes sense, but I think we might need to then define the possible configuration values:
Looking at the WebIDL spec, I'm not sure you can have a parameter of type "dictionary". Instead, the examples and algorithms show and imply, respectively, use of a dictionary definition.

If we can determine a likely set of member, that might be okay and would allow us to define the members in the spec (helping with interop) while maintaining extensibility.

(In reply to David Dorwin from comment #0)
> robustness options,

Do you envision these to be Key System-specific or do you envision standardizing a cross-Key System robustness taxonomy. AFAICT, EME has tried to avoid the latter, but you say "We should enable/encourage use of consistent configuration values across key systems."

> offline,

What kind of offline cases do you have in mind? From the user perspective, EME's non-lock-in story is that since EME is always streaming, it doesn't matter if the user watches one Netflix stream using Widevine on Chrome OS and the next stream using PlayReady on Windows 8.1--the user can make that transition, since there are no retained files tied to the first-used DRM keeping the user locked into the first-used DRM.

The same lock-in mitigation applies to browser vendors, too, in case a browser vendor wishes to be able to migrate from supporting one Key System to supporting another, since there's no need to keep supporting previously-obtained legacy files.

"Offline" in the sense of "sales" breaks that story, because if the user holds onto the DRMed files over a long period of time, the user is locked into the DRM used at the time the user obtained the files. So supporting that sort of offline seems harmful.

"Offline" in the sense of "rental" where the JS app manages the data (i.e. the user doesn't get to move a rented movie from a device to anthore) or caching subscription content could be accomplished using a generic offlining mechanism such as NavigationController as long as the Key System supports expressing a time-limited license as a single EME response message that the JS can store into IndexedDB or similar and push to the EME API later. So supporting this kind of offline should not involve changes to EME assuming a Key System with the described characteristic.

> server certificates used to protect user identifiers, etc.

Can you, please, elaborate on this? What's being protected against what/whom?

Hi Henri,

The issue of "lock in", either for browser or user, is really a function of a service that doesn't support multiple DRMs. It's not specific to offline - you could have lock-in with a subscription streaming service too. It's obviously more severe with 'ownership' models because the timeframe is 'in perpetuity'.

EME can't prevent this. What we are doing is defining an architecture that makes it easier for services to support multiple DRMs, in the hope that services will therefore find it easier not to lock in their customers in this way. That's all.

This bug is about quite practical concerns. As much as we wish to harmonize, the features and operation of different DRMs can be quite different. CDMs can have different modes offering different levels of robustness, for example, where starting the CDM in a more robust mode might take longer than in a less robust mode. If the application can provide information about the required mode, the longer startup can be avoided for applications that do not need the more robust mode.

The server certificates point refers to the idea that a CDM may wish to encrypt its messages to the server using a server public key. One approach is to do a round trip to the server to ask it for its public key. But if this information could be provided by the application, it would save a round trip.

I think the assumption with this mechanism is that it should be entirely for optional optimizations. Keysystems should always support a default mode of operation where no such information is supplied.

Mark did a good job addressing most of the questions (thanks!). A few more comments below.

(In reply to Henri Sivonen from comment #3)
> (In reply to David Dorwin from comment #0)
> > robustness options,
> 
> Do you envision these to be Key System-specific or do you envision
> standardizing a cross-Key System robustness taxonomy. AFAICT, EME has tried
> to avoid the latter, but you say "We should enable/encourage use of
> consistent configuration values across key systems."

I meant the name of such configuration items. For simple items (e.g. offline), the values can also be standardized, but you're right that it seems unlikely that robustness values could be standardized, at least in the short term. The format of certificates and other values might also differ.

> 
> > offline,
> 
> What kind of offline cases do you have in mind?

Think of it more as taking a streaming service/app on an airplane, etc. The user has made the same agreement with the service provider, but now they don't need a high bandwidth connection at the time the content is actually viewed.

The user can use different browsers/CDMs or the browser can transition CDMs (assuming the service supports the new CDM, which EME tries to make as easy as possible), but the app will need to acquire a license for the new CDM.

If one or more of the items in the dictionary is unrecognized or unsupported by the CDM, what should happen?

1. Report a MediaKeyError (NOT_SUPPORTED_ERR or INVALID_ACCESS_ERR).
2. Throw an exception.
 * This is probably more app-friendly than #1, but it requires the UA to know acceptable values, some of which could require probing. Thus, I don't think it is an option.
3. Ignore such values.
 * For recognized but unsupported values, do the best possible.
 * The server decide whether it's sufficient.
 * This potentially allows a single dictionary to be passed to all CDMs.
4. Ignore unrecognized values but let the CDM report errors for recognized but unsupported values if appropriate.
 * This seems to add too much ambiguity.

(In reply to David Dorwin from comment #2)
> That makes sense, but I think we might need to then define the possible
> configuration values:
> Looking at the WebIDL spec, I'm not sure you can have a parameter of type
> "dictionary". Instead, the examples and algorithms show and imply,
> respectively, use of a dictionary definition.

This is a common pattern. For example, see EventInit [1], passed as a generic initialization parameters collection to the Event constructor [2].

[1] http://www.w3.org/TR/dom/#eventinit
[2] http://www.w3.org/TR/dom/#event

> If we can determine a likely set of member, that might be okay and would
> allow us to define the members in the spec (helping with interop) while
> maintaining extensibility.

You can define zero or more potential standardized members, leaving others to be CDM specific (and defined in CDM specific documentation).

It would be much better to use a dictionary than to use a serialized JSON string.

(In reply to David Dorwin from comment #6)
> If one or more of the items in the dictionary is unrecognized or unsupported
> by the CDM, what should happen?
> 
> 1. Report a MediaKeyError (NOT_SUPPORTED_ERR or INVALID_ACCESS_ERR).
> 2. Throw an exception.
>  * This is probably more app-friendly than #1, but it requires the UA to
> know acceptable values, some of which could require probing. Thus, I don't
> think it is an option.
> 3. Ignore such values.
>  * For recognized but unsupported values, do the best possible.
>  * The server decide whether it's sufficient.
>  * This potentially allows a single dictionary to be passed to all CDMs.
> 4. Ignore unrecognized values but let the CDM report errors for recognized
> but unsupported values if appropriate.
>  * This seems to add too much ambiguity.

I vote for option #3 here. But I would say we need a little more clarity. 

Is a CDM free to ignore a single value or set of values? Or if an unknown value is present, must it ignore the entire dictionary? I would vote for the former as it is more flexible. 

I am fairly agnostic as to whether the parameter is a dictionary or a JSON string. However I will point out that if this is a JSON string, the CDM will be forced to include a parser it does not have today and that could be a source of errors.

My use-case for this is to provide a server certificate to the CDM.

A given CDM may be used with multiple servers, for example servers maintained by different service providers. In general, such servers will be running under license agreements from the CDM provider and can be provided with certificates signed by the CDM provider. This enables the CDM to authenticate servers i.e. determine that they are indeed approved by the CDM provider though the receipt of a server certificate.

Additionally, a server certificate can be used for the CDM to encrypt data sent to that server (in the keymessages). Such encryption may be useful to ensuring that the encrypted keymessage does not contain anything which could be used as a permanant user identifier by a site which does not have its own server certificate.

Such a server certificate will likely not change frequently and so may be cached by the site's client-side code and provided to the CDM when the MediaKeys is constructed. This approach avoids the provision of the server certificate requiring a round-trip to the server.

As discussed in bug 24082, it may be better to explicitly extend EME to handle missing capabilities rather than allow or even encourage custom values.

With that in mind, the three use cases presented so far could be addressed as follows:

1) Add an optional |capability| parameter to the MediaKeys() constructor or MediaKeySession.createSession().
The former keeps all key system-specific strings together. The latter allows more flexibility, including allowing sessions to use different capabilities, but that's probably not necessary.
This parameter would accept the same strings that are proposed to be supported by isTypeSupported() in bug 24873.

2) Add a "persistent" attribute to MediaKeys.
When true, the CDM will persist created sessions and load sessions from persistent storage. When false, things work as they do today (and loadSession() throws an exception). If a UA or key system implementation does not support persisting licenses, the UA may throw a NOT_SUPPORTED_ERR when an application attempts to set "mediaKeys.persistent = true".

3) Add an optional setServerCertificate(Uint8Array serverCertificate) to MediaKeys.
If a UA or key system implementation does not support server certificates, the UA may throw a NOT_SUPPORTED_ERR.

(In reply to David Dorwin from comment #10)
> 2) Add a "persistent" attribute to MediaKeys.
> When true, the CDM will persist created sessions and load sessions from
> persistent storage. When false, things work as they do today (and
> loadSession() throws an exception). If a UA or key system implementation
> does not support persisting licenses, the UA may throw a NOT_SUPPORTED_ERR
> when an application attempts to set "mediaKeys.persistent = true".

I don't think this attribute makes sense. Either there is a significant performance benefit to setting this flag and it will always be set by the application, or there is not and caching will be determined by license policy. Do you have a use case where this attribute would be determined by something other than the key system selected?

In the spirit of adding explicit extensions, I would like to add a fourth category. 

4) Add an optional "license domain" to MediaKeys. 
This would allow the application to select the license domain against which keys should be requested. There may be multiple domains (potentially requiring user selection) and the CDM will not have the policy logic to make this decision. I am not sure whether in all cases this could be deferred to a server communication either, since it may required user interaction. This is something the application has to be able to handle. 

I am also having a problem with this bit from the original request:
> 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)."

This feature should be targeted at exactly what this line says it is not - i.e. providing data from the application to be sent (or used) as part of the message events. Server certificate certainly falls into that category.

This bug now tracks three specific extensions that are no longer consistent with the original summary. I will file separate bugs for each.

(In reply to Joe Steele from comment #11)
> (In reply to David Dorwin from comment #10)
> > 2) Add a "persistent" attribute to MediaKeys.
> > When true, the CDM will persist created sessions and load sessions from
> > persistent storage. When false, things work as they do today (and
> > loadSession() throws an exception). If a UA or key system implementation
> > does not support persisting licenses, the UA may throw a NOT_SUPPORTED_ERR
> > when an application attempts to set "mediaKeys.persistent = true".
> 
> I don't think this attribute makes sense. Either there is a significant
> performance benefit to setting this flag and it will always be set by the
> application, or there is not and caching will be determined by license
> policy. Do you have a use case where this attribute would be determined by
> something other than the key system selected?

Yes, storage of licenses should be determined by the policy.
The proposal in comment #10 was a rough attempt at documenting how the use cases could be explicitly addressed rather than using a dictionary. As has been pointed out, this one needs more work. I'll provide an updated proposal in the new bug.
The important part is that the license request is appropriate for a persisted license. The CDM *may* then receive a license telling it to persist the license.

I filed specific bugs for the original use cases. This bug can now be closed.

1) Optional |capability| parameter like the proposed new isTypeSupported() parameter in bug 24873: I did not file a bug since I don't have a concrete use case at the moment.

2) Request persistable licenses: Filed bug 25200.

3) Preemptively provide a server certificate: Filed bug 25201.

(In reply to David Dorwin from comment #13)
> I filed specific bugs for the original use cases. This bug can now be closed.
> 
> 1) Optional |capability| parameter like the proposed new isTypeSupported()
> parameter in bug 24873: I did not file a bug since I don't have a concrete
> use case at the moment.
> 
> 2) Request persistable licenses: Filed bug 25200.
> 
> 3) Preemptively provide a server certificate: Filed bug 25201.

You did not add the 4th use case I provided. I will file an additional bug for this.