Request: Allow CDMs to support and enforce resolution restrictions (and expose the status of those restrictions to the application)

[ddorwin]

[March 6, 2015 Update: The discussion has diverged from the original intent of this bug, including the text of this comment, and the first commit below. I have updated the title to reflect the discussion]

Bug 25409 ("Allow applications to detect whether a key is usable before using it to decrypt content") explains the original motivation for the keyStatuses attribute and Bug 25092 comment 33 explains the intended behavior and usage. However, this may not be clear from the spec text.

[mwatson2]

In thinking about this further, I realize some of my previous comments may have been unclear / missing some points. Apologies for that. The following takes precedence if there is conflict ;-)

First, it's obviously desirable to be able to detect before playback starts what the key status is - particularly if it is "not allowed". It's highly desirable that CDMs attempt to engage HDCP before playback starts, since the UX for engaging HDCP during playback is horrible. I would expect implementations to attempt to engage HDCP as soon as the license is received and to indicate the key status once that process is complete. In that case the key status will remain fixed from then on. [If there are implementations which wait to receive content before engaging HDCP, then the key status could change, but that is a horrible UX as noted].

Second, we do have a requirement for content-specific policies associated with a single key. Whilst EME CDMs might support separate keys with separate content-independent policies, many services are prevented from using this capability by the need to have a single set of streams shared with many other (non-EME) devices which do not support this.

"Downscaling" is an example of a policy which is always content-dependent. If the policy is "downscale to SD", then this is obviously a noop if the content is SD resolution or lower. If the policy has exactly two tiers, then our present solution - a single key with status "output-downscaled" - is good: the application knows the tiers and therefore knows what content will pass the policy unmodified. How to handle >2 tiers is an open issue. (For example, with UHD the HDCP version matters as well and there is a "downscale to HD" case)

"Not allowed" is not so cleanly supported presently. As above, if the policy has two tiers, then the "output-not-allowed" value could be used for the case of HD not allowed but SD allowed. The application knows the tiers and can distinguish from the case where nothing is allowed since that case would result in an error. So it can assume that SD is all that is allowed. A better name would be "output-restricted".

For policies with > 2 tiers, we need to indicate multiple statuses associated with one key. CDM-specific fake key ids is one way to do that, but not at all a good one, in my opinion, from both a design and an interoperability perspective.

I'd suggest we explore other ways to indicate multiple status values for one key, for example a list or dictionary format for the key status. But I believe the >2 tiers cases are a future requirement and we should lock down the 2-tier case first.

[mwatson2]

Here is my understanding of the problem and some options for solutions:

Problem: the policy associated with a single key may be content-dependent. As a result the key may have a different 'status' depending on the content. The status value for content with different properties should be knowable before content is provided. How do we express this in the API so that the site can pick the appropriate content ?

Example: a policy associated with a single key with id X specifies different rules for UHD, HD and SD content. Depending on output protection, some of these may be not-allowed or downscaled.

Assumption: the service provider knows what kinds of policies their service issues.

Solution 1: Fake key ids

The CDM breaks the policy into separate pieces and exposes the status of the nth piece (for n>1) against a generated (aka 'fake') key id.

In the example, there would be three key ids, X, Fake-X-1 and Fake-X-2 with status as follows: X: status for SD content Fake-X-1: status for HD content Fake-X-2: status for UHD content

This solution assumes: (a) The application is aware of the content-dependent nature of the policy including the three tiers (b) The application either controls or is aware of the choice of fake key ids

Solution 2: Status list

The CDM breaks the policy into separate pieces following a canonical order. The status of key is expressed as a list of enum values, giving the status for each piece.

In the example, the status for Key ID X would be a list:

[ , , ]

For example [ "usable", "output-downscaled", "output-downscaled" ]

This solution assumes: (a) The application is aware of the content-dependent nature of the policy (b) The application either controls or is aware of the ordering of the policies in the list

Solution 3: Resolution-specific status values

The only form of content-dependent policy supported is resolution-dependent and we define specific status values for different resolutions, for example as follows:

• output-downscaled-sd: Any content > SD resolution will be downscaled to SD
• output-downscaled-hd: Any content > HD resolution will be downscaled to HD
• output-not-allowed-hd: Any content > SD resolution is not allowed
• output-not-allowed-uhd: Any content > HD resolution is not allowed

There may be other solutions - the above are intended to start the discussion.

Solution 4: Complete content-property to status map

The CDM breaks the policy into separate pieces and provides a description of each piece and its status. i.e. the KeyStatus for each Key ID is a map-like from a content descriptor to a key status.

Content descriptors could be newly defined strings or could even be Media Queries.

In the example, the key status might be:

{ "max-pixels: 307200" : "usable", "default" : "output-downscaled" }

Discussion:

Solutions 1 and 2 rely on application knowledge of the content-dependent policy. This seems a fairly safe assumption. Between them Solution 2 has the advantage of not requiring keysystem support for either application-provided fake key ids, or standardization of the way fake key ids are generated. Also, the fake key id approach seems to badly mix distinct concepts (key ids and content-dependent policy).

Solution 2 does require a canonical ordering of the policies. However since the only real-world example (resolution-specific policy) has a natural ordering it seems this principle might be easy to establish at this time.

Solution 3 is pragmatic, addressing the presently known use-case in a straightforward manner. It has the advantage of simplicity at the expense flexibility for future use-cases or for varying definitions of "SD", "HD" and "UHD".

Solution 4 is comprehensive, but arguably over-complex given the absence of concrete use-cases beyond resolution.

Extension of content-specific policies beyond resolution may occur if HDCP2.2 is cracked and WGC / HDR become subject to more stringent requirements than 4K. We can assume this is unlikely in the short to medium term. In any case Solution 3 could bear extension to another content property or two without become unwieldy and so my preference is Solution 3 (followed by Solution 2).

[ddorwin]

Streams with meaningfully different policies should use different keys. Using the same key and relying on content-dependent policy is a kludge and likely to compromise content security in practice.

Content-/resolution-dependent policies are unlikely to be supported by all key systems or CDM implementations. Specifically, CDMs may not have access to resolution information when a hardware decoder is used. Thus, it’s not something that applications can rely on. Encouraging such designs goes against the interoperability goals, especially for higher quality/resolution content.

Rather than baking a kludge only supported by a subset of CDM implementations into the spec, especially with the additional API complexity costs for all applications and implementations, we should leave it to applications relying on such policies to use the fake key ID workaround.

[mwatson2]

Regarding "Streams with meaningfully different policies should use different keys. Using the same key and relying on content-dependent policy is a kludge and likely to compromise content security in practice.":

What does / does not compromise content security policy is not a matter we can adjudicate here. It's an issue between content provider and CDM provider.

Using the same key for different resolutions has the huge advantage that the same media files can be used with millions of legacy devices. It's not (commercially) reasonable to provide a different file set for EME and indeed this is the very reason for many aspects of the design, not least Common Encryption.

Regarding "Content-/resolution-dependent policies are unlikely to be supported by all key systems or CDM implementations.", this is fine, but all currently deployed key systems do support this in some form. A CDM that did not support this likely could not be used by service providers who take this approach. In practice, I think such a CDM is unlikely to be successful.

