HTML Media -- 27 Nov 2012

<johnsim> http://www.w3.org/2001/12/zakim-irc-bot

<scribe> scribe:ddorwin

<scribe> scribe: ddorwin

adrianba: Any topics?

joesteele: Was the optional parameters for the key request discussed at TPAC

ddorwin: I think I gave a brief overview but we did not discuss because the interested parties weren't there.

joesteele: Don't need to change the spec to do what I want but want to make sure people understand the use model
... application and license server may not be connected or have a loose relationship.
... I'm not sure how this case would be solved.
... One option would be for the CDM to have access to the cookies, but that's not spelled out in the spec.

adrianba: Comment: As we have drilled into this at Microsoft, I think we're looking at a similar requirement, which is to be able to provide some information, which is probably opaque to the CDM, but we want to pass down to the CDM to be encrypted to be included in the first key message so it can be transferred to the service.

adrianb: The reason for this is for compatibility with existing use cases. PlayReady has this capability. Being able to pass the information in the same way is something we could work around but would require more changes to the license service.

adrianba: In your model, is access to the cookies a workaround or does the CDM use it?

joesteele: The CDM looks at part of the metadata and says "here is the license server you need to talk to".

… One possible response is I need more data.

… The CDM can respond in several ways. If it has the data, it responds. But the more common case is to pop up a password dialog.

joesteele: I don't see a way to do this in the standard today. It's general enough that I could do it, but there is no standard way.

adrianba: It sounds like you're saying the CDM does the network communication.

joesteele: It does today, but it doesn't have to.

… The CDM has no way of directly communicating with the application.

markw: Just wanted to point out that what adrianba and joesteele are describing are different.

… key-system independent vs. key-system specific

scribe: The spec is somewhat of a refactoring of how DRM systems work.

markw: Is it possible to do what you're describing at the application level.

joesteele: It is possible, but then you lose the whole benefit of the CDM. Every application would have to support it. If you used keys, they could be accessed by JavaScript.

… Everything the CDM does to authenticate itself would be exposed to the application.

markw: … the security comes from the CDM

joesteele: Let me see if I understand. If the CDM gets a "need more data" response, …..

johnsim: It would be really helpful for me to see 1 or 2 use cases that you see as not supported or awkward written down so we can look at them one at a time and see if what Mark describes addresses it.

… We have a bag of use cases that involve some sort of exchange of information with a license server today, and we're trying to make sure we don't create an API with EME that would cause a great upheaval as they migrate.

… Adrian referenced the discussion at Microsoft. The impact pointed out by the field people was the impact on the license servers, which include business logic.

… I would like to see use case, use case, use case.

joesteele: The fundamental weakness: There is an assumption that all the authentication needed can be done by the application a priori, and that's just not true.

… If you accept my contention that this is not true, then how do you deal with when you need authentication later.

<adrianba> ddorwin: DRM systems are going to need to change for use in a HTML stack

<adrianba> ... what about UI?

joesteele: The application would display the ui.

markw: It's not an assumption that authentication is done a priori; it's an assumption that the application does the authentication.
... (Application server can work with the license server and application.)
... So, one possible solution is the outer layers of the protocol are implemented at the application layers, and the core is secure in the server and CDM.

joesteele: The nasty parts of DRM are in the CDM, and this leaks them.
... And one goal is for applications to be CDM-independent.

markw: That's one possibliity.
... Many people do their own user authentication …..

adrianba: It sounds like for your requirements that you need significantly more information to pass into the CDM.

joesteele: No, I don't think that's true. It's more interesting for it to be able to happen later because that's the point when the license server - which I think is key-system dependent - is in place and may need to require additional information that the CDM does not have.

… It would be good to have some channel where the CDM can ask for more information and have a way to provide that information back.

… Nothing has to be changed for this to work. I can make it work today leveraging the URI mechanism.

… It would be a good thing that if you see a URI that follows these conventions, don't send it to the server. For example "app://".

johnsim: The generalization of the use case that I'm hearing is that you make a key request and the license server refuses to provide a key unless the user provides additional information, and the application is what has to provide that information.

… When the key is not provided, you need some generic way of telling the application not only that the key was not provided, but why.

joesteele: That's the general use case.

… It's not really a failure; it just indicates it needs another round.

johnsim: If you provided that information at session creation, similar to what adrianba described (stuffed in the license request, no need to parse or understand the format).

