Re: [EME] Authentication to unknown license servers

On Jan 22, 2013, at 11:19 AM, Joe Steele wrote:

I will try to gather the various threads into one here. The bug currently representing this discussion is 17660 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=17660), however we may want to close that and open a new one that is more focused on this discussion.

As a response to ACTION-7 I put forward several use cases which I do not feel are addressed by the current spec.

The uses cases are below:
Use case #1 -- Video Search Engine
This is a video search engine site which incorporates a player. The user enters search terms and is provided with a selection of matching videos from possibly unknown sources. These sources may use various key systems. The application has no way of knowing in general what server to authenticate to or which key servers will be contacted prior to playback. The URI to the video is a raw content link or playlist, not a link to a publishers website (if there is such a site).

Version #1
https://docs.google.com/drawings/pub?id=15dnxQHHSTY64YSnMSihfBa9w-oxCVuOsFUBOfBMJDVY&w=960&h=720

Version #2
https://docs.google.com/drawings/pub?id=1Zlk6R8Lz1iI_NHIcMs-2DNBkED2qjLZpYYsQ6ymxVfI&w=960&h=720

-------------------
Use case #2 -- Online Storage Player
This is an online storage site which provides a video playback feature allowing users to upload secured content or just playlists. The user opens up their private storage area and selects a video or playlist from among those they have uploaded. The application has no way of knowing in general what server to authenticate to or which key servers will be contacted prior to playback.

https://docs.google.com/drawings/pub?id=1ybZ1tDbrwO9jX372nSpJuQKnAzdtSTJ5dmVuZLwM4kA&w=960&h=720

-------------------
Use case #3 -- Social Media Player
This is an social networking site which allows for users to share links to secured content and play back the content in a branded player provided by the site. The application has no way of knowing in general what server to authenticate to or which key servers will be contacted prior to playback. The URI to the video is a raw content link or playlist, not a link to a publishers website (if there is such a site).

https://docs.google.com/drawings/pub?id=1H4wHvOxdrhU9aTqQG-2mZIPzZtgmag_GvNMcfXpeBRU&w=960&h=720

The common thread to these use cases is that the application has no idea what license server will be communicated with prior to getting the key message from the CDM. And just based on the destinationURI it may not be possible for the application to know how to authenticate to the license server.

I think the main point of confusion here is that just based on the destinationURI is it not possible for the application to even know how to communicate with the license server at all: i.e. what protocol to use.

Wherever this protocol is specified - be it some standard license server protocol or a proprietary license server protocol - that same specification can include authentication details.


I propose we solve this by allowing the CDM to request data directly from the application via a pre-defined URI scheme.

Here is an example of the sequence of events:
* A media source is loaded and the media stack decides it needs a key.
* The application decides that it wants to use the "com.foo.keysystem" keysystem.
* The application calls createSession, passing the initData from the media stack.
* The CDM then examines the initData and determines that an in-band authentication needs to occur.
* The CDM then fires a needkey event setting the destinationURI to be something like "app://com.foo.keysystem?username&password".
* The app is watching for destinationURIs beginning with "app://" which it then handles directly rather than resulting in an network request.
* The app parses the URI into the keysystem and the request portions.
* The app then decides how it wants to respond to the key request and returns the information requested via the addKey method.
* The CDM constructs a key message which can be sent on to the key server without further intervention from the application.

Note that this mechanism can be extended to allow the CDM to convey other (possibly key-system specific) bits of information that the application may need.

If the approach described above is acceptable, I would like to see some text blessing this approach in the spec. An FAQ question+answer with an example would be sufficient. We would also need to specify that the UA cannot filter these types of URIs.

If this approach is not acceptable, please propose an alternative approach.

The license server protocol specification can specify how authentication should be done. For example:

* A media source is loaded and the media stack decides it needs a key. It fires the need key event containing the initData.
* The application decides that it wants to use the "com.foo.keysystem" keysystem.
* The application calls createSession, passing the initData from the media stack.
* The CDM then fires a key message event, containing the license request
* The client app, which knows the license server protocol, constructs a request message containing the license request from the CDM, together with other information as required by that protocol
* The license server returns a failure message with the reason "Authentication Required"
* The client application obtains the needed user credentials and resends the request message, this time including the authentication credentials

The point is that the "license server protocol" is more than just the CDM keymessages. Authentication and authorization are contained in the difference between these two.

…Mark


Joe Steele
steele@adobe.com<mailto:steele@adobe.com>