Regarding "CDMs may not have access to resolution information when a hardware decoder is used.", if you mean a hardware decrypt / decode pipeline, this pipeline needs to implement output protection policy and that is always going to be resolution-dependent because of the nature of studio requirements. So that pipeline needs a secure way to be provided with the policy.

It is not necessary for the resolution of the actual decoded video to be known to correctly present the key status: that is derived from the license independent of the provided content (just to be clear, this is contrary to some things I said much earlier in the Bugzilla conversation.)

Regarding "Rather than baking a kludge only supported by a subset of CDM implementations into the spec, especially with the additional API complexity costs for all applications and implementations, we should leave it to applications relying on such policies to use the fake key ID workaround."

I couldn't disagree more. This approach is not a kludge and is widely supported. We do not have a proposal that would make the fake key ids interoperable and if we did I think we would find that it maps easily and more cleanly to one of the other solutions I suggested.

[ddorwin]

What does / does not compromise content security policy is not a matter we can adjudicate here. It's an issue between content provider and CDM provider.

It's not just between content provider and CDM provider because it leads content provider(s) to attempt to restore the lost security properties with other kludges and platform/user agent/CDM requirements that negatively affect client implementers, users, the web platform, and - as in the current discussion - authors. Such requirements unnecessarily restrict the ability to innovate in client implementations. They may also restrict content to client devices in ways that are otherwise unnecessary and unrelated to content protection and introduce DRM-like requirements to more of the web platform and/or client implementations. As I said, we should not encourage this or complicate the API for something that is harmful to the platform, especially considering there is already a solution (fake key IDs).

Using the same key for different resolutions has the huge advantage that the same media files can be used with millions of legacy devices. It's not (commercially) reasonable to provide a different file set for EME and indeed this is the very reason for many aspects of the design, not least Common Encryption.

Surely UHD and new codecs are an opportunity to break away from such legacy requirements.

What is it exactly that these legacy devices do not support and why? What is the scope of this problem? How old are these devices? Do they support CENC? Are there alternative solutions like using multiple licenses?

Regarding "Content-/resolution-dependent policies are unlikely to be supported by all key systems or CDM implementations.", this is fine, but all currently deployed key systems do support this in some form. A CDM that did not support this likely could not be used by service providers who take this approach. In practice, I think such a CDM is unlikely to be successful.

See my first paragraph above. We should not let old devices (without user agents) dictate the interoperability, innovation, etc. of the web platform and client implementations.

Regarding "CDMs may not have access to resolution information when a hardware decoder is used.", if you mean a hardware decrypt / decode pipeline, this pipeline needs to implement output protection policy and that is always going to be resolution-dependent because of the nature of studio requirements. So that pipeline needs a secure way to be provided with the policy.

CDMs do not need to know the resolution of content to enforce output protection. You appear to be assuming a specific design where a monolithic pipeline implements all DRM policies.

It is not necessary for the resolution of the actual decoded video to be known to correctly present the key status: that is derived from the license independent of the provided content (just to be clear, this is contrary to some things I said much earlier in the Bugzilla conversation.)

Yes, the status values could probably be reported, but the policies represented by those values must be enforced by the CDM, which would require the CDM to know the resolution.

I couldn't disagree more. This approach is not a kludge and is widely supported.

I disagree on both points. Using the same key is in fact a workaround that while effective in solving the specific problem (something related to legacy devices) is difficult to extend and maintain. Support is limited on at least some clients and will be increasingly problematic as content, protection requirements, and devices evolve and expand. Also, we have no indication that other content providers do or wish to use this model.

We do not have a proposal that would make the fake key ids interoperable and if we did I think we would find that it maps easily and more cleanly to one of the other solutions I suggested.

I don’t recall a concrete interoperability problem with the fake key ID solution. (To be clear, there is nothing special in the client about fake key IDs - the CDM doesn’t know that the content provider is not planning to use the key.) Perhaps you can identify specific concerns and we can focus on addressing those.

All that said, nothing says you can't use the same key - I’m just saying that we shouldn't complicate the APIs that all authors have to deal with in order to make using the same key simpler. We should prefer simple and interoperable APIs for authors using best practices. I still think the fake key IDs model can probably be made to work for all clients, but if authors who do not follow best practices need UA- or key system-specific code, that is something they will have to deal with.

[mwatson2]

On Thu, Feb 12, 2015 at 12:12 AM, ddorwin notifications@github.com wrote:

What does / does not compromise content security policy is not a matter we can adjudicate here. It's an issue between content provider and CDM provider.

It's not just between content provider and CDM provider because it leads content provider(s) to attempt to restore the lost security properties with other kludges and platform/user agent/CDM requirements that negatively affect client implementers, users, the web platform, and - as in the current discussion - authors. Such requirements unnecessarily restrict the ability to innovate in client implementations. They may also restrict content to client devices in ways that are otherwise unnecessary and unrelated to content protection and introduce DRM-like requirements to more of the web platform and/or client implementations. As I said, we should not encourage this or complicate the API for something that is harmful to the platform, especially considering there is already a solution (fake key IDs).

I don't understand how ​content-specific policies cause any of the ills you describe above. Could you be more specific ?

Using the same key for different resolutions has the huge advantage that the same media files can be used with millions of legacy devices. It's not (commercially) reasonable to provide a different file set for EME and indeed this is the very reason for many aspects of the design, not least Common Encryption.

Surely UHD and new codecs are an opportunity to break away from such legacy requirements.

​I think that ship has sailed.​

What is it exactly that these legacy devices do not support and why? What is the scope of this problem? How old are these devices? Do they support CENC? Are there alternative solutions like using multiple licenses?

​As far as I am aware, none of the existing CENC-supporting DRMs have the ability to have multiple keys delivered and used for seamless playback, so we are talking about all CENC devices (of which there are many millions) including very recent ones.​

Regarding "Content-/resolution-dependent policies are unlikely to be supported by all key systems or CDM implementations.", this is fine, but all currently deployed key systems do support this in some form. A CDM that did not support this likely could not be used by service providers who take this approach. In practice, I think such a CDM is unlikely to be successful.

See my first paragraph above. We should not let old devices (without user agents) dictate the interoperability, innovation, etc. of the web platform and client implementations.

One of the big advantages of Common Encryption is that streams can be shared with existing CENC devices. This is a big enough advantage to be worthy of consideration. I don't agree that there is any negative impact on interoperability or innovation (quite the reverse when it comes to interoperability).

Regarding "CDMs may not have access to resolution information when a hardware decoder is used.", if you mean a hardware decrypt / decode pipeline, this pipeline needs to implement output protection policy and that is always going to be resolution-dependent because of the nature of studio requirements. So that pipeline needs a secure way to be provided with the policy.

CDMs do not need to know the resolution of content to enforce output protection. You appear to be assuming a specific design where a monolithic pipeline implements all DRM policies.

It is not necessary for the resolution of the actual decoded video to be known to correctly present the key status: that is derived from the license independent of the provided content (just to be clear, this is contrary to some things I said much earlier in the Bugzilla conversation.)

Yes, the status values could probably be reported, but the policies represented by those values must be enforced by the CDM, which would require the CDM to know the resolution.

