16:05:17 <RRSAgent> RRSAgent has joined #html-media
16:05:17 <RRSAgent> logging to http://www.w3.org/2012/11/27-html-media-irc
16:05:50 <ddorwin> zakim, list
16:05:50 <Zakim> I see HTML_WG()11:00AM, Team_(dnt)16:00Z, T&S_EGOV(Eurasian)4:00AM, WAI_(WCAG2ICT)10:00AM, RWC_PEWG()11:00AM active
16:05:53 <Zakim> also scheduled at this time are WAI_PFWG(HTML_TF)11:00AM, RWC_WebEven()11:00AM, SW_(SPARQL)10:00AM, T&S_XMLSEC()10:00AM, SW_HCLS()11:00AM, SW_RIF()11:00AM, WAI_UAWG(CHAIRS)10:30AM,
16:05:53 <Zakim> ... Team_Validat()11:00AM, XML_ET-TF()11:00AM, HTML_WG(HTMLT)11:00AM, VB_VBWG()10:00AM
16:06:21 <johnsim> http://www.w3.org/2001/12/zakim-irc-bot
16:06:29 <Mark_Vickers> Mark_Vickers has joined #html-media
16:06:31 <ddorwin> zakim, list conferences
16:06:31 <Zakim> I see HTML_WG()11:00AM, Team_(dnt)16:00Z, T&S_EGOV(Eurasian)4:00AM, WAI_(WCAG2ICT)10:00AM, RWC_PEWG()11:00AM active
16:06:33 <Zakim> also scheduled at this time are WAI_PFWG(HTML_TF)11:00AM, RWC_WebEven()11:00AM, SW_(SPARQL)10:00AM, T&S_XMLSEC()10:00AM, SW_HCLS()11:00AM, SW_RIF()11:00AM, WAI_UAWG(CHAIRS)10:30AM,
16:06:33 <Zakim> ... Team_Validat()11:00AM, XML_ET-TF()11:00AM, HTML_WG(HTMLT)11:00AM, VB_VBWG()10:00AM
16:07:01 <ddorwin> zakim, this is HTML
16:07:01 <Zakim> ok, ddorwin; that matches HTML_WG()11:00AM
16:07:26 <ddorwin> zakim, who is here?
16:07:26 <Zakim> On the phone I see +1.415.867.aabb, +1.425.202.aacc, +1.408.536.aadd, [Microsoft], Matt_Womer, pal, ??P22, +1.425.614.aaee
16:07:28 <Zakim> On IRC I see Mark_Vickers, RRSAgent, Zakim, pal, joesteele, ddorwin, johnsim, glenn, odinho_, trackbot, matt
16:07:38 <ddorwin> zakim, aacc is me
16:07:38 <Zakim> +ddorwin; got it
16:07:54 <joesteele> Zakim, aadd is joesteele
16:07:55 <Zakim> +joesteele; got it
16:08:38 <ddorwin> scribe:ddorwin
16:08:45 <ddorwin> scribe: ddorwin
16:09:17 <ddorwin> adrianba: Any topics?
16:09:40 <ddorwin> joesteele: Was the optional parameters for the key request discussed at TPAC
16:09:57 <Zakim> +Mark_Vickers
16:10:49 <adrianba> adrianba has joined #html-media
16:10:53 <ddorwin> ddorwin: I think I gave a brief overview but we did not discuss because the interested parties weren't there.
16:11:26 <adrianba> zakim, mute ddorwin
16:11:26 <Zakim> ddorwin should now be muted
16:11:29 <ddorwin> joesteele: Don't need to change the spec to do what I want but want to make sure people understand the use model
16:11:33 <chriho> chriho has joined #html-media
16:12:38 <ddorwin> joesteele: application and license server may not be connected or have a loose relationship.
16:12:49 <adrianba> q+
16:12:53 <ddorwin> joesteele: I'm not sure how this case would be solved.
16:13:20 <ddorwin> joesteele: One option would be for the CDM to have access to the cookies, but that's not spelled out in the spec.
16:13:31 <adrianba> ack me
16:15:03 <johnsim> q+
16:15:07 <ddorwin> ddorwin has joined #html-media
16:15:23 <ddorwin> ddorwin has joined #html-media
16:15:29 <ddorwin> 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.
16:15:36 <ddorwin> 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.
16:16:11 <ddorwin> adrianba: In your model, is access to the cookies a workaround or does the CDM use it?
16:16:14 <adrianba> q?
16:16:43 <ddorwin> joesteele: The CDM looks at part of the metadata and says "here is the license server you need to talk to".
16:16:52 <ddorwin> … One possible response is I need more data.
16:17:26 <ddorwin> … 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.
16:17:31 <Zakim> + +81.45.787.aaff
16:17:57 <ddorwin> joesteel: 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.
16:18:14 <ddorwin> s/joesteel/joesteele/
16:18:42 <ddorwin> adrianba: It sounds like you're saying the CDM does the network communication.
16:18:52 <ddorwin> joesteele: It does today, but it doesn't have to.
16:19:14 <ddorwin> … The CDM has no way of directly communicating with the application.
16:19:43 <ddorwin> markw: Just wanted to point out that what adrianba and joesteele are describing are different.
16:20:09 <ddorwin> … key-system independent vs. key-system specific
16:20:26 <ddorwin> The spec is somewhat of a refactoring of how DRM systems work.
16:20:40 <ddorwin> s/The/... The/
16:20:59 <ddorwin> markw: Is it possible to do what you're describing at the application level.
16:21:36 <ddorwin> 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.
16:22:14 <ddorwin> … Everything the CDM does to authenticate itself would be exposed to the application.
16:22:16 <ddorwin> q+
16:22:34 <ddorwin> markw: … the security comes from the CDM
16:23:14 <ddorwin> joesteele: Let me see if I understand. If the CDM gets a "need more data" response, …..
16:23:19 <adrianba> ack next
16:24:04 <ddorwin> 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.
16:24:41 <ddorwin> … 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.
16:25:20 <ddorwin> … 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.
16:25:35 <ddorwin> … I would like to see use case, use case, use case.
16:26:00 <ddorwin> 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.
16:26:20 <ddorwin> … If you accept my contention that this is not true, then how do you deal with when you need authentication later.
16:26:21 <adrianba> ack next
16:27:31 <adrianba> ddorwin: DRM systems are going to need to change for use in a HTML stack
16:27:41 <adrianba> ... what about UI?
16:29:47 <ddorwin> joesteele: The application would display the ui.
16:30:11 <ddorwin> markw: It's not an assumption that authentication is done a priori; it's an assumption that the application does the authentication.
16:30:37 <ddorwin> markw: (Application server can work with the license server and application.)
16:30:52 <Mark_Vickers> Mark_Vickers has joined #html-media
16:31:15 <ddorwin> markw: 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.
16:31:36 <ddorwin> joesteele: The nasty parts of DRM are in the CDM, and this leaks them.
16:31:57 <ddorwin> joesteele: And one goal is for applications to be CDM-independent.
16:32:05 <ddorwin> markw: That's one possibliity.
16:32:50 <ddorwin> markw: Many people do their own user authentication …..
16:33:10 <ddorwin> adrianba: It sounds like for your requirements that you need significantly more information to pass into the CDM.
16:34:02 <ddorwin> 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.
16:34:25 <ddorwin> … 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.
16:34:49 <ddorwin> … Nothing has to be changed for this to work. I can make it work today leveraging the URI mechanism.
16:35:22 <ddorwin> … 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://".
16:36:15 <ddorwin> 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.
16:36:37 <ddorwin> … 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.
16:36:44 <ddorwin> joesteele: That's the general use case.
16:37:06 <ddorwin> … It's not really a failure; it just indicates it needs another round.
16:37:44 <ddorwin> 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).
16:38:09 <ddorwin> … But where it gets interesting is the CDM having to understand (collaborate) with providing the additional information.
16:38:36 <ddorwin> johnsim: How do we get to resolution on this subject?
16:39:01 <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
16:39:18 <ddorwin> 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.
16:39:25 <Zakim> - +1.425.614.aaee
16:39:26 <markw> markw has joined #html-media
16:39:37 <ddorwin> … In general, a more formal mechanism to address the case.
16:39:44 <markw> sorry - I'm somewhere noisy
16:39:56 <ddorwin> … If everyone else thinks it's unusual (I don't think it is), then that's okay.
16:40:09 <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
16:40:36 <ddorwin> 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.
16:40:39 <ddorwin> q+
16:41:04 <ddorwin> johnsim: It seems if could be handled in the application code if....
16:41:31 <ddorwin> joesteele: Example: Website that has two types of videos - 1) let's say, Netflix. 2) An internal video server.
16:41:44 <markw> there's no assumption in the current specification that authentication is done before playback
16:41:58 <ddorwin> … I don't want to provide the tokens ahead of time because that would be a security breach.
16:42:55 <ddorwin> johnsim: It seems you would know when you develop the application which tokens are needed for which type of content.
16:43:25 <ddorwin> joesteele: There is this assumption that there is a 1:1 correspondence between the license server and the application.
16:43:47 <ddorwin> … In the 90% case, that's probably true - writing an app to display videos from example.com.
16:44:04 <ddorwin> … But not in the application I described.
16:44:40 <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
16:44:59 <ddorwin> ack me
16:46:28 <ddorwin> <discussion of use cases>
16:47:25 <ddorwin> 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.
16:47:48 <ddorwin> pal: In that particular use case, the aggregator knows that there are potentially two key servers and can adapt accordingly.
16:48:41 <ddorwin> 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)
16:48:52 <ddorwin> … The application could make the decision.
16:49:11 <ddorwin> … But in the model joesteele is decribing, that decision occurs at the license server.
16:49:45 <ddorwin> 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.
16:50:41 <ddorwin> … 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?
16:50:59 <ddorwin> joesteele: The use case I care about is a third case - it's no the application or server - it's the CDM.
16:51:25 <ddorwin> … The metadata that's embedded has the URI and the aggregator does not have it.
16:51:40 <ddorwin> … Content provider 1 and 2 may have their own license servers.
16:51:55 <ddorwin> … The aggregator is just redirecting you to the license server.
16:52:26 <ddorwin> 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.
16:52:52 <ddorwin> joesteele: There most likely will be a relationship, but I don't understand the issue about releasing keys.
16:53:16 <ddorwin> pal: Content protection means the content can't be stolen, but that doesn't mean money doesn't exchange hands.
16:53:40 <ddorwin> joesteele: If the license server can get information, it can know who to bill, etc.
16:54:32 <ddorwin> 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.
16:55:05 <Mark_Vic_> Mark_Vic_ has joined #html-media
16:55:05 <ddorwin> … 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.
16:55:19 <ddorwin> …. I think it would be a lot easier to settle that if we had a well-defined description.
16:55:35 <ddorwin> joesteele: Let me see if I can distill the two use cases and send them out this week.
16:55:46 <ddorwin> pal: It would be helpful to have some diagrams of the various parties.
16:58:34 <ddorwin> ACTION: joesteele to Provide a well-defined description of the uses cases along with some diagrams showing the various parties.
16:58:34 <trackbot> Sorry, couldn't find joesteele. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.
16:58:42 <Zakim> -??P22
16:59:19 <ddorwin> https://www.w3.org/html/wg/media/track/users
16:59:52 <Zakim> -Mark_Vickers
16:59:53 <Zakim> -pal
16:59:54 <Zakim> - +81.45.787.aaff
16:59:58 <Zakim> -[Microsoft]
16:59:59 <Zakim> - +1.415.867.aabb
17:00:00 <Zakim> -Matt_Womer
17:01:36 <ddorwin> https://www.w3.org/2005/06/tracker/users/my
17:03:16 <ddorwin> ACTION: ddorwin to Provide a well-defined description of the uses cases along with some diagrams showing the various parties. (ddorwin placeholder for joesteele)
17:03:16 <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].
17:03:33 <ddorwin> rrsagent, generate minutes
17:03:33 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/27-html-media-minutes.html ddorwin
17:03:40 <Zakim> -joesteele
17:06:40 <ddorwin> rrsagent, generate minutes
17:06:40 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/27-html-media-minutes.html ddorwin
17:08:41 <Zakim> disconnecting the lone participant, ddorwin, in HTML_WG()11:00AM
17:08:43 <Zakim> HTML_WG()11:00AM has ended
17:08:43 <Zakim> Attendees were +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
17:08:50 <chriho> Zakim, what's the code?
17:08:50 <Zakim> the conference code is hidden, chriho
17:08:54 <ddorwin> Zakim, make logs public
17:08:54 <Zakim> I don't understand 'make logs public', ddorwin
17:09:11 <ddorwin> Zakim, make logs public
17:09:11 <Zakim> I don't understand 'make logs public', ddorwin
17:09:29 <matt> rrsagent, make logs public
17:10:03 <mike5> mike5 has joined #html-media
17:10:13 <mike5> Zakim, make logs public
17:10:13 <Zakim> I don't understand 'make logs public', mike5
17:10:22 <ddorwin> rrsagent, generate minutes
17:10:22 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/27-html-media-minutes.html ddorwin
17:11:22 <mike5> RRSAgent, make logs public
17:13:19 <ddorwin> Meeting: HTML Media
17:13:29 <ddorwin> Chair: group
17:14:24 <ddorwin> ScribeNick: ddorwin
17:14:40 <ddorwin> rrsagent, generate minutes
17:14:40 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/27-html-media-minutes.html ddorwin
17:16:07 <ddorwin> Meeting: HTML Media Task Force Teleconference
17:16:11 <ddorwin> Scribe: David Dorwin
17:17:09 <ddorwin> rrsagent, generate minutes
17:17:09 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/27-html-media-minutes.html ddorwin
17:20:21 <ddorwin> Meeting: HTML Media Task Force Teleconference
17:20:29 <ddorwin> rrsagent, generate minutes
17:20:29 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/27-html-media-minutes.html ddorwin