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