This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
key server should know the keymessage is from who. So I think app can generate a token based on account infor of user in web portal. Thus the generateKeyRequest may change to generateKeyRequest(KeySystem,initData, token),then the CDM can bind the token into keymessage before return the keymessage to app. BTW: in 8.2 use section first question also mention about it.
(In reply to comment #0) > key server should know the keymessage is from who. > So I think app can generate a token based on account infor of user in web > portal. That is one possible scenario, but not all scenarios will involve such a token. > Thus the generateKeyRequest may change to > generateKeyRequest(KeySystem,initData, token),then the CDM can bind the token > into keymessage before return the keymessage to app. Such binding assumes that the key system / CDM can support it. > > BTW: in 8.2 use section > first question also mention about it. The answer to the question says, "The application can add this to the license request (sent via XMLHttpRequest in the examples) or send it to the CDM via generateKeyRequest() to be included in the license request." The last part of the sentence is referring to combining it into initData somehow (in a key system-specific way). It is TBD how well such combination will work. The intent was to not bake a specific scenario that not all key systems would support into the API. Still, we could consider adding some additional parameter if the combination doesn't work well or we want to ensure that the initData returned by the needkey event is always the same as the value passed to generateKeyRequest(). (It's not clear that the latter will always be the case anyway, especially depending on the outcome of [1].) [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673
Discussed in telcon: http://www.w3.org/2012/07/10-html-media-minutes.html#item06 Resolving LATER. Today we have a single binary initData blob that can combine application specific data including (but not limited to) user token. We should review this later once we have more implementation experience to understand if this is a common scenario for which a single binary blob is inconvenient.
I would like to reopen this bug. It would be useful to be able to have the application specify additional parameters (e.g. username, sessionNonce, etc.) when calling createSession(). These could then be incorporated into the key request in a CDM specific manner. This is important in cases where TLS is not being used for the authentication channel (perhaps due to scaling issues) and the authentication is instead passed in-band with the CDM key request, secured using CDM-specific mechanisms. How about something like an array of name-value pairs?
I proposed an alternate mechanism which does not require a new parameter to be added and seems to be more in keeping with the spirit of this spec here: http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0076.html Assuming everyone is ok with this -- I would like to see the example code and FAQ item added to the spec. I am happy to provide the text if needed.
I believe we should close this bug and use Bug 24082 to drive the conversation. I am resolving MOVED.