W3C home > Mailing lists > Public > public-html-media@w3.org > December 2012

Re: ACTION-7 Use cases

From: David Dorwin <ddorwin@google.com>
Date: Mon, 10 Dec 2012 22:03:01 -0800
Message-ID: <CAHD2rsjLQux+HEzCLJazYK_JgObOEQ0ECLJ1BV50Ly9a47_snw@mail.gmail.com>
To: Joe Steele <steele@adobe.com>
Cc: "<public-html-media@w3.org>" <public-html-media@w3.org>
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.

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.


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

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?

David

On Sun, Dec 9, 2012 at 6:01 PM, Joe Steele <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
>
>
Received on Tuesday, 11 December 2012 06:03:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:57 UTC