​The CDM also does the decrypt and decode, so it must know the resolution. ​I'm sure there are implementation architectures where this is easier / harder but there's nothing in the EME architecture which impedes this. If it's a secure hardware implementation, policy interpretation, decrypt, decode and output protection all need to be in the secure area.

I couldn't disagree more. This approach is not a kludge and is widely supported.

I disagree on both points. Using the same key is in fact a workaround that while effective in solving the specific problem (something related to legacy devices) is difficult to extend and maintain. Support is limited on at least some clients and will be increasingly problematic as content, protection requirements, and devices evolve and expand. Also, we have no indication that other content providers do or wish to use this model.

We do not have a proposal that would make the fake key ids interoperable and if we did I think we would find that it maps easily and more cleanly to one of the other solutions I suggested.

I don’t recall a concrete interoperability problem with the fake key ID solution. (To be clear, there is nothing special in the client about fake key IDs - the CDM doesn’t know that the content provider is not planning to use the key.) Perhaps you can identify specific concerns and we can focus on addressing those.

​It feels like we have different models of how the Fake Key IDs could work.

I am assuming that a license is provide to the CDM containing a single key that indicates (say) that SD output is allowed without HDCP but that HD requires HDCP. The CDM must then expose two key ids, the real one and the fake one. The choice of fake key id is made in the CDM and needs to be made in an interoperable way - we would need to specify that. The absence of such a specification is an interoperability problem as every CDM will choose to do it in a different way.

If, for example, we were to specify that the fake key id representing the HD policy shall be the real key id with the letters "HD" appended, then that solves the interoperability problem. But this does not seem any different, implementation-wise, from exposing output-downscaled-hd as a new status on the original key id, which is much cleaner architecturally.

Did you have a different model in mind for the fake key ids ?

All that said, nothing says you can't use the same key - I’m just saying that we shouldn't complicate the APIs that all authors have to deal with in order to make using the same key simpler. We should prefer simple and interoperable APIs for authors using best practices. I still think the fake key IDs model can probably be made to work for all clients, but if authors who do not follow best practices need UA- or key system-specific code, that is something they will have to deal with.

​Of course I agree with all these statements about preferring ​prefer simple and interoperable APIs, I just think what I proposed is simpler and more interoperable ;-)

— Reply to this email directly or view it on GitHub https://github.com/w3c/encrypted-media/issues/22#issuecomment-74032730.

[alex-the-man]

I agree with ddorwin that context-dependent policy is a kludge and something EME shouldn't standardize. However, the fake key solution might not work on current PlayReady and Adobe Access because they use single key licenses. There is no way to inject 2 keys into their CDMs without 2 MediaKeySessions. Of course the spec can require that [https://github.com/w3c/encrypted-media/issues/23] but I don't think it's a good idea to impose additional requirements on CDMs just because of a workaround. Also, I don't think exposing keys to the application layer is a good idea. It makes writing application code that works across CDMs difficult.

I think the problem here is that output protection is conceptually resolution independent. But it has evolved so quickly and unfortunately becomes resolution dependent in a de-facto way. For example, HDCP v1 is required for HD content. And HDCP v2.2 is required for UHD content. Output protection will likely be tiered in real world use case.

Should we make an exception to output protection here because of real world use cases and treat it separately from key status? Because if we do, we can simply add a query method to let the CDM to tell the application what output protection requirements specified in the license are violated. The application have to compute the maximum resolution from the output protection requirements status on its own.

To CDM implementations, it's a trivial case when there is just a single key. However, if there are multiple keys, CDMs should scan through all keys, find all mentioned output protection requirements, check their statuses and report to the application.

This is still a workaround but it's better for interoperability since it works for both existing use case (a single key license with resolution dependent rule) and the secure use case (a dual keys license with a SD key without output protection & a HD key with output protection).

I'm speaking from the perspective of an application developer so what I've said might not make sense to a CDM implementer.

[ddorwin]

It's not just between content provider and CDM provider because it leads content provider(s) to attempt to restore the lost security properties with other kludges and platform/user agent/CDM requirements that negatively affect client implementers, users, the web platform, and - as in the current discussion - authors. Such requirements unnecessarily restrict the ability to innovate in client implementations. They may also restrict content to client devices in ways that are otherwise unnecessary and unrelated to content protection and introduce DRM-like requirements to more of the web platform and/or client implementations. As I said, we should not encourage this or complicate the API for something that is harmful to the platform, especially considering there is already a solution (fake key IDs).

I don't understand how ​content-specific policies cause any of the ills you describe above. Could you be more specific ?

For example, attempting to require that the entire user agent and/or web application execution environment be locked down in a server-verifiable way.

Forcing CDMs to support resolution restrictions unnecessarily restricts the possible solution space in ways that are unrelated to the actual protection of content. As the web platform (and EME) are added to more and more types of devices, it’s important that the solution space not be so restricted.

We haven’t discussed whether keys can be shared between audio and video, but that would compound the issue further. Is this something we can rule out?

Surely UHD and new codecs are an opportunity to break away from such legacy requirements.

​I think that ship has sailed.​

I disagree. Comparatively little content is available in UHD or using next generation codecs, and there are still more advances, such as bit depth and HDR, coming.

It’s disappointing to again see a preference for restricting all future web platform clients rather than working to resolve (or encourage resolution of) known limitations. These issues have been known for a long time and could have been previously addressed rather than forcing kludges and pain on all other implementations. As noted below, at least one content provider appears to have confronted and resolved this issue.

​As far as I am aware, none of the existing CENC-supporting DRMs have the ability to have multiple keys delivered and used for seamless playback, so we are talking about all CENC devices (of which there are many millions) including very recent ones.​

This is not true. Widevine supports CENC and multiple keys. Also, I know there is a content provider doing seamless switching of CENC content on multiple devices (and not just with Widevine).

One of the big advantages of Common Encryption is that streams can be shared with existing CENC devices. This is a big enough advantage to be worthy of consideration. I don't agree that there is any negative impact on interoperability or innovation (quite the reverse when it comes to interoperability).

I am telling you there are reasonable and advantageous architectures/designs/implementations that do not support such resolution restrictions. Thus, such devices cannot play content that relies on this. That is a negative impact on interoperability and users. In addition, if clients must be implemented in a specific way to play popular content, that inhibits innovation.

​The CDM also does the decrypt and decode, so it must know the resolution. ​I'm sure there are implementation architectures where this is easier / harder but there's nothing in the EME architecture which impedes this. If it's a secure hardware implementation, policy interpretation, decrypt, decode and output protection all need to be in the secure area.

You are assuming a specific implementation; the spec should not. Even some more “traditional” implementations may not support what would be required.

It feels like we have different models of how the Fake Key IDs could work.

I am assuming that a license is provide to the CDM containing a single key that indicates (say) that SD output is allowed without HDCP but that HD requires HDCP. The CDM must then expose two key ids, the real one and the fake one. The choice of fake key id is made in the CDM and needs to be made in an interoperable way - we would need to specify that. The absence of such a specification is an interoperability problem as every CDM will choose to do it in a different way.

Thanks for clarifying your model. I was assuming that the application's server would ask the key system’s license server to issue a license containing the real key and the fake key. Thus, the content provider would be in complete control of the IDs.

I don’t see a reason for the CDM to generate the ID - if the CDM can be updated to do that, it can (be updated to) accept a license with multiple keys. This is also a step towards addressing issue #23, which I’m guessing also affects such CDM implementations.

