Re: [EME] Authentication to unknown license servers

On Fri, Jan 25, 2013 at 5:42 PM, Joe Steele <steele@adobe.com<mailto:steele@adobe.com>> wrote:

[steele] Agreed.

I think this is a useful example. Why don't we change the "Other Content Decryption Module" example to show the application processing the license server response in some way? Developers could otherwise assume that doing a simple XMLHttpRequest and pushing the results down into the CDM is this the only type of protocol supported, since that is what is shown for all the key acquisition examples.

Adding or modifying examples has come up several times, so I'd like to address this. The examples are non-normative and not meant to be all encompassing. They are intended to show how to use the APIs in simple and common ways - selecting a key system, using each method, handling each event, etc. This doesn't mean we shouldn't add or modify examples, but we do not need to make sure they encompass all use cases. The EME spec document probably already has more example text than the entire spec for the media element, and this has not prevented people from implementing advanced applications based on it.

[steele] All the current examples show the same key server protocol. I think we need some variety to avoid implying that is the only protocol that should be supported. I suggest rewording one of the existing examples rather than writing a new one. I can write something up if you like for you to review.


Authentication and authorization are contained in the difference between these two.

I don't completely agree with this. Authentication and authorization information may be in the initData and accessible to the CDM. If it is - it could be supplied to the application to allow it to execute the appropriate protocol.

Let me give you an example. Assume my initData looks like this:

<key_request>
<contentId>9287219837<tel:9287219837></contentId>
<licenseServer>http://blah.example.com/keyserver/v4</licenseServer><http://blah.example.com/keyserver/v4%3C/licenseServer%3E>
<licenseServerAuth>inbandUsernameAndPassword</licenseServerAuth>
</key_request>

In this case the CDM *could* tell the application how to authenticate, if it had a mechanism for doing so. It could tell the application that "usernameAndPassword" is expected in the key request. But we don't have a designated channel for this kind of communication and there is a risk that we will prevent the one channel that does exist from being used for this purpose.

As I understand the use case, a media search engine  applicatoin might ask the user to enter a password for an unrelated site so that the application can send the password to a license server to get a license for the content? That seems like a really bad idea from a security (and user conditioning) point of view. Surely there are better authentication mechanisms and they are better handled by the application and not permanently encoded in the media. (What if the media owner wants to change the authentication mechanism.)

[steele] I agree that having the application capture third party authentication tokens is a bad idea. I was trying to construct a very simple example for illustrative purposes. The key concept is that initData can contain information indicating what protocol is to be performed.
Here is a trivial variation on the earlier example:

<key_request>
<content_id>9287219837</content_id>
<licenseServer>http://example.com/keyserver/v4</licenseServer>
<licenseServerAuth>redirect:http://example.com/auth<http://example.com/auth></licenseServerAuth>
</key_request>

In this example the _licenseServerAuth_ element tells the application to redirect to a specific URI for authentication instead. No new security issues there.


While the initData could contain a lot of things, I don't think we should necessarily expose everything that it might contain to the application. There was a similar discussion of media metadata, such as ID3 tags, on WHATWG. The initData is just another type of metadata. One proposal in that case is that the application could parse the media itself. I think that's perfectly reasonable if there is a key system- or application-specific need to access the data. In the initData case, the amount of data to parse is very small.

[steele] Ok, it sounds like we are agreed that the initData may contain key-system specific information that the application may need.

However since the initData may be partially encrypted, it may not be completely parseable by the application. It would make sense to allow the CDM which contains the necessary keys, to decrypt the initData when needed and expose the elements that the application needs via some channel.