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

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

--- Comment #5 from Mark Watson <watsonm@netflix.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).

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.

Anyway, I think we should just agree that we had different understandings of
that one and leave it behind us, rather then referring to one understanding as
a precedent.

> Federation is still
> possible, but it requires metadata such as a manifest, which is increasingly
> likely with the popularity of DASH and MSE.
> 
> 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)

However, if I am the only one arguing for this alternative, I'll agree to the
type thing.

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

Received on Wednesday, 17 September 2014 00:23:24 UTC