[ddorwin]

However, the fake key solution might not work on current PlayReady and Adobe Access because they use single key licenses.

Thanks for bringing this to our attention. This is more relevant to issue #23, so I’ve moved this part of the discussion there.

There is no way to inject 2 keys into their CDMs without 2 MediaKeySessions. Of course the spec can require that [#23] but I don't think it's a good idea to impose additional requirements on CDMs just because of a workaround.

23 is not just for this workaround - it is an important capability for applications.

Also, I don't think exposing keys to the application layer is a good idea. It makes writing application code that works across CDMs difficult.

See my reply in #23. Keys are already an important concept in the application. The goal is to make writing applications simpler with less key system-/CDM-specific code.

I think the problem here is that output protection is conceptually resolution independent. But it has evolved so quickly and unfortunately becomes resolution dependent in a de-facto way. For example, HDCP v1 is required for HD content. And HDCP v2.2 is required for UHD content. Output protection will likely be tiered in real world use case.

Those are business rules, and it is fine to have business rules that depend on resolutions. The problems are a) expecting all CDMs to enforce decoded resolution (rather than just whether a key can be used) and b) exposing such business rules in the spec - we cannot and should not predict what policies and differentiations will be relevant in the future. Relying on separate keys allows any business rule to be implemented by the application and server (and for CDM implementations to evolve to meet new industry needs).

Should we make an exception to output protection here because of real world use cases and treat it separately from key status?

Such an exception does not address (a) and (b) above.

[mwatson2]

On Thu, Feb 26, 2015 at 11:03 AM, ddorwin notifications@github.com wrote:

It's not just between content provider and CDM provider because it leads content provider(s) to attempt to restore the lost security properties with other kludges and platform/user agent/CDM requirements that negatively affect client implementers, users, the web platform, and - as in the current discussion - authors. Such requirements unnecessarily restrict the ability to innovate in client implementations. They may also restrict content to client devices in ways that are otherwise unnecessary and unrelated to content protection and introduce DRM-like requirements to more of the web platform and/or client implementations. As I said, we should not encourage this or complicate the API for something that is harmful to the platform, especially considering there is already a solution (fake key IDs).

I don't understand how ​content-specific policies cause any of the ills you describe above. Could you be more specific ?

For example, attempting to require that the entire user agent and/or web application execution environment be locked down in a server-verifiable way.

​The scope of functionality that must comply to DRM robustness rules is indeed an important factor. I believe this is a (strict) subset of the CDM​ and should remain so.

But, still, I don't understand how content-dependent policies lead to this consequence ? Resolution-dependent policies are implemented today without this consequence.

Forcing CDMs to support resolution restrictions unnecessarily restricts the possible solution space in ways that are unrelated to the actual protection of content. As the web platform (and EME) are added to more and more types of devices, it’s important that the solution space not be so restricted.

​Existing CDMs already support resolution-dependent policies. It's not clear to me that the solution space is at all restricted. Some things may be more complex from an implementation perspective, but nothing is rendered impossible or impractical.

Downscaling of already-buffered content based on output protection status is a clear user-affecting use-case where knowledge of the resolution restriction is required after decode (to perform the downscaling). Assuming this use-case is supported I cannot see how the indications I proposed above add any restrictions or even significant complexity. Even if this use-case is not supported, the architectural implications seem minor.

We haven’t discussed whether keys can be shared between audio and video, but that would compound the issue further. Is this something we can rule out?

​It's not something we (Netflix) require.

Surely UHD and new codecs are an opportunity to break away from such legacy requirements.

​I think that ship has sailed.​

I disagree. Comparatively little content is available in UHD or using next generation codecs, and there are still more advances, such as bit depth and HDR, coming.

​There are a large volume of UHD-capable devices already deployed. One could imagine a project to roll out seamless key-switching to new devices, but this would be quite some time in coming by which time there will be an even larger number of legacy UHD devices in the field as well as HDR devices.​ Maintaining support for these whilst also introducing seamless key-switching would imply keeping duplicate catalogs through the device refresh cycle (7-10 years) during which time there will be significant volumes of content in these formats. The security advantages of using different keys for different resolutions are undermined by the mere existence of a stream set where the same key is used, so those are not obtained until the legacy devices are retired.

It’s disappointing to again see a preference for restricting all future web platform clients rather than working to resolve (or encourage resolution of) known limitations. These issues have been known for a long time and could have been previously addressed rather than forcing kludges and pain on all other implementations. As noted below, at least one content provider appears to have confronted and resolved this issue.

​Many things are disappointing. But again, I don't believe you've demonstrated any significant "restrictions" being imposed on future clients: we're talking about exposing indications based on existing CDM functionality.​

​As far as I am aware, none of the existing CENC-supporting DRMs have the ability to have multiple keys delivered and used for seamless playback, so we are talking about all CENC devices (of which there are many millions) including very recent ones.​

This is not true.

​My statement was true ("As far as I am aware etc."). Ok, so Widevine is an exception. We're still talking about the vast majority of deployed devices that do not support seamless key-switching. ​

Widevine supports CENC and multiple keys. Also, I know there is a content provider doing seamless switching of CENC content on multiple devices (and not just with Widevine).

​Fair enough. I'm not suggesting they need to make any changes.​

One of the big advantages of Common Encryption is that streams can be shared with existing CENC devices. This is a big enough advantage to be worthy of consideration. I don't agree that there is any negative impact on interoperability or innovation (quite the reverse when it comes to interoperability).

I am telling you there are reasonable and advantageous architectures/designs/implementations that do not support such resolution restrictions. Thus, such devices cannot play content that relies on this. That is a negative impact on interoperability and users. In addition, if clients must be implemented in a specific way to play popular content, that inhibits innovation.

​I think we need to better understand the ​architectures/designs/implementations that you are referring to. IIUC, what you are saying is that resolution-dependent policies imply undue implementation complexity. This is only an interoperability issue if, either, support is optional or the complexity is high enough that implementers choose non-compliance. Otherwise it's just a burden on implementers which has to be justified by requirements higher in the priority of constituencies. Certainly, we should be aware if we are crossing the complexity bar that causes people to choose non-compliance, but at the moment I don't see it being close to that at all, based on deployed functionality.

And, again, given the use-case of downscaling already-buffered content it is hard to see where, architecturally, such complexity could arise ?

​The CDM also does the decrypt and decode, so it must know the resolution. ​I'm sure there are implementation architectures where this is easier / harder but there's nothing in the EME architecture which impedes this. If it's a secure hardware implementation, policy interpretation, decrypt, decode and output protection all need to be in the secure area.

You are assuming a specific implementation; the spec should not.

​No, I'm actually explicitly not assuming any implementation. Decode, decrypt, license interpretation and output protection all need to be within the scope of the DRM robustness rules. Now, it's entirely possible to have implementations where these components are within distinct components secured in different ways, but without making any assumptions we can be sure that there need to be secure communication paths between these components, specifically for communication between license interpretation and decrypt (the key) and between decrypt and decode (decrypted data). The implementation complexity of resolution-specific policy amounts to a need to augment these paths with the resolution-restriction information (downscaling / restriction).

Even some more “traditional” implementations may not support what would be required.

