Bug 17660 - need token relative with user identity for a new generateKeyRequest parameter
need token relative with user identity for a new generateKeyRequest parameter
Status: RESOLVED MOVED
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions
unspecified
PC Windows NT
: P2 normal
: ---
Assigned To: Adrian Bateman [MSFT]
HTML WG Bugzilla archive list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-30 07:56 UTC by Yang Sun
Modified: 2013-12-17 22:03 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yang Sun 2012-06-30 07:56:09 UTC
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.
Comment 1 David Dorwin 2012-07-03 19:38:25 UTC
(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
Comment 2 Adrian Bateman [MSFT] 2012-07-10 16:01:25 UTC
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.
Comment 3 Joe Steele 2012-09-04 20:01:36 UTC
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?
Comment 4 Joe Steele 2012-10-31 15:41:19 UTC
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.
Comment 5 Adrian Bateman [MSFT] 2013-12-13 00:49:04 UTC
I believe we should close this bug and use Bug 24082 to drive the conversation. I am resolving MOVED.