[Bug 27124] Add "individualizationrequest" to the MediaKeyMessageType enum

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124

--- Comment #4 from Mark Watson <watsonm@netflix.com> ---
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,

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 23 October 2014 00:57:15 UTC