​Can you elaborate ?​

It feels like we have different models of how the Fake Key IDs could work.

I am assuming that a license is provide to the CDM containing a single key that indicates (say) that SD output is allowed without HDCP but that HD requires HDCP. The CDM must then expose two key ids, the real one and the fake one. The choice of fake key id is made in the CDM and needs to be made in an interoperable way - we would need to specify that. The absence of such a specification is an interoperability problem as every CDM will choose to do it in a different way.

Thanks for clarifying your model. I was assuming that the application's server would ask the key system’s license server to issue a license containing the real key and the fake key. Thus, the content provider would be in complete control of the IDs.

​This implies updates to the portions of the CDM subject to robustness rules and to the server peer as well.

What I'm proposing, in terms of exposing additional key status information, requires updates only to the part of the CDM not subject to robustness rules, since these indications are already available on the API surface of existing DRMs (as far as I understand).​

​I suppose one could imagine introducing a non-robust shim around an existing license format to carry this information, but that seems unnecessarily complex.​

I don’t see a reason for the CDM to generate the ID - if the CDM can be

updated to do that, it can (be updated to) accept a license with multiple keys.

​Those are very different kinds of update - as noted above.​ One could reasonably expect the key status changes I proposed to get dropped into a forthcoming CDM release for any given CDM, but support of multiple keys with seamless switching is a major subject-to-robustness client and server-affecting feature which we have always been told is a long way off.

This is also a step towards addressing issue #23 https://github.com/w3c/encrypted-media/issues/23, which I’m guessing also affects such CDM implementations.

— Reply to this email directly or view it on GitHub https://github.com/w3c/encrypted-media/issues/22#issuecomment-76244625.

[ddorwin]

To summarize:

@mwatson2’s reply above appears to assume the following:

• All/most CDM implementations support content-dependent policies.
• All/most CDM implementations support downscaling (and/or this is required by the spec), so they already interact with resolutions.
• It is reasonable to require the above of all future UA/CDM implementations.
• Thus, it is reasonable to expose the resolution information.

The first two are not true. I do not believe the third is reasonable, and we would object to it. Thus, the fourth will not be consistently supported, and the spec should not encourage authors to rely on it.

For example, attempting to require that the entire user agent and/or web application execution environment be locked down in a server-verifiable way.

... But, still, I don't understand how content-dependent policies lead to this consequence ? Resolution-dependent policies are implemented today without this consequence.

As I said before, the use of the same key for different policies, which is the source of the desire for content-dependent policies, compromises the security of the streams. I’m not confident your assertion about “today” is accurate; regardless, there have been attempts to push clients in that direction.

Existing CDMs already support resolution-dependent policies.

Some DRM clients on some platforms. As I said, this is not as widespread as you seem to think.

It's not clear to me that the solution space is at all restricted.

As someone familiar with the solution space on a variety of modern platforms, I’m saying this is restrictive and unreasonable.

Some things may be more complex from an implementation perspective, but nothing is rendered impossible or impractical.

It is no less “impossible or impractical” for a content provider to solve the issues on problematic devices or serve different streams to them. At least that would limit the burden to the provider that created the problem rather than heaving that burden on every UA produced in the future.

Downscaling of already-buffered content based on output protection status is a clear user-affecting use-case where knowledge of the resolution restriction is required after decode (to perform the downscaling). Assuming this use-case is supported I cannot see how the indications I proposed above add any restrictions or even significant complexity. Even if this use-case is not supported, the architectural implications seem minor.

Support for downscaling is explicitly optional, and applications are advised not to rely on it. This is for the exact same reasons - not all clients will or can reasonably implement support for downscaling.

It’s disappointing to again see a preference for restricting all future web platform clients rather than working to resolve (or encourage resolution of) known limitations. These issues have been known for a long time and could have been previously addressed rather than forcing kludges and pain on all other implementations. As noted below, at least one content provider appears to have confronted and resolved this issue.

​Many things are disappointing. But again, I don't believe you've demonstrated any significant "restrictions" being imposed on future clients: we're talking about exposing indications based on existing CDM functionality.​

There are current user-beneficial architectures/designs that do not support what would be required. Having to support what would be required would require changes that negatively affect users of such clients and restrict the possible client features, architectures, and designs.

We are not just “talking about exposing indications based on existing CDM functionality.” First, not all CDM implementations have this functionality to expose. Second, exposing this in the spec would imply to authors that they can rely on this functionality and use a single key for all streams when that should actually be avoided. For authors that choose to use a single key, there is the fake key ID option, which does not require any additional explicit support in the spec.

Widevine supports CENC and multiple keys. Also, I know there is a content provider doing seamless switching of CENC content on multiple devices (and not just with Widevine).

Fair enough. I'm not suggesting they need to make any changes.​

My point was that this content provider was able to use multiple keys with another major DRM system on a “CENC device” - one that likely also supports Netflix.

Certainly, we should be aware if we are crossing the complexity bar that causes people to choose non-compliance, but at the moment I don't see it being close to that at all, based on deployed functionality.

I’m not sure what subset of deployed functionality you are looking at, but there are multiple deployed platforms that do not and will not support this.

And, again, given the use-case of downscaling already-buffered content it is hard to see where, architecturally, such complexity could arise ?

As I said above, downscaling is optional for many of the same reasons. Requiring downscaling would place many of the same (and more) restrictions on implementations. However, downscaling is more of a quality of implementation issue because there are other options for authors on clients that do not support it.

The implementation complexity of resolution-specific policy amounts to a need to augment these paths with the resolution-restriction information (downscaling / restriction).

That is not practical on many clients.

​This implies updates to the portions of the CDM subject to robustness rules and to the server peer as well.

Not necessarily. For example, the necessary information could be contained in a wrapper around the actual license. Better yet, CDMs that only support one key per license should at least support bundling of licenses into a single session as is being discussed in issue #23. Thus, the wrapper would provide required functionality and not just a workaround for this issue.

What I'm proposing, in terms of exposing additional key status information, requires updates only to the part of the CDM not subject to robustness rules, since these indications are already available on the API surface of existing DRMs (as far as I understand).​

This assumes that such CDMs have a way to expose this information. For CDMs that don’t support the feature at all, this is clearly not possible. Other CDMs may not expose the necessary information from the parts subject to robustness rules. On the other hand, a fake key ID could definitely be implemented in other parts of the CDM or even the UA.

[alex-the-man]

Those are business rules, and it is fine to have business rules that depend on resolutions.

My suggestion does not expose business rules in the spec. It exposes the output protection status to the app. Business rules are still in the app.

a) expecting all CDMs to enforce decoded resolution (rather than just whether a key can be used)

The API can be optional instead of required. We can allow CDM to return "not-supported" to tell the app it doesn't support output protection. As the app developer also chooses the DRM solution they are using, this doesn't require additional handling.

b) exposing such business rules in the spec - we cannot and should not predict what policies and differentiations will be relevant in the future. Relying on separate keys allows any business rule to be implemented by the application and server (and for CDM implementations to evolve to meet new industry needs).

We are not predicting the future. Output protection is supported by most widely used DRMs at present.

[mwatson2]

On Thu, Mar 5, 2015 at 10:39 AM, ddorwin notifications@github.com wrote:

To summarize:

