[EME] Authentication to unknown license servers

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 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. 

Joe Steele
steele@adobe.com