I agree with this proposed change. This would allow for better cross-origin privacy. It would also reduce or eliminate the need to embed destination URLs in the request data.

(In reply to Henri Sivonen from comment #0)
> The spec currently says:
> "Application- and origin-independent messages related to per-client
> initialization (or reinitialization) that are sent to a fixed
> non-application-dependent URL MUST be handled by the user agent and MUST NOT
> be passed to the application via the APIs."
> 
> I think this is inappropriate. As far as I am aware, no rationale has been
> given for the above-quoted design restriction. As described in
> http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0006.html ,
> it's a totally reasonable design that individualization (is there
> "initialization" of another kind?) requests are made as EME messages and
> either the JS app knows how to route these to a different server than the
> license requests or the license server knows how to proxy these to an
> individualization server.

Individualization is already explicitly allowed to go through the EME APIs by the next paragraph in the spec, but it must be per-origin individualization rather than user agent- or system-wide individualization.

The rationale for not sending non-origini-specific individualization was mentioned at the end of [1]:
  "privacy with respect to whether the device has previously been initialized."

The concerns about a centralized server in my reply [2] to that email also apply. Specifically:
'... it's unclear whether deferring such individualization to a centralized server maintains those [privacy] qualities. (I am assuming the reason for the proxying is that the "individualization server" is not run by the application provider.) This also requires every content provider to understand the privacy implications of doing so (for every client implementation), which is unlikely to be the case. (With user agent-driven initialization, only the user agent vendor needs to understand the implications of this on each particular client it supports.)'

I'm happy to discuss this, but I think that is a separate bug from the enum requested in this bug's summary. Maybe the summary should be changed.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25434#c13
[2] http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0064.html

> 
> I request that
> 
>  1) The above-quoted sentence be edited to say that individualization MAY be
> handled by the user agent without exposing the process to the application
> via EME or individualization MAY be performed via EME messages whose type is
> "individualizationrequest".

Both options are supported, but there are some limitations. I'm also concerned about the centralized server aspect of the second option. As I said in [2], we should also keep in mind that it would be better if there aren't multiple ways to do things depending on the key system and/or client.

>  2) "individualizationrequest" be added to the MediaKeyMessageType
> enumeration.
> 
> (I could live with the string "individualizationrequest" to be bikeshedded
> to the more generic "initializationrequest" if spec text explains that it is
> meant to cover individualization.)

If we decide to support such individualization, we should definitely add a message type for it, but I think we need to address the issues first.

> Please note that individualization could reasonably be origin-*dependent*.
> (This is desirable for privacy reasons to prevent cross-site correlation of
> individualized bits that the key system exposes.) Sure, it's possible to
> read the above-quoted sentence as not restricting origin-*dependent*
> individualization via EME messages, but I still request change #1 above.

I acknowledged this in [1] and "per-origin initialization" via the EME APIs is currently explicitly allowed by the spec.
It's also possible to address the privacy issues without per-origin communication with a centralized server. As mentioned in [2], involving a centralized server may compromise some of the privacy qualities of such implementations.

