{minutes} HTML WG media telecon 2012-11-27 - EME

Minutes: http://www.w3.org/2012/11/27-html-media-minutes.html


   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                               HTML Media

27 Nov 2012

   See also: [2]IRC log

      [2] http://www.w3.org/2012/11/27-html-media-irc

Attendees

   Present
          +81.45.787.aaaa, +1.415.867.aabb, +1.425.202.aacc,
          +1.408.536.aadd, [Microsoft], Matt_Womer, pal,
          +1.425.614.aaee, ddorwin, joesteele, Mark_Vickers,
          +81.45.787.aaff

   Regrets
   Chair
          group

   Scribe
          ddorwin, David Dorwin

Contents

     * [3]Topics
     * [4]Summary of Action Items
     __________________________________________________________

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

      [5] 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

   <discussion of use cases>

   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
   [6]http://www.w3.org/2012/11/27-html-media-minutes.html#action0
   1]

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

      [7] http://www.w3.org/html/wg/media/track/users%3E.

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

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

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

      [9] 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
   [10]http://www.w3.org/2012/11/27-html-media-minutes.html#action
   02]

   <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

Summary of Action Items

   [NEW] 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
   [11]http://www.w3.org/2012/11/27-html-media-minutes.html#action
   02]
   [NEW] ACTION: joesteele to Provide a well-defined description
   of the uses cases along with some diagrams showing the various
   parties. [recorded in
   [12]http://www.w3.org/2012/11/27-html-media-minutes.html#action
   01]

   [End of minutes]