This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
At various stages of defining this spec, we have mentioned supporting domains. In order to support domains properly, there needs to be a way to select the domain to be associated with key requests when multiple acceptable domains exist. This is a choice that the content decryption module cannot always make directly and may require input from the web application or even the user. An example of this is when two domains are possible to choose from - but one domain costs money to join and the other does not (perhaps because the device is already a member). This could have been provided by bug 24025, but in lieu of that mechanism I propose the following be added to MediaKeys: void setLicenseDomain(DomString licenseDomain); If the CDM corresponding to the keySystem attribute does not support license domains, throw a NOT_SUPPORTED_ERR exception and abort these steps.
Actually I am going to modify my proposal. I think this would be better as part of the createSession() call than as a separate method, since this would apply to all requests for the session. So the method would look like this: MediaKeySession createSession(DOMString contentType, Uint8Array initData, optional DomString licenseDomain);
Joe, can you explain what a "domain" is, in terms that are independent of any particular DRM system ?
(In reply to Mark Watson from comment #2) > Joe, can you explain what a "domain" is, in terms that are independent of > any particular DRM system ? In DRM-generic terms, a domain (or "license domain") is a group of players for which a single content license can be issued. A domain key is a key that is used to encrypt content keys for delivery to players in the same domain.
(In reply to Joe Steele from comment #3) > (In reply to Mark Watson from comment #2) > > Joe, can you explain what a "domain" is, in terms that are independent of > > any particular DRM system ? > > In DRM-generic terms, a domain (or "license domain") is a group of players > for which a single content license can be issued. A domain key is a key that > is used to encrypt content keys for delivery to players in the same domain. So, the idea would be that a player from one origin gets a domain key and (possibly) licenses for the domain and then this information can be used by players from other origins that are part of the same domain ? How would this fit into the 'same origin' web security model ? What would be the mechanism for origins to prove that they are allowed access to keys / licenses associated with a specific domain ?
(In reply to Mark Watson from comment #4) > (In reply to Joe Steele from comment #3) > > (In reply to Mark Watson from comment #2) > > > Joe, can you explain what a "domain" is, in terms that are independent of > > > any particular DRM system ? > > > > In DRM-generic terms, a domain (or "license domain") is a group of players > > for which a single content license can be issued. A domain key is a key that > > is used to encrypt content keys for delivery to players in the same domain. > > So, the idea would be that a player from one origin gets a domain key and > (possibly) licenses for the domain and then this information can be used by > players from other origins that are part of the same domain ? No. > > How would this fit into the 'same origin' web security model ? What would be > the mechanism for origins to prove that they are allowed access to keys / > licenses associated with a specific domain ? Per our resolution to bug 17202, I am not expecting keys to be shared across origins.
(In reply to Joe Steele from comment #5) > (In reply to Mark Watson from comment #4) > > (In reply to Joe Steele from comment #3) > > > (In reply to Mark Watson from comment #2) > > > > Joe, can you explain what a "domain" is, in terms that are independent of > > > > any particular DRM system ? > > > > > > In DRM-generic terms, a domain (or "license domain") is a group of players > > > for which a single content license can be issued. A domain key is a key that > > > is used to encrypt content keys for delivery to players in the same domain. > > > > So, the idea would be that a player from one origin gets a domain key and > > (possibly) licenses for the domain and then this information can be used by > > players from other origins that are part of the same domain ? > > No. > > > > > How would this fit into the 'same origin' web security model ? What would be > > the mechanism for origins to prove that they are allowed access to keys / > > licenses associated with a specific domain ? > > Per our resolution to bug 17202, I am not expecting keys to be shared across > origins. On re-reading - I think I see the confusion. There are two different meanings to "sharing" in this case. A content license issued to a domain is implicitly "shared" between players by virtue of being in the same domain. However I do not mean to imply that the copy of that content license downloaded to a particular player is shared with other players. The players in the domain may all have their own copies of the same license, and in the case of EME they would.
Ok, so from the perspective of an individual client, the domain name identifies some state stored by the CDM which is necessary to facilitate the license exchange. If no state is present for that domain, then presumably some additional steps are necessary to establish it (e.g. additional request / response exchanges). So far, we have assumed that everything the CDM needs to generate the license request is in the initData. IIUC, this is not the case with the domains concept because the application may have knowledge of or opinions about the which of several possible domains should be chosen. If this is right, I think we need a higher-level understanding of the requirements / use-cases in order to understand whether this can be exposed in the API in a key-system agnostic way. Also, to understand what is the appropriate level of generality. It might be appropriate to have a more general capability.
One of the primary use cases for this proposal (playback of Ultraviolet content) is no longer urgent as the usage of domains is no longer required. Per the discussion in the telco today, I propose that we table this for a later release.