… But where it gets interesting is the CDM having to understand (collaborate) with providing the additional information.

johnsim: How do we get to resolution on this subject?

<adrianba> i have to leave for another appointment - i will make a concrete proposal for the opaque data idea and i'd like to then understand the specific technical delta from that to what joe wants

joesteele: One bit that would help to resolve: If there is some blessing of the proposed solution on my side (i.e. URI), some representation in the spec so developers can see it.

… In general, a more formal mechanism to address the case.

<markw> sorry - I'm somewhere noisy

… If everyone else thinks it's unusual (I don't think it is), then that's okay.

<markw> I think the uss-case can be addressed through appropriate factoring of the license server protocol and Adrian's proposal for opaque information embedded in the CDM messages

johnsim: In that model, the application doesn't know a priori that it needs this information. Sometimes it will be needed, sometimes it won't.
... It seems if could be handled in the application code if....

joesteele: Example: Website that has two types of videos - 1) let's say, Netflix. 2) An internal video server.

<markw> there's no assumption in the current specification that authentication is done before playback

… I don't want to provide the tokens ahead of time because that would be a security breach.

johnsim: It seems you would know when you develop the application which tokens are needed for which type of content.

joesteele: There is this assumption that there is a 1:1 correspondence between the license server and the application.

… In the 90% case, that's probably true - writing an app to display videos from example.com.

… But not in the application I described.

<markw> it's assumed that the application protocol is implemented in Javascript, not by the CDM, whether that is a protocol for talking to Netflix servers or a protocol for talking to Adobe license servers

johnsim: I think the different levels of authentication is less instructive. The aggregator case may be better. There is this additional information that is needed, and what it is depends on the media being played.

pal: In that particular use case, the aggregator knows that there are potentially two key servers and can adapt accordingly.

johnsim: I can see solving it in the application. It might be the same key server but needs different information (i.e. credentials vs. credentials and device your running on)

… The application could make the decision.

… But in the model joesteele is decribing, that decision occurs at the license server.

pal: As the aggregator, I know I have two different requirements. Therefore, I can create a single proxy server that offers a common interface to my two license servers so the application can be common.

… Which solution do people see as more likely - the proxy or an intelligent application that knows which license server it needs to talk to or which additional steps it needs?

joesteele: The use case I care about is a third case - it's no the application or server - it's the CDM.

… The metadata that's embedded has the URI and the aggregator does not have it.

… Content provider 1 and 2 may have their own license servers.

… The aggregator is just redirecting you to the license server.

pal: Why would the underlying content provider release the keys to the aggregator? You can't expect any aggregator to manage access to content willy nilly.

joesteele: There most likely will be a relationship, but I don't understand the issue about releasing keys.

pal: Content protection means the content can't be stolen, but that doesn't mean money doesn't exchange hands.

joesteele: If the license server can get information, it can know who to bill, etc.

johnsim: I think the conversation over the last 10 minutes shows that we really need documentation - a representative example - so that we can try to look at what various solutions might be.

… I think adrianba's proposal about having opaque data that can find it's way back to the server adds one arrow to the quiver, but it doesn't necessarily address the use case that you're concerned about.

…. I think it would be a lot easier to settle that if we had a well-defined description.

joesteele: Let me see if I can distill the two use cases and send them out this week.

pal: It would be helpful to have some diagrams of the various parties.

<scribe> ACTION: joesteele to Provide a well-defined description of the uses cases along with some diagrams showing the various parties. [recorded in http://www.w3.org/2012/11/27-html-media-minutes.html#action01]

<trackbot> Sorry, couldn't find joesteele. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.

https://www.w3.org/html/wg/media/track/users

https://www.w3.org/2005/06/tracker/users/my

<scribe> ACTION: ddorwin to Provide a well-defined description of the uses cases along with some diagrams showing the various parties. (ddorwin placeholder for joesteele) [recorded in http://www.w3.org/2012/11/27-html-media-minutes.html#action02]

<trackbot> Created ACTION-7 - Provide a well-defined description of the uses cases along with some diagrams showing the various parties. (ddorwin placeholder for joesteele) [on David Dorwin - due 2012-12-04].

<scribe> ScribeNick: ddorwin

<scribe> Meeting: HTML Media Task Force Teleconference

<scribe> Scribe: David Dorwin

<scribe> Meeting: HTML Media Task Force Teleconference

- DRAFT -

HTML Media

27 Nov 2012

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output