@mwatson2 https://github.com/mwatson2’s reply above appears to assume the following:

• All/most CDM implementations support content-dependent policies.
• All/most CDM implementations support downscaling (and/or this is required by the spec), so they already interact with resolutions.
• It is reasonable to require the above of all future UA/CDM implementations.
• Thus, it is reasonable to expose the resolution information.

The first two are not true.

​So, here we have a disagreement about a matter of fact which I trust we can clear up with more specific data. ​I can say that we use resolution-dependent policies with all of the DRMs that we support, in various contexts. Specifically, output protection requirements are resolution-dependent. Several DRMs support a feature in which we can restrict the resolution that can be decoded.

Downscaling is not as widely supported, that is true, however it is supported by some DRMs. This is not just a quality-of-implementation issues. Without downscaling, playback start is slower in the case that the already buffered data has to be discarded. In this respect it is just like any other optimization designed to improve playback start times, for example prefetching of licenses.

I do not believe the third is reasonable, and we would object to it.

​I am not arguing that the specification require the support of resolution-dependent policies. The types of policies supported vary from DRM to DRM in a number of ways. Of course this is indeed an interoperability concern and to the extent we can use the EME specification to address this - by harmonizing capabilities - that is a good thing. But I imagine there will remain keysystem-specific capabilities for some time to come.

It is the case that Netflix requires the support of resolution-dependent policies because, as I have explained, the install base of devices that do not support multiple keys and the need to share streams for efficiency, makes it impractical for us to migrate to a multi-key solution. But I'm not arguing that the specification require all the things Netflix requires. I'm just saying that if several DRMs already support something and it is easy to expose that through the API, we should do so in a clean way.

Thus, the fourth will not be consistently supported, and the spec should not encourage authors to rely on it.

​What I am suggesting is that where CDMs support resolution-dependent policies, we have a standard way to expose the indications that enable optimization of the downloaded data. Authors know the nature of the policies they embed in the licenses they deliver, so from an authors' point of view the behavior will be completely consistent.

For example, attempting to require that the entire user agent and/or web application execution environment be locked down in a server-verifiable way.

... But, still, I don't understand how content-dependent policies lead to this consequence ? Resolution-dependent policies are implemented today without this consequence.

As I said before, the use of the same key for different policies, which is the source of the desire for content-dependent policies, compromises the security of the streams.

​What constitutes a security compromise ​is not something we can adjudicate here. Robustness rules are very complex and in the end come down to judgement calls as to the difficulty and consequences of various attacks. There are typically many ways to achieve the security objectives of the system.

I’m not confident your assertion about “today” is accurate; regardless, there have been attempts to push clients in that direction.

Existing CDMs already support resolution-dependent policies.

Some DRM clients on some platforms. As I said, this is not as widespread as you seem to think.

​It's true that I only know about our own system in detail. But certainly thousands of distinct types of device receive millions of hours of content every day using a variety of DRMs relying on this technique.

It's not clear to me that the solution space is at all restricted.

As someone familiar with the solution space on a variety of modern platforms, I’m saying this is restrictive and unreasonable.

Again, I'm not suggesting that the specification require this approach. But I think we need more than assertions to justify not supporting it at all.

Some things may be more complex from an implementation perspective, but nothing is rendered impossible or impractical.

It is no less “impossible or impractical” for a content provider to solve the issues on problematic devices or serve different streams to them.

​It is certainly impractical, since it implies duplicating streams. The whole point of EME adopting Common Encryption was to enable sharing of streams. Without this, EME itself would be impractical. If you impose requirements that imply EME devices need different sets of streams from other Common Encryption devices this imposes significant ongoing efficiency costs for the duplicate streams. Ongoing costs trump one-off engineering and site authors rank higher in the priority of constituencies than UA implementors.

At least that would limit the burden to the provider that created the problem rather than heaving that burden on every UA produced in the future.

Downscaling of already-buffered content based on output protection status is a clear user-affecting use-case where knowledge of the resolution restriction is required after decode (to perform the downscaling). Assuming this use-case is supported I cannot see how the indications I proposed above add any restrictions or even significant complexity. Even if this use-case is not supported, the architectural implications seem minor.

Support for downscaling is explicitly optional, and applications are advised not to rely on it. This is for the exact same reasons - not all clients will or can reasonably implement support for downscaling.

​Sure, it's a play start time optimization. Just like pre-fetching of licenses. Both of these things may or may not be supported, but where​ they are supported they should be supported in a consistent, standard, way.

It’s disappointing to again see a preference for restricting all future web platform clients rather than working to resolve (or encourage resolution of) known limitations. These issues have been known for a long time and could have been previously addressed rather than forcing kludges and pain on all other implementations. As noted below, at least one content provider appears to have confronted and resolved this issue.

​Many things are disappointing. But again, I don't believe you've demonstrated any significant "restrictions" being imposed on future clients: we're talking about exposing indications based on existing CDM functionality.​

There are current user-beneficial architectures/designs that do not support what would be required. Having to support what would be required would require changes that negatively affect users of such clients and restrict the possible client features, architectures, and designs.

​Can you elaborate ?​

We are not just “talking about exposing indications based on existing CDM functionality.” First, not all CDM implementations have this functionality to expose. Second, exposing this in the spec would imply to authors that they can rely on this functionality and use a single key for all streams when that should actually be avoided.

​As I said above, authors are well aware of what DRM functionality they can rely on and what they cannot, because it is the author who crafts the license itself. So I don't see a problem here.​

I dispute the assertion that using a single key should be avoided. This is your opinion, but we have had large scale empirical success with this approach. That's not at all to say that multiple keys don't have advantages but just that there are multiple ways to achieve the required security objectives, some of which don't involve multiple keys.

For authors that choose to use a single key, there is the fake key ID option, which does not require any additional explicit support in the spec.

​I don't think a widely supported and perfectly adequate solution should be relegated to a second class kludge in the specification. The convenience of not requiring any explicit support in the specification is at the very bottom of the priority of constituencies. Also, see discussion below.​

Widevine supports CENC and multiple keys. Also, I know there is a content provider doing seamless switching of CENC content on multiple devices (and not just with Widevine).

Fair enough. I'm not suggesting they need to make any changes.​

My point was that this content provider was able to use multiple keys with another major DRM system on a “CENC device” - one that likely also supports Netflix.

​Still, ​that doesn't negate any of the points I make above.

Certainly, we should be aware if we are crossing the complexity bar that causes people to choose non-compliance, but at the moment I don't see it being close to that at all, based on deployed functionality.

I’m not sure what subset of deployed functionality you are looking at, but there are multiple deployed platforms that do not and will not support this.

​Again, I'm not sure how that is relevant to the discussion. There are various things that a platform must support in order to support a specific service, such as Netflix. If some platforms don't support all the things needed for a given service, then that service won't be supported on that platform. But this has nothing to do with the specification.

And, again, given the use-case of downscaling already-buffered content it is hard to see where, architecturally, such complexity could arise ?

As I said above, downscaling is optional for many of the same reasons. Requiring downscaling would place many of the same (and more) restrictions on implementations. However, downscaling is more of a quality of implementation issue because there are other options for authors on clients that do not support it.

The implementation complexity of resolution-specific policy amounts to a need to augment these paths with the resolution-restriction information (downscaling / restriction).

