The format will likely need to specify the number of key IDs and/or key ID length.

This assumes that the list of key IDs would be meaningful to the underlying DRM without any accompanying metadata (i.e. PSSHs). This is not generally true.

Would this list include metadata associated with each key id? For example -- an associated PSSH?

(In reply to Joe Steele from comment #2)
> This assumes that the list of key IDs would be meaningful to the underlying
> DRM without any accompanying metadata (i.e. PSSHs). This is not generally
> true.

Maybe not in legacy implementations, but why couldn't such a DRM system add support for this?

> Would this list include metadata associated with each key id? For example --
> an associated PSSH?

No. The point is to not require the application to worry about PSSH boxes or otherwise be limited/complicated by container formats.

(In reply to David Dorwin from comment #3)
> (In reply to Joe Steele from comment #2)
> > This assumes that the list of key IDs would be meaningful to the underlying
> > DRM without any accompanying metadata (i.e. PSSHs). This is not generally
> > true.
> 
> Maybe not in legacy implementations, but why couldn't such a DRM system add
> support for this?

At least in the Primetime case, this is not possible. The metadata contains information about the license server(s) and how to communicate with them. So lacking this information, the list of key IDs could only be used to reference existing keys not to request new ones.

(In reply to Joe Steele from comment #4)
> (In reply to David Dorwin from comment #3)
> > (In reply to Joe Steele from comment #2)
> > > This assumes that the list of key IDs would be meaningful to the underlying
> > > DRM without any accompanying metadata (i.e. PSSHs). This is not generally
> > > true.
> > 
> > Maybe not in legacy implementations, but why couldn't such a DRM system add
> > support for this?
> 
> At least in the Primetime case, this is not possible. The metadata contains
> information about the license server(s) and how to communicate with them. So
> lacking this information, the list of key IDs could only be used to
> reference existing keys not to request new ones.

Do you mean URLs, etc.? Since the application handles the communication with the license server, couldn't it know the URLs, etc.?

(In reply to David Dorwin from comment #5)
> (In reply to Joe Steele from comment #4)
> > (In reply to David Dorwin from comment #3)
> > > (In reply to Joe Steele from comment #2)
> > > > This assumes that the list of key IDs would be meaningful to the underlying
> > > > DRM without any accompanying metadata (i.e. PSSHs). This is not generally
> > > > true.
> > > 
> > > Maybe not in legacy implementations, but why couldn't such a DRM system add
> > > support for this?
> > 
> > At least in the Primetime case, this is not possible. The metadata contains
> > information about the license server(s) and how to communicate with them. So
> > lacking this information, the list of key IDs could only be used to
> > reference existing keys not to request new ones.
> 
> Do you mean URLs, etc.? Since the application handles the communication with
> the license server, couldn't it know the URLs, etc.?

Yes and other information. The application may know some of the information, but it may not be able to use the information to create a valid key request. 

When talking about CENC, the key ID referred to in the TrackEncryptionBox (tenc) or the SampleGroupDescriptionBox (sgpd) is just a reference. The information about how to use the key ID to decrypt content is contained within the PSSH. If the PSSH is not present, in general the DRM does not have enough information to retrieve the key needed to decrypt the content.

(In reply to Joe Steele from comment #6)
> The
> information about how to use the key ID to decrypt content is contained
> within the PSSH. If the PSSH is not present, in general the DRM does not
> have enough information to retrieve the key needed to decrypt the content.

Are you referring to information related to key chaining and/or domain keys? CENC specifies AES-CTR mode, so it's unclear what else is necessary to map a key ID to a decryption key and apply it.

I wouldn't say that the key ID is not enough in general. There are plenty of services in production where it is.

(In reply to David Dorwin from comment #7)
> (In reply to Joe Steele from comment #6)
> > The
> > information about how to use the key ID to decrypt content is contained
> > within the PSSH. If the PSSH is not present, in general the DRM does not
> > have enough information to retrieve the key needed to decrypt the content.
> 
> Are you referring to information related to key chaining and/or domain keys?
> CENC specifies AES-CTR mode, so it's unclear what else is necessary to map a
> key ID to a decryption key and apply it.

This is simple key acquisition, no chaining required. This has nothing to do with the encryption mode. This is about giving the CDM the information it requires to retrieve the key. I can give you two examples of information that might be required - the URL of the license server and the certificate used to encrypt for it. 

> 
> I wouldn't say that the key ID is not enough in general. There are plenty of
> services in production where it is.

It would be more precise for me to say that there are significant services in production for which this does not hold true. 

I agree - there are some DRMs that do not require more than the key ID because they manage everything on the server side. There are certainly services that rely on those specific DRMs. 

However the reason the CENC spec is written the way it is, is that for many DRMs the key ID alone is not enough to specify how to retrieve the key.

(In reply to Joe Steele from comment #8)
> (In reply to David Dorwin from comment #7)
> > (In reply to Joe Steele from comment #6)
> > > The
> > > information about how to use the key ID to decrypt content is contained
> > > within the PSSH. If the PSSH is not present, in general the DRM does not
> > > have enough information to retrieve the key needed to decrypt the content.
> > 
> > Are you referring to information related to key chaining and/or domain keys?
> > CENC specifies AES-CTR mode, so it's unclear what else is necessary to map a
> > key ID to a decryption key and apply it.
> 
> This is simple key acquisition, no chaining required. This has nothing to do
> with the encryption mode. This is about giving the CDM the information it
> requires to retrieve the key. I can give you two examples of information
> that might be required - the URL of the license server and the certificate
> used to encrypt for it. 

An application using the mechanism proposed in this bug would likely know the URL and certificate. Bug 25201 proposes an interoperable way to provide such a certificate.

> > 
> > I wouldn't say that the key ID is not enough in general. There are plenty of
> > services in production where it is.
> 
> It would be more precise for me to say that there are significant services
> in production for which this does not hold true. 
> 
> I agree - there are some DRMs that do not require more than the key ID
> because they manage everything on the server side. There are certainly
> services that rely on those specific DRMs. 
> 
> However the reason the CENC spec is written the way it is, is that for many
> DRMs the key ID alone is not enough to specify how to retrieve the key.

As discussed in bug 17673 (starting at #15), relying on proprietary functionality in the PSSH box is problematic for EME's interop story. EME relies on commonly encrypted files, but that doesn't mean it uses or supports every possible feature of an external spec.

So if I am understanding you correctly - you are saying that EME should not support the PSSH component of the CENC spec either?

My implementation does require the PSSH material. It sounds like you have a specific DRM implementation in mind. If you would care to share the implementation details of that DRM (server and client) with the task force, we can review it and see if that makes requiring the PSSH unnecessary.

(In reply to David Dorwin from comment #9)
> As discussed in bug 17673 (starting at #15), relying on proprietary
> functionality in the PSSH box is problematic for EME's interop story. EME
> relies on commonly encrypted files, but that doesn't mean it uses or
> supports every possible feature of an external spec.

See also http://lists.w3.org/Archives/Public/public-html-media/2013May/0017.html

That is a great thread to point to. Folks reading that message should read the response from Mark Watson: http://lists.w3.org/Archives/Public/public-html-media/2013May/0018.html

The answer to the question Mark asks - "Do the DRM providers really *need* this DRM-specific header ... ?" is YES at least for many DRMs.

Assuming that the text around how a session is managed allows for data like the PSSH to be cached during a session, we could support this. It remains to be seen how this would be impacted by remove() but sounds like group consensus is that remove() can ignore this type of data.

As Adrian noted in the f2f, this could be used in the case, for example, where the key IDs are provided in a manifest. Then there is no need to go through the complexities of creating one or more PSSH boxes.

The main remaining work is to define the format - how to specify the number of key IDs and/or length of them.

I believe there are three basic options:

#1: Allow createSession() to accept a JavaScript object in addition to the Uint8Array option. Then, a JSON definition could be used and passed directly. (There are similar advantages to allowing an object for update() and the message event.)

#2 Use a JSON definition and serialize it into a Uint8Array using the Encoding API: http://encoding.spec.whatwg.org/#interface-textencoder

#3: Use a binary format.
For this option, I propose the following format:
 * 1-byte key ID length in bytes.
 * N key IDs, each that many bytes long.

If zero-based, this supports key ID lengths from 8 to 2048 in 8-bit steps. zero-based lengths might be confusing, in which case we might use one-based lengths. However, we'd lose support for 2048. Given the current dominant length of 128-bits, this is probably okay.

We also need to define a byte order.

I am not clear what problem this is solving. Why would an application need to just provide key IDs or aggregate multiple needkey events? Is this an *optional* feature? I think we need more discussion of the use case.

(In reply to Joe Steele from comment #17)
> I am not clear what problem this is solving. Why would an application need
> to just provide key IDs or aggregate multiple needkey events? Is this an
> *optional* feature? I think we need more discussion of the use case.

See comment #0 and comment #14 for the motivation. There are real applications that would prefer not to worry about PSSH boxes.

As with the other initialization data types, this is optional and detectable via isTypeSupported().

(In reply to David Dorwin from comment #18)
> (In reply to Joe Steele from comment #17)
> > I am not clear what problem this is solving. Why would an application need
> > to just provide key IDs or aggregate multiple needkey events? Is this an
> > *optional* feature? I think we need more discussion of the use case.
> 
> See comment #0 and comment #14 for the motivation. There are real
> applications that would prefer not to worry about PSSH boxes.

Comment 0 explains the motivation but not the use case this enables. Comment 14 is more informative but still does not explain why this is *needed* as opposed to just desired.

This could be done without changing the API at all. Assuming all the information is available to the application (e.g. license server URL, license server certificate, key IDs, content ID, key system), the application can send an "initData request" to a common server to generate an appropriate PSSH without involving the CDM. And then pass that PSSH into the createSession call.

> 
> As with the other initialization data types, this is optional and detectable
> via isTypeSupported().

Great.

There was a preference for #2 in the telecon today.

#2 is implemented in https://dvcs.w3.org/hg/html-media/rev/4c2719078d2f