[Bug 26683] Replace MediaKeyMessageEvent's "destinationURL" attribute with a "type" attribute

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

--- Comment #6 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #4)
> The "federation" scenario appears to be the main motivation for a
> "free-form" value (i.e. comment #1 and comment #2). The
> assumption/implication is that the license server is encoded in the PSSH.
> 
> However, this is irrelevant to this bug because URL extraction from initData
> is not and should not be permitted (bug 25920). Federation is still
> possible, but it requires metadata such as a manifest, which is increasingly
> likely with the popularity of DASH and MSE.

I want to clarify something that seems to be confusing many people. The "URL
extraction" that bug 25920 was originally referring to and that you seem to be
objecting to, is the browser extraction of URL from the initData. I am in
agreement that that is problematic because of the proprietary nature of
initData. However CDM extraction of URLs from the initData does not have this
problem. And since the same initData may be found in the manifest as in the
PSSH, the problem does not goes away. 

> 
> I believe such URL extraction is the only use case discussed in the related
> bugs for which an indication of the type of message/server (the proposal in
> comment #0) is not sufficient. In the absence of concrete alternate
> proposals for normative interoperable solutions, we should fix the current
> problem (destinationURL) and get some implementation feedback and experience
> on the message type solution.

I don't believe there is an absence of a concrete proposal for
interoperability. I believe that the proposal is -- if a URL is provided by the
CDM, the application _can_ use it with appropriate validation. We should wait
on implementation experience to provide further guidelines here. 

(In reply to Mark Watson from comment #5)
> (In reply to David Dorwin from comment #4)
> > The "federation" scenario appears to be the main motivation for a
> > "free-form" value (i.e. comment #1 and comment #2). The
> > assumption/implication is that the license server is encoded in the PSSH.
> > 
> > However, this is irrelevant to this bug because URL extraction from initData
> > is not and should not be permitted (bug 25920).
> 
> FWIW, that was not my understanding of what was agreed with that bug: I
> thought we had agreed not to specify that destinationURL must be set to the
> defaultURL extracted from the initData. That's a very different thing from
> prohibiting the CDM from setting the destinationURL.

Agreed. 

> > I believe such URL extraction is the only use case discussed in the related
> > bugs for which an indication of the type of message/server (the proposal in
> > comment #0) is not sufficient. In the absence of concrete alternate
> > proposals for normative interoperable solutions, we should fix the current
> > problem (destinationURL) and get some implementation feedback and experience
> > on the message type solution.
> 
> My concrete alternate proposal is:
> - rename destination URL to 'destination', defined as 'key-system specific
> message routing information'
> - include security considerations addressing the necessity for applications
> to pay proper consideration to the authenticity of indications received over
> the EME API (I'm happy to draft detailed text)

I would agree with this proposal, pending reviewing the text.

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

Received on Wednesday, 17 September 2014 16:37:55 UTC