That is not practical on many clients.

​This implies updates to the portions of the CDM subject to robustness rules and to the server peer as well.

Not necessarily. For example, the necessary information could be contained in a wrapper around the actual license. Better yet, CDMs that only support one key per license should at least support bundling of licenses into a single session as is being discussed in issue #23 https://github.com/w3c/encrypted-media/issues/23. Thus, the wrapper would provide required functionality and not just a workaround for this issue.

What I'm proposing, in terms of exposing additional key status information, requires updates only to the part of the CDM not subject to robustness rules, since these indications are already available on the API surface of existing DRMs (as far as I understand).​

This assumes that such CDMs have a way to expose this information. For CDMs that don’t support the feature at all, this is clearly not possible. Other CDMs may not expose the necessary information from the parts subject to robustness rules. On the other hand, a fake key ID could definitely be implemented in other parts of the CDM or even the UA.

​If a CDM vendor introduces a non-robust wrapper of the kind described above with which to communicate the "fake key ids", then information about resolution-dependent policies still needs to be exposed on the API surface of the robust portion of the CDM, in order to drive the key status map to show the correct status for the fake ids.

So this solution also relies on the requirement that CDMs supporting such policies expose the necessary indications on the API surface of the robust component.

Since that's a given in both approaches, the approach of exposing explicit indications in the key status map has the advantage that only client side changes are required and does not involve the development of a whole new protocol layer. The "fake key ids" approach seems like an excessive amount of work for a kludgy outcome.

What I would like to see is an approach where if resolution-dependent policies are supported by a key-system then we have a ​simple standard way to expose when they are active, without needing server-side and protocol changes which are completely unnecessary to this goal. (and capability detection for resolution-dependent policies is a server-side issue that need not concern us in the EME specification.)

…Mark

— Reply to this email directly or view it on GitHub https://github.com/w3c/encrypted-media/issues/22#issuecomment-77422846.

[ddorwin]

My suggestion does not expose business rules in the spec. It exposes the output protection status to the app. Business rules are still in the app.

Can you clarify your proposal? Are you suggesting exposing the current output protection level (i.e. HDCP 1.4, HDCP 2.2) via a separate API? Where would this API would be added? Where would the set of values be documented and how would it be updated?

a) expecting all CDMs to enforce decoded resolution (rather than just whether a key can be used)

The API can be optional instead of required. We can allow CDM to return "not-supported" to tell the app it doesn't support output protection. As the app developer also chooses the DRM solution they are using, this doesn't require additional handling.

Unless there is an alternative solution, it would be a de facto requirement. I don't understand how the selection of the key system is related.

b) exposing such business rules in the spec - we cannot and should not predict what policies and differentiations will be relevant in the future. Relying on separate keys allows any business rule to be implemented by the application and server (and for CDM implementations to evolve to meet new industry needs).

We are not predicting the future. Output protection is supported by most widely used DRMs at present.

We would be predicting that output protection is the only feature that will need to be exposed independent of a key ID. (Also, that it will be the only resolution-dependent policy.) Also, we'd need to determine which output protection protocols are supported and how support for new ones is added to the spec. Relying on key IDs and policies does not have this problem.

While exposing output protection levels would avoid the need for the CDM to expose resolution(-based) information to the application, there is still the underlying problem of requiring CDMs to "restrict the resolution that can be decoded" to support use of a single key for multiple output protection levels. I believe this the whole reason that we wouldn't just use key IDs as the spec supports today.

Note: Checking whether HDCP 2.2 is supported via such an API is equivalent to checking the status of a key that requires HDCP 2.2 (for all resolutions). Thus, it doesn't seem much better. If an implementation can implement such an API, it should be able to abstract that into a separate key ID too.

[ddorwin]

While exposing output protection levels would avoid the need for the CDM to expose resolution(-based) information to the application, there is still the underlying problem of requiring CDMs to "restrict the resolution that can be decoded" to support use of a single key for multiple output protection levels. I believe this the whole reason that we wouldn't just use key IDs as the spec supports today.

On second thought, I don't think resolution restrictions are always related to output protection. Thus, providing access to the output protection level would not address Mark's single-key issue.

[mwatson2]

On Fri, Mar 6, 2015 at 2:05 PM, ddorwin notifications@github.com wrote:

While exposing output protection levels would avoid the need for the CDM to expose resolution(-based) information to the application, there is still the underlying problem of requiring CDMs to "restrict the resolution that can be decoded" to support use of a single key for multiple output protection levels. I believe this the whole reason that we wouldn't just use key IDs as the spec supports today.

On second thought, I don't think resolution restrictions are always related to output protection. Thus, providing access to the output protection level would not address Mark's single-key issue.

​There are two kinds of resolution restrictions that may be included in a license: (a) those that are ​dependent on things the application is already aware of (b) those that are dependent on things the application is not aware of

(a) might include a flat policy that only SD content is allowed. or a policy based on DRM robustness level, which is know as part of capability discovery. The DRM is expected to enforce these, but the application is fully aware of the policy and when it applies and so it's acceptable for the DRM just to fail playback if the application feeds the wrong content.

(b) might include output-protection-dependent resolution restrictions. The application is aware of the nature of the policy, but not of the output protection status. In this case, either the application needs to know the output protection status (from which it can derive the resolution restriction) or it just needs to know the resolution restriction that applies (from which it could derive the output protection status).

If we indicate the resolution restriction, we handle any other examples under (b). I don't have a good example other then output protection to hand, but one could imagine availability of certain secure resources having this kind of effect.

…Mark

— Reply to this email directly or view it on GitHub https://github.com/w3c/encrypted-media/issues/22#issuecomment-77644861.

[ddorwin]

I agree. Since the output protection level only addresses (known instances of) (b), I think it is a red herring. It's also worth noting that a CDM implementation could enforce output protection without being able to enforce or report resolution restrictions.

This discussion is really about requiring enforcement of resolution restrictions and exposing the status of those restrictions. I'll update the title, which is very obsolete at this point.

Perhaps (a) doesn't require exposing the information to the app like (b) does, but it still requires enforcement, which is 99% of the problem.

[mwatson2]

On Fri, Mar 6, 2015 at 2:52 PM, ddorwin notifications@github.com wrote:

I agree. Since the output protection level only addresses (known instances of) (b), I think it is a red herring. It's also worth noting that a CDM implementation could enforce output protection without being able to enforce or report resolution restrictions.

This discussion is really about requiring enforcement of resolution restrictions and exposing the status of those restrictions. I'll update the title, which is very obsolete at this point.

​As I said before, I'm not proposing that the EME specification require CDMs to support resolution-dependent policies. What I'm proposing is that when a CDM does support resolution-dependent policies it should be able to expose the resolution restrictions in place at any given time in a simple standard manner.

…Mark

Perhaps (a) doesn't require exposing the information to the app like (b) does, but it still requires enforcement, which is 99% of the problem.

— Reply to this email directly or view it on GitHub https://github.com/w3c/encrypted-media/issues/22#issuecomment-77651143.

[ddorwin]

​As I said before, I'm not proposing that the EME specification require CDMs to support resolution-dependent policies. What I'm proposing is that when a CDM does support resolution-dependent policies it should be able to expose the resolution restrictions in place at any given time in a simple standard manner.

