Re: ACTION-7 Use cases

Replies inline --

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

On Dec 10, 2012, at 10:03 PM, David Dorwin <ddorwin@google.com<mailto:ddorwin@google.com>> wrote:

Thanks, Joe. Can you remind us exactly what change(s) you are requesting? I think this discussion came out of https://www.w3.org/Bugs/Public/show_bug.cgi?id=17660, but the recent discussion and use cases below seem to focus on obtaining credentials much more than providing an identity token for the license request. In the meantime, my questions and comments about the use cases are below.

[steele] My change request was to formalize the notion that a CDM can communicate with the application via the "set key" and "key request" messages by the use of a predefined URI scheme in the destinationURI. The "app" URI scheme would indicate a URI that the application should handle directly rather than trying to send to an external server. I further suggested that the CDM could request specific pieces of data using the parameters to the destinationURI (e.g. app://com.foo.keysystem?username&password). Here is the email - http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0076.html


Do I understand use case #1 correctly that?

 *   The video contains the license server URL (i.e. in the PSSH).
 *   The CDM provides the URL (destinationURL) to the application, which forwards the message to a license server for which the application does not have prior knowledge.
 *   The unknown license server tells the CDM to tell the application to request authentication in some specific way.

 *   The application requests authentication in that specific way.

[steele] Yes, I think you understand it.


This seems to use the CDM to avoid standardizing communication between the license server and application but still require standardizing communication between the CDM and application. The license server is at least associated with the CDM, so there is some limitation in the protocols it can implement.

[steele] Yes

Or does the Video Search Engine support any unknown key system? (Since the key systems must be specified when creating the MediaKeys object and the application doesn't know anything about the video, this doesn't seem possible.) Assuming there is a limitation in possible protocols and the application knows the key system, the license server and application could communicate via an established protocol to establish the authenitcation mechanism.

[steele] My assumption is that application should expect to deal with unknown key systems using canPlayType(). My understanding from previous conversations is that we do not want to tie an application to a particular CDM as much as possible. Since I believe that license servers and CDMs are relatively closely bound in any event, it makes sense for the CDM to interpret the license servers wishes in this matter.


How does the application know how to interpret the information about how the authentication should be done? This seems key-system specific, which means the communication has been standardized between the application and CDM rather than the server and application  Assuming both the CDM and server are for a known key system (as mentioned above), what is the benefit of standardizing the application with the CDM rather than the server?

[steele] I believe this is a benefit because:
1. I expect there to be far fewer CDMs than there are license server configurations.
2. In the specific use cases I described the application does not have any a-priori knowledge of the license server.
3. Some license servers will encode the request for additional information (e.g. user authentication) in a CDM-specific way (for example encrypted)


David

On Sun, Dec 9, 2012 at 6:01 PM, Joe Steele <steele@adobe.com<mailto:steele@adobe.com>> wrote:
There are three use cases I describe below for ACTION-7. All of them result in the same basic flow of messages between the various components.

Upon video selection, the CDM is engaged and there are three key exchanges:
* The first key exchange determines that authentication is needed.
* The second key exchange provides information to the application about how the authentication should be done.
* The third key exchange provides the required credentials to the key server and retrieves the final content key.

I included a variation of the authentication mechanism where in the second key exchange the app redirects to an authentication web site provided to the CDM by the key server, instead of gathering the credentials directly.

I published the diagrams via Google Docs. Hopefully everyone can access them. I can move them elsewhere as needed.

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


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