(In reply to David Dorwin from comment #2)
In the first sentence of the last paragraph, "this" was refers to "the privacy reasons" and [1] should have been [2]. Here's a fixed version:
> I acknowledged the privacy reasons in [2] and "per-origin initialization"
> via the EME APIs is currently explicitly allowed by the spec.
> It's also possible to address the privacy issues without per-origin
> communication with a centralized server. As mentioned in [2], involving a
> centralized server may compromise some of the privacy qualities of such
> implementations.

First, I think the introduction of the new message type is justified by the per-origin initialization case. In this case the application may still value a hint as to the messages purpose. Indeed this was the main use-case we had for the destinationUrl, so I was certainly expecting the messageType to support this.

Second, there is a gap in the restrictions in the specification right now between "application/origin-independent" and "per-origin". What about situations where the individualization is neither ?

In general I think it is very hard to tie this kind of thing down in a single API specification. For example, of messageType, it says 'Applications may ignore this attribute and must not be required to handle message types'. The first 'may' is a permissive requirement for applications, but applications are not the subject of this specification (they do not need to claim 'conformance'). The 'must not' is a requirement on some putative entity that might place requirements on applications. Who/what is that and why do we expect it to be compliant to our spec ?

If we were designing the whole system, we could easily impose these kind of design constraints, since we would have specifications that other parts of the system are supposed to be compliant to. But that's not the situation we're in.

I believe what David is trying to do is impose a design constraint on CDM/UA integrations that requires that initialization exchanges are either independent per-origin things or are hidden from applications altogether.

A more generic way to impose that requirement would be to require the entire API to have a strong same-origin property: that is, nothing that happens on one origin is allowed to affect the behavior of the API on another origin. One could allow origins to explicitly enable cross-origin behavior in a kind-of CORs way.

I'm not proposing that and I think some others might object, but I think that is the basic principle being pushed for here.

So, I suggest we address this bug just be adding the value, since it is needed anyway for the per-origin case and, if necessary, address the idea of a more general same-origin restriction elsewhere,

(In reply to Mark Watson from comment #4)
> First, I think the introduction of the new message type is justified by the
> per-origin initialization case. In this case the application may still value
> a hint as to the messages purpose. Indeed this was the main use-case we had
> for the destinationUrl, so I was certainly expecting the messageType to
> support this.

That was not the main or even second use case for destinationURL.

The concern about just adding this type is that its primary use case may be an anti-pattern. We should evaluate the use case and, if we choose to add this type, include appropriate text. We're still waiting for responses from Mozilla and Adobe on their use case.

> Second, there is a gap in the restrictions in the specification right now
> between "application/origin-independent" and "per-origin". What about
> situations where the individualization is neither ?

Do you have an example? As I have said, I think there are some reasons to be concerned when per-origin and per-client information are mixed.

> In general I think it is very hard to tie this kind of thing down in a
> single API specification. For example, of messageType, it says 'Applications
> may ignore this attribute and must not be required to handle message types'.
> The first 'may' is a permissive requirement for applications, but
> applications are not the subject of this specification (they do not need to
> claim 'conformance'). The 'must not' is a requirement on some putative
> entity that might place requirements on applications. Who/what is that and
> why do we expect it to be compliant to our spec ?

We can make the first "MAY" a non-RFC "may". The MUST NOT applies to implementations (user agents and CDMs). We could restructure that sentence to make implementations the subject.
The point is that, like setServerCertificate(), use should be optional so that applications aren't *required* to have client-specific code. That's how the web platform is supposed to work.

> If we were designing the whole system, we could easily impose these kind of
> design constraints, since we would have specifications that other parts of
> the system are supposed to be compliant to. But that's not the situation
> we're in.

Based on previous statements, it sounds like Adobe is currently designing this for EME. Regardless, that's not a reason to throw up our hands.

> I believe what David is trying to do is impose a design constraint on CDM/UA
> integrations that requires that initialization exchanges are either
> independent per-origin things or are hidden from applications altogether.

There is a fundamental question of whether the user agent should turn over responsibility for platform initialization to an application. I'm arguing that it should not. This is very much within the scope of the spec.

The origin is the fundamental boundary for the web platform. EME should not be an exception.

The current requirement is that either that the client initializes itself without providing per-origin information to a server OR the client initializes itself for an origin without providing privacy-sensitive per-client information (i.e. identifiers) to the origin.

If identifiers are provided, then the privacy properties are lost and you might as well use per-client initialization. If the request (and identifiers) are forwarded to a central server, what was the point of going through the application? Also, the central server now has a record of all origins visited, which is a privacy concern.

> A more generic way to impose that requirement would be to require the entire
> API to have a strong same-origin property: that is, nothing that happens on
> one origin is allowed to affect the behavior of the API on another origin.
> One could allow origins to explicitly enable cross-origin behavior in a
> kind-of CORs way.
> 
> I'm not proposing that and I think some others might object, but I think
> that is the basic principle being pushed for here.
> 
> So, I suggest we address this bug just be adding the value, since it is
> needed anyway for the per-origin case and, if necessary, address the idea of
> a more general same-origin restriction elsewhere,

(In reply to David Dorwin from comment #5)
> (In reply to Mark Watson from comment #4)
> > First, I think the introduction of the new message type is justified by the
> > per-origin initialization case. In this case the application may still value
> > a hint as to the messages purpose. Indeed this was the main use-case we had
> > for the destinationUrl, so I was certainly expecting the messageType to
> > support this.
> 
> That was not the main or even second use case for destinationURL.

It was certainly a use-case that we required, as I answered in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25920#c14 when you asked for use-cases.

I know you had some questions on that use-case, but still, at the end of that discussion my position was that we should have a free-format field for 'routing hints'. In compromising even on that back to a enum, I never dropped the use-case.

> 
> The concern about just adding this type is that its primary use case may be
> an anti-pattern. We should evaluate the use case and, if we choose to add
> this type, include appropriate text. We're still waiting for responses from
> Mozilla and Adobe on their use case.

The capacity and availability analysis for a server performing per-origin individualization is very different from that for a server providing licenses. This alone might lead services to make different architectural choices.

At the very least, if indiv servers are distinct from license servers, having the client send the request directly to the indiv server removes a point of failure from the path. This kind of thing is important when driving for very low failure rates.

> 
> > Second, there is a gap in the restrictions in the specification right now
> > between "application/origin-independent" and "per-origin". What about
> > situations where the individualization is neither ?
> 
> Do you have an example? As I have said, I think there are some reasons to be
> concerned when per-origin and per-client information are mixed.

I was just pointing out there was an unspecified gap in the language, so what you have might not be achieving what you'd like to achieve. This led to a more general argument that what you want to achieve is difficult to do at all at this level and we might be better off addressing this at a higher level: to what extent is the EME API per-origin ?

Specifically, one could imagine a CDM that shared some kind of indiv state across a set of origins. The application from any one of those would be empowered to perform an individualization that would then be good for all origins in the set. Such an arrangement would be neither per-origin nor origin-independent.

Such an arrangement need not involve leakage of information cross-origin except the fact that individualization has taken place for one of the other related origins.

> 
> > In general I think it is very hard to tie this kind of thing down in a
> > single API specification. For example, of messageType, it says 'Applications
> > may ignore this attribute and must not be required to handle message types'.
> > The first 'may' is a permissive requirement for applications, but
> > applications are not the subject of this specification (they do not need to
> > claim 'conformance'). The 'must not' is a requirement on some putative
> > entity that might place requirements on applications. Who/what is that and
> > why do we expect it to be compliant to our spec ?
> 
> We can make the first "MAY" a non-RFC "may". The MUST NOT applies to
> implementations (user agents and CDMs). We could restructure that sentence
> to make implementations the subject.
> The point is that, like setServerCertificate(), use should be optional so
> that applications aren't *required* to have client-specific code. That's how
> the web platform is supposed to work.

But this is a requirement on the system architecture, not on the implementation of the UA or CDM. There's no way that a requirement on the UA/CDM implementation can force a service provider to deploy a server capable of handling both indiv and license requests.

> 
> > If we were designing the whole system, we could easily impose these kind of
> > design constraints, since we would have specifications that other parts of
> > the system are supposed to be compliant to. But that's not the situation
> > we're in.
> 
> Based on previous statements, it sounds like Adobe is currently designing
> this for EME. Regardless, that's not a reason to throw up our hands.

As I understand it, the choices are for the application to route messages based on a new 'indiv' message type if it is present or for them to sniff the message itself for a hint as to what kind it is and route on that basis if it is not.

> 
> > I believe what David is trying to do is impose a design constraint on CDM/UA
> > integrations that requires that initialization exchanges are either
> > independent per-origin things or are hidden from applications altogether.
> 
> There is a fundamental question of whether the user agent should turn over
> responsibility for platform initialization to an application. I'm arguing
> that it should not. This is very much within the scope of the spec.
> 
> The origin is the fundamental boundary for the web platform. EME should not
> be an exception.
> 
> The current requirement is that either that the client initializes itself
> without providing per-origin information to a server OR the client
> initializes itself for an origin without providing privacy-sensitive
> per-client information (i.e. identifiers) to the origin.

Again, I'm not sure the requirement as stated really does what you say you want.

A more rigorous and succinct requirement would be to say that the behaviors and information on the EME API are strictly per origin.

This would imply that operations on the API *cannot* install state that affects the behavior on another origin. As a consequence, any message exchanges which install state that affects more than one origin MUST be done by the user agent.

Discussion in terms of identifiers here becomes complex because there are such things as per-origin identifiers which are derived from cross-origin state.

I think stating the requirement in terms of the well-understood same-origin policy would also make it easier for us to understand whether anyone is actually requesting the ability to install cross-origin state over the API: if someone really needs that perhaps we have to look at applying principles from elsewhere as to when cross-origin data transferred is safely allowed.

> 
> If identifiers are provided, then the privacy properties are lost and you
> might as well use per-client initialization. If the request (and
> identifiers) are forwarded to a central server, what was the point of going
> through the application? Also, the central server now has a record of all
> origins visited, which is a privacy concern.
> 
> > A more generic way to impose that requirement would be to require the entire
> > API to have a strong same-origin property: that is, nothing that happens on
> > one origin is allowed to affect the behavior of the API on another origin.
> > One could allow origins to explicitly enable cross-origin behavior in a
> > kind-of CORs way.
> > 
> > I'm not proposing that and I think some others might object, but I think
> > that is the basic principle being pushed for here.
> > 
> > So, I suggest we address this bug just be adding the value, since it is
> > needed anyway for the per-origin case and, if necessary, address the idea of
> > a more general same-origin restriction elsewhere,

(In reply to Mark Watson from comment #6)
> (In reply to David Dorwin from comment #5)
> > (In reply to Mark Watson from comment #4)
> > > First, I think the introduction of the new message type is justified by the
> > > per-origin initialization case. In this case the application may still value
> > > a hint as to the messages purpose. Indeed this was the main use-case we had
> > > for the destinationUrl, so I was certainly expecting the messageType to
> > > support this.
> > 
> > That was not the main or even second use case for destinationURL.
> 
> It was certainly a use-case that we required, as I answered in
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25920#c14 when you asked for
> use-cases.
> 
> I know you had some questions on that use-case, but still, at the end of
> that discussion my position was that we should have a free-format field for
> 'routing hints'. In compromising even on that back to a enum, I never
> dropped the use-case.

Thanks for clarifying. We were talking about different timeframes. I interpreted that as original use case, and you were referring to the remaining use case when we removed it.

> > > In general I think it is very hard to tie this kind of thing down in a
> > > single API specification. For example, of messageType, it says 'Applications
> > > may ignore this attribute and must not be required to handle message types'.
> > > The first 'may' is a permissive requirement for applications, but
> > > applications are not the subject of this specification (they do not need to
> > > claim 'conformance'). The 'must not' is a requirement on some putative
> > > entity that might place requirements on applications. Who/what is that and
> > > why do we expect it to be compliant to our spec ?
> > 
> > We can make the first "MAY" a non-RFC "may". The MUST NOT applies to
> > implementations (user agents and CDMs). We could restructure that sentence
> > to make implementations the subject.
> > The point is that, like setServerCertificate(), use should be optional so
> > that applications aren't *required* to have client-specific code. That's how
> > the web platform is supposed to work.
> 
> But this is a requirement on the system architecture, not on the
> implementation of the UA or CDM. There's no way that a requirement on the
> UA/CDM implementation can force a service provider to deploy a server
> capable of handling both indiv and license requests.

Is "service provider" a content provider or something else? This is a requirement on the key system, which is generally comprised of a CDM and license server. Regardless of enforceability, this is still a very strong recommendation.

> > > I believe what David is trying to do is impose a design constraint on CDM/UA
> > > integrations that requires that initialization exchanges are either
> > > independent per-origin things or are hidden from applications altogether.
> > 
> > There is a fundamental question of whether the user agent should turn over
> > responsibility for platform initialization to an application. I'm arguing
> > that it should not. This is very much within the scope of the spec.
> > 
> > The origin is the fundamental boundary for the web platform. EME should not
> > be an exception.
> > 
> > The current requirement is that either that the client initializes itself
> > without providing per-origin information to a server OR the client
> > initializes itself for an origin without providing privacy-sensitive
> > per-client information (i.e. identifiers) to the origin.
> 
> Again, I'm not sure the requirement as stated really does what you say you
> want.
> 
> A more rigorous and succinct requirement would be to say that the behaviors
> and information on the EME API are strictly per origin.
> 
> This would imply that operations on the API *cannot* install state that
> affects the behavior on another origin. As a consequence, any message
> exchanges which install state that affects more than one origin MUST be done
> by the user agent.

Would you like to propose some text?

> Discussion in terms of identifiers here becomes complex because there are
> such things as per-origin identifiers which are derived from cross-origin
> state.

Until/unless we disallow per-client and per-user identifiers, we'll need to account for those as well. That is a good goal and would be ideal for privacy, but we would need to address the fact that it would prohibit many existing implementations.

We also need to avoid driving non-individualization traffic away from the EME APIs.

> I think stating the requirement in terms of the well-understood same-origin
> policy would also make it easier for us to understand whether anyone is
> actually requesting the ability to install cross-origin state over the API:
> if someone really needs that perhaps we have to look at applying principles
> from elsewhere as to when cross-origin data transferred is safely allowed.

In comment 0, Henri proposed an additional enum value to allow the application to distinguish between individualization requests and license requests. The discussion about the privacy implications of what server handles that request is irrelevant to this proposal and should be the subject of separate conversation. 

(In reply to David Dorwin from comment #5)
> (In reply to Mark Watson from comment #4)
> > If we were designing the whole system, we could easily impose these kind of
> > design constraints, since we would have specifications that other parts of
> > the system are supposed to be compliant to. But that's not the situation
> > we're in.
> 
> Based on previous statements, it sounds like Adobe is currently designing
> this for EME. Regardless, that's not a reason to throw up our hands.

The individualization mechanism Adobe will use with EME is the same mechanism used elsewhere. Adobe individualization for EME will be per-origin as I have mentioned before.

Looking back at bug 26683, where this change was introduced, I notice that the list of enums you chose to put in the changelist did not include two of the message types you referred to in the bugs initial description [1]. You referred to heartbeat and initialization as known use cases. The omission of those use cases seems to be rather arbitrary, since you did not include any justification for it in your closing comment.

In addition to the "initializationRquest" Henri mentioned -- I would like to see "heartbeatRequest" added as well. Would you like me to file a separate bug?

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26683#c0

(In reply to David Dorwin from comment #2)
> (In reply to Henri Sivonen from comment #0)
> > The spec currently says:
> > "Application- and origin-independent messages related to per-client
> > initialization (or reinitialization) that are sent to a fixed
> > non-application-dependent URL MUST be handled by the user agent and MUST NOT
> > be passed to the application via the APIs."
> > 
> > I think this is inappropriate. As far as I am aware, no rationale has been
> > given for the above-quoted design restriction. As described in
> > http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0006.html ,
> > it's a totally reasonable design that individualization (is there
> > "initialization" of another kind?) requests are made as EME messages and
> > either the JS app knows how to route these to a different server than the
> > license requests or the license server knows how to proxy these to an
> > individualization server.
> 
> Individualization is already explicitly allowed to go through the EME APIs
> by the next paragraph in the spec,

Oops. I had missed that. Sorry.

> but it must be per-origin
> individualization rather than user agent- or system-wide individualization.
> 
> The rationale for not sending non-origini-specific individualization was
> mentioned at the end of [1]:
>   "privacy with respect to whether the device has previously been
> initialized."

As noted on public-html-media, unless origin-independent individualization happens eagerly ahead of time, the application can deduce the lack of previous individualization from the latency of the first operation requiring individualization.

Since PlayReady pricing currently disincents eager ahead-of-time individualization, I bet there are people who'd be unhappy about the spec requiring eager ahead-of-time individualization when individualization isn't origin-dependent...

> I acknowledged this in [1] and "per-origin initialization" via the EME APIs
> is currently explicitly allowed by the spec.

Since it's already explictly allowed, surely the spec should have an enum entry to go along with it, too.

(Other concerns not quoted here already replied to on public-html-media: http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0078.html )

(In reply to Joe Steele from comment #8)
> In comment 0, Henri proposed an additional enum value to allow the
> application to distinguish between individualization requests and license
> requests. The discussion about the privacy implications of what server
> handles that request is irrelevant to this proposal and should be the
> subject of separate conversation. 

Despite the bug summary, much of comment 0 (and the subsequent discussion) relates to privacy-related text and requirements.

As I said in comment 2, this bug seems to be more about those issues than the simple enum request:

> I'm happy to discuss this, but I think that is a separate bug from the enum
> requested in this bug's summary. Maybe the summary should be changed.

I'm also concerned about baking an anti-pattern into the spec, so I think the enum is blocked on this discussion.

(In reply to Joe Steele from comment #9)
> Looking back at bug 26683, where this change was introduced, I notice that
> the list of enums you chose to put in the changelist did not include two of
> the message types you referred to in the bugs initial description [1]. You
> referred to heartbeat and initialization as known use cases. The omission of
> those use cases seems to be rather arbitrary, since you did not include any
> justification for it in your closing comment.

My reference to "heartbeat" was a mistake - the use case I was thinking of was renewal, which I did include. I didn't know anyone else wanted heartbeat.

The main goal of that bug and the changeset was to implement the API change, not necessarily all possible types. The initialization was (and is) pretty unclear to me, and I didn't add things I didn't understand or wasn't sure we would need (better to add than have to remove). My closing comment said, "We can add more types to the enum if necessary (file a bug)." This all seems to have worked as intended.
> 
> In addition to the "initializationRquest" Henri mentioned -- I would like to
> see "heartbeatRequest" added as well. Would you like me to file a separate
> bug?

Do you have a use case for heartbeat or is this just for completeness with bug 26683? If the former, please file a bug. We may want to discuss whether we need/want both renewal and heartbeat types.
> 
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26683#c0

(In reply to Henri Sivonen from comment #10)
> (In reply to David Dorwin from comment #2)
> > but it must be per-origin
> > individualization rather than user agent- or system-wide individualization.
> > 
> > The rationale for not sending non-origini-specific individualization was
> > mentioned at the end of [1]:
> >   "privacy with respect to whether the device has previously been
> > initialized."
> 
> As noted on public-html-media, unless origin-independent individualization
> happens eagerly ahead of time, the application can deduce the lack of
> previous individualization from the latency of the first operation requiring
> individualization.

Unless there are per-origin user prompts, which is probably a good practice for client individualization anyway (see bug 27165).

Beyond that specific rationale, there are probably other concerns with deferring such operations to applications, similar to the central server concerns.
> 
> Since PlayReady pricing currently disincents eager ahead-of-time
> individualization, I bet there are people who'd be unhappy about the spec
> requiring eager ahead-of-time individualization when individualization isn't
> origin-dependent...

I don't think the spec requires this. Avoiding such timing "attacks" is probably an implementation detail (for implementations not requiring user interaction before individualizing), though we could certainly add it to the privacy considerations section.

(In reply to David Dorwin from comment #11)
> (In reply to Joe Steele from comment #9)
> > Looking back at bug 26683, where this change was introduced, I notice that
> > the list of enums you chose to put in the changelist did not include two of
> > the message types you referred to in the bugs initial description [1]. You
> > referred to heartbeat and initialization as known use cases. The omission of
> > those use cases seems to be rather arbitrary, since you did not include any
> > justification for it in your closing comment.
> 
> My reference to "heartbeat" was a mistake - the use case I was thinking of
> was renewal, which I did include. I didn't know anyone else wanted heartbeat.
> 
> The main goal of that bug and the changeset was to implement the API change,
> not necessarily all possible types. The initialization was (and is) pretty
> unclear to me, and I didn't add things I didn't understand or wasn't sure we
> would need (better to add than have to remove). My closing comment said, "We
> can add more types to the enum if necessary (file a bug)." This all seems to
> have worked as intended.
> > 
> > In addition to the "initializationRquest" Henri mentioned -- I would like to
> > see "heartbeatRequest" added as well. Would you like me to file a separate
> > bug?
> 
> Do you have a use case for heartbeat or is this just for completeness with
> bug 26683? If the former, please file a bug. We may want to discuss whether
> we need/want both renewal and heartbeat types.

We do actually have a "heartbeat" use case. The usage up till now has apparently been confusing -- I thought we were talking about the same thing. In our heartbeat use case, the server is providing a time check for the client. Since desktop devices rarely have anti-rollback clocks (at least that are accessible) this allows the client to verify its own clock for checking license expiry.

I don't believe this use case is critical for the initial release (although I will need to double check). If it is -- I will submit a separate bug. We should probably update the Use Case wiki to reflect this.

I'm not sure I understand what is blocking this bug.

- It seems to be agreed that origin-specific individualization has privacy advantages and should be supported
- It seems to be agreed that origin-specific individualization can and should be done through the application, just like license retrieval

As a service provider, I would like the flexibility to deploy separate server farms for individualization and licenses. I would like the ability to route messages directly to the correct farm from the client.

Isn't this sufficient to justify addition of the "individualization" type ?

We may need to rename all values of the MediaKeyMessageType enum to include a dash between words. See bug 27317.

What is the status here? Can we add the individualization request to the MediaKeyMessageType enum?

Can we please get edits that are about naming things done ASAP so that the names won't keep changing after implementations have adopted the names? There's more value in not having vendor prefixes and not having naming churn after shipping than in ending up with perfect names some time in the future.

Per bug 27317 and for consistency with the existing members of MediaKeyMessageType, the name should have dashes. So, "individualization-request" or "per-origin-individualization-request".

However, as mentioned in comment 11, the name of a potential new enum is just a small part of the discussion and open issues, which include privacy-related text and requirements.

(In reply to David Dorwin from comment #18)
> Per bug 27317 and for consistency with the existing members of
> MediaKeyMessageType, the name should have dashes. So,
> "individualization-request" or "per-origin-individualization-request".
> 
> However, as mentioned in comment 11, the name of a potential new enum is
> just a small part of the discussion and open issues, which include
> privacy-related text and requirements.

Please, let's get "individualization-request" decided as the name that we can put in code to be shipped.

Blocking the naming decision on privacy-related text is not cool, when you aren't blocking or imposing uncertainty on implementations that individualize out of band from the POV of EME.

+1 to "individualization-request". Let's get this included in the specification asap. If there is an open privacy issue, let's add a note to that effect.

But, what is the open privacy issue here ? I would like to send the individualization request to my server of choice. Whether I do that directly from the client, or have it proxied via a server that also handles other EME messages makes no difference at all to privacy - it's purely a technical optimization.

Privacy issues arise from the existence of identifiers in the first place and we have put in place extensive requirements there.

As discussed in the telecon, we will add "individualization-request".
Minutes: http://www.w3.org/2015/01/20-html-media-minutes.html#item11

https://github.com/w3c/encrypted-media/commit/1a611eab4f93318e4bba4207bbcba673d42cd062 adds "individualization-request" to MediaKeyMessageType.