Your earlier reply implies that all clients could enforce resolution restrictions with a little "one-off engineering." This is simply not true on a variety of modern platforms, and we must not exclude such clients and their users.

Unlike downscaling or other optional features or quality of implementation issues, there is no fallback or alternative mechanism for applications that rely on resolution-dependent policies to support clients that cannot support them. Optional features in specs are also generally frowned upon for good reason.

[mwatson2]

Can we adjust the title to "Allow" CDMs instead of require ..., since that is the request.

All I can say about segmentation here is that if a service provider requires support of resolution-dependent policies - because that is what their content contracts say - then that service will not work with CDMs that don't support resolution-dependent policies - at least for better than SD. That's true whether or not we have explicit support in the specification.

Given that such policies already exist for multiple CDMs and show no signs of being removed from studio contracts (indeed they are increasing), I think we should have a consistent way of exposing them.

[mwatson2]

After some internal discussion and review of CDM capabilities, it seems that imposing uniformity in terms of how resolution-dependent policies are defined (for example exposing "HD" and "UHD" values explicitly in our API) would be very difficult.

It is still the case that CDMs support various forms of resolution-dependent policy, the simplest of which being that a license may only be used up to a specified maximum resolution.

I still think it is useful for keystatus to distinguish the following four output protection cases:

• the key is usable for all content ("usable")
• the key is not usable at all ("output-not-allowed")
• the key is usable for some content and other content will be downscaled ("output-downscaled")
• the key is usable for some content and other content will be blocked

We have values for the first three, so my proposal for resolving this issue is to introduce a single additional value (say "output-restricted").

It will be up to the application to combine this information with facts it knows about the policies it provided to determine the appropriate response.

[mwatson2]

I've made my proposal in the form of a pull request, in case this helps.

[ddorwin]

Mark’s proposal is a good step forward and caused me to rethink our approach to statuses. I have a modified proposal below, followed by a discussion of the issues that led me to this conclusion.

Proposal

Replace output-not-allowed and output-downscaled with the new value, which would cover all cases where there are output restrictions that cannot be met, and therefore, the app should avoid using streams that will trigger this key’s output restrictions. This gives the app all the information it needs without having to define/add values for each possible restriction mechanism (or the potential for inaccurate names and descriptions). There would be two scenarios depending on the application design:

• In the basic case (different keys for different policies) formerly represented by output-not-allowed, the app would know that playback will fail if it ever uses that key.
• In other cases - covered by output-downscaled and this bug - the app would know that it it should not provide content that exceeds the limitations in the license.

Discussion

Reading Mark’s comment and pull request, it appears we need to clarify the expected behavior and intended usage of both the proposed new value and output-downscaled. Specifically, in which of the following three conditions would these values to be used?

1. Any time some output requirements (i.e. for any resolution) cannot currently be met, regardless of the current stream(s) (but some content can still be decrypted - otherwise it would be output-not-allowed)
2. When the output requirements cannot currently be met for the current stream(s)
3. When the output requirements can currently be met for the current stream(s) but not for other stream(s) (i.e. higher resolutions)

For output-downscaled, I thought the intent was 2. In other words, the current content is being downscaled. (In this definition, the status would be usable when the current content is not being downscaled.) Since playback would continue, it was basically a warning to the application to pick a different stream rather than waste resources. Thinking more about this, I see that this would really be a key-and-stream status, which is probably not ideal, both from an API and implementation flexibility point of view.

For the new value, 2 does not make sense because it’s too late to avoid affecting the user. One option is to go with 3 and use output-not-allowed (or output-downscaled if downscaling is supported) when, for example, a higher resolution stream is encountered.

In any case:

• usable would be used whenever there are no output requirements or all (i.e. for all resolutions) output requirements can currently be met.
• output-not-allowed would be used for keys whose output requirements cannot currently be met and thus cannot be used to decrypt any content^.

My interpretation (2) of output-downscaled was nice because it did not require the application to know the details of the license. However, a) it is more than just a key status, b) it doesn’t make sense to define the new value in the same way, and c) the application would probably want to have such knowledge to be able to jump down to the correct stream.

Using 1 for both seems okay, if that’s what others prefer. If so, I wonder whether there is value in differentiating “downscaled” from other reasons not to use streams that are incompatible with the current state. Likewise, output-not-allowed is nearly indistinguishable from 1 - note how complex I had to make the two definitions. See my proposal above.

^ “Any content” and “The key is not currently usable to decrypt media data…” are not necessarily true for the intended use case (e.g. HDCP required) because the key could potentially be used to decrypt audio (depending on the implementation). Thus, the message that key use is “restricted” is probably most accurate across key systems and implementations.

[mwatson2]

With interpretation (1) the use-case for separate output-restricted and output-downscaled is where the application has already downloaded but not appended high-resolution data (playback has not started). If the key status is output-downscaled the application can start playback with the downloaded data and uses this indication to avoid downloading any more data of that resolution. If the status is output-restricted then it will have to discard the downloaded data and download lower resolution data instead.

Applications could become quite good at predicting what the status will be based on previous sessions, so the discard case will likely be rare and worthwhile for the startup time improvement that comes with fetching media data before the EME exchange is complete.

[ddorwin]

Note: According to the current spec text, (1) is the correct interpretation:

A key's status is independent of whether the key is currently being used and of media data.

To summarize:

• We should have an "output restricted" status that means some output requirement in the license for this key cannot currently be met (regardless of the content currently in use).
  • This includes output protection (e.g. HDCP) requirements at some or all resolutions.
• @mwatson2 would like to add an "output restricted so affected content will be downscaled" status.
  • This is a subset of the first status and would be used by implementations that support downscaling (when downscaling can avoid the restriction).

"output-restricted" seams reasonable for the first status (replacing the existing "output-not-allowed". "output-restricted-downscaled"would clearly indicate the relationship of the second to the first, but is a bit long and still doesn't convey "may be downscaled." We could leave it as "output-downscaled".

[mwatson2]

I think we still need the distinction between output-not-allowed and output-restricted. In the former case, output is not allowed at all - the session must be failed. In the second case at least some resolutions are allowed (and the application is expected to know which) so the session can continue at that resolution or below.

So, I still think the change should be to add output-restricted per my PR.

[ddorwin]

What does it mean that "the session must be failed?" There is no concept of failing a session. There can be multiple keys per session, and the output-related statuses can change during the lifetime of a session.

Is there a meaningful difference for applications between "not allowed at all" and allowed for only (for example) some resolutions? An application is either (for example) using resolution restrictions or not. Thus, it knows what "restricted" means. As I said in my proposal, the status means "the app should avoid using streams that will trigger this key’s output restrictions" (those restrictions could include any use) and "gives the app all the information it needs..."

In addition, "output is not allowed at all" would mean neither audio or video can be decrypted. Depending on the key system protocol, CDM implementation, and/or license, applications might get different statuses when using effectively identical policies.

[mwatson2]

Ok, I see what you are saying. So, we would keep output-downscaled and then replace output-not-allowed with output-restricted. The application is expected to know the nature of any potential output restriction, which could be a blanket restriction or a resolution-specific one.

[ddorwin]

Yes.

[mwatson2]

Ok, I've updated the PR.