Bug 17658 - need procedure for selection of Key System
Summary: need procedure for selection of Key System
Status: RESOLVED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-30 03:44 UTC by Yang Sun
Modified: 2012-08-28 20:21 UTC (History)
4 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 03:44:44 UTC
If media element’s source attribute has a keySystem attribute then we use this as selected keySystem, this is OK.
If no selected KeySystem, the specification says “jump to Key Presence”

The question is :

At “jump to Key Presence” is a else if of “selected key system”, so here we have no idea about key system,
but in "jump to Key Presence", we are handling key already exist, so why before key system selected, we can have key?

We may need let app or CDM to analyze the initData to find the KeySystem, but I have not seen any text for Analyzing initData to generate key system here, or I miss something?

So where we select the Key System if no selected key system in media element?
Comment 1 Mark Watson 2012-07-03 23:05:34 UTC
The key system is selected with the call to generateKeyRequest(). If that keysystem is not supported (by the browser, or by the file) then the call will fail and the app can try a different keysystem.

Note that all three of the app, the file and the browser may support multiple keysystems. Only a keysystem in the intersection of these three sets may be used. There may still be more than one. The app needs to choose its favorite from that set, as there may be commercial implications of the choice for the app.

The way we chose to implement that was by allowing the app to attempt generateKeyRequest with different key systems, in preference order, until one succeeded.

That seems acceptable given that the set of keysystems in the intersection I describe above is likely to be very small (coming up with an example where there are 3, say, is already a challenge).
Comment 2 Yang Sun 2012-07-04 05:15:56 UTC
Thanks for your reply.

I guess you misunderstand my question.
My question is when encrypted block is detected by media element during resource fetch algorithm , 
how to choose the key system.

From specification,

In step 6 of section 5.1 encrypted block encounted
It is said if the media element has a selected key system, then use it,
If not, jump to key presence, there is no key system selection text  in step 9 Key Presence.
Step 9 only mentioned 3 choices: 1 key is available, 2 fire needKey event with “keySystem”,3 abort resource fetch procedure

What’s more, I think before the generateKeyRequest(KeySystem, initData) is called, the KeySystem is already
Selected, and the specification mentioned if KeySystem is null, it will throw a SYNTAX_ERROR.
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-generatekeyrequest











(In reply to comment #1)
> The key system is selected with the call to generateKeyRequest(). If that
> keysystem is not supported (by the browser, or by the file) then the call will
> fail and the app can try a different keysystem.
> 
> Note that all three of the app, the file and the browser may support multiple
> keysystems. Only a keysystem in the intersection of these three sets may be
> used. There may still be more than one. The app needs to choose its favorite
> from that set, as there may be commercial implications of the choice for the
> app.
> 
> The way we chose to implement that was by allowing the app to attempt
> generateKeyRequest with different key systems, in preference order, until one
> succeeded.
> 
> That seems acceptable given that the set of keysystems in the intersection I
> describe above is likely to be very small (coming up with an example where
> there are 3, say, is already a challenge).
Comment 3 David Dorwin 2012-07-09 19:23:01 UTC
The application always chooses the key system to use; the media element does not choose the key system. The only case where the UA "sets" the current key system is when a <source> element is used to select the source and the selected element specifies a "keySystem" attribute. Even in this case, though, the key system to use for a particular source was specified by the application and the UA is just processing the options.

(In reply to comment #2)
> From specification,
> 
> In step 6 of section 5.1 encrypted block encounted
> It is said if the media element has a selected key system, then use it,
> If not, jump to key presence, there is no key system selection text  in step 9
> Key Presence.
> Step 9 only mentioned 3 choices: 1 key is available, 2 fire needKey event with
> “keySystem”,3 abort resource fetch procedure

"key system" is a variable that is set to null in step 1. Thus, it will be null in the case you described.

> What’s more, I think before the generateKeyRequest(KeySystem, initData) is
> called, the KeySystem is already
> Selected, and the specification mentioned if KeySystem is null, it will throw a
> SYNTAX_ERROR.
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-generatekeyrequest
> > there are 3, say, is already a challenge).

Yes, the keySystem parameter is required for generateKeyRequest(). Whether this method has been successfully called before the needkey event is fired may affect which of the three options for setting the keySystem attribute is used.
Comment 4 Adrian Bateman [MSFT] 2012-08-28 20:21:41 UTC
By design, the API expects the application to try key systems in the order of preference until it finds one that works.