Re: [EME] Authentication to unknown license servers

On Fri, Jan 25, 2013 at 5:42 PM, Joe Steele <steele@adobe.com> wrote:

>
> [steele] Agreed.
>
> I think this is a useful example. Why don't we change the "Other Content
> Decryption Module" example to show the application processing the license
> server response in some way? Developers could otherwise assume that doing a
> simple XMLHttpRequest and pushing the results down into the CDM is this the
> only type of protocol supported, since that is what is shown for all the
> key acquisition examples.
>

Adding or modifying examples has come up several times, so I'd like to
address this. The examples are non-normative and not meant to be all
encompassing. They are intended to show how to use the APIs in simple and
common ways - selecting a key system, using each method, handling each
event, etc. This doesn't mean we shouldn't add or modify examples, but we
do not need to make sure they encompass all use cases. The EME spec
document probably already has more example text than the entire spec for
the media element, and this has not prevented people from implementing
advanced applications based on it.

Authentication and authorization are contained in the difference between
> these two.
>
>
> I don't completely agree with this. Authentication and authorization
> information may be in the initData and accessible to the CDM. If it is - it
> could be supplied to the application to allow it to execute the appropriate
> protocol.
>
> Let me give you an example. Assume my initData looks like this:
>
> <key_request>
> <contentId>9287219837</contentId>
>  <licenseServer>http://blah.example.com/keyserver/v4</licenseServer>
>  <licenseServerAuth>inbandUsernameAndPassword</licenseServerAuth>
> </key_request>
>
> In this case the CDM *could* tell the application how to authenticate, if
> it had a mechanism for doing so. It could tell the application that
> "usernameAndPassword" is expected in the key request. But we don't have a
> designated channel for this kind of communication and there is a risk that
> we will prevent the one channel that does exist from being used for this
> purpose.
>
> As I understand the use case, a media search engine  applicatoin might ask
the user to enter a password for an unrelated site so that the application
can send the password to a license server to get a license for the content?
That seems like a really bad idea from a security (and user conditioning)
point of view. Surely there are better authentication mechanisms and they
are better handled by the application and not permanently encoded in the
media. (What if the media owner wants to change the authentication
mechanism.)

While the initData could contain a lot of things, I don't think we should
necessarily expose everything that it might contain to the application.
There was a similar discussion of media metadata, such as ID3 tags, on
WHATWG. The initData is just another type of metadata. One proposal in that
case is that the application could parse the media itself. I think that's
perfectly reasonable if there is a key system- or application-specific need
to access the data. In the initData case, the amount of data to parse is
very small.