[Bug 25434] Remove unsupported informative text in Abstract regarding OOB communication.

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

--- Comment #13 from David Dorwin <ddorwin@google.com> ---
The purpose of the new text is to document the intent, which is consistent with
the TAG's spec review. The intent is that all application-specific and
origin-specific messages go through the application via the APIs defined in the
EME spec. This includes all license exchange messages.

The text Glenn quoted in comment #9 is intended to avoid prohibiting the user
agent from handling client initialization/individualization and/or forcing all
applications to handle it. Only such traffic is allowed to NOT be passed
through the application. As noted in the text, these should be rare and not
occur for every origin using the key system.

(In reply to Glenn Adams from comment #9)
> The new text [1] is overly vague:
>  
>     1.17 +            <p>Messages related to "one-time"
> application-independent initialization that are sent to a pre-defined URL
> MAY be handled by the user agent and not passed to the application via the
> APIs.
>     1.18 +              The related operations MUST be performed by the user
> agent, and such messages MUST still be transmitted via the user agent's
> network stack.
>     1.19 +            </p>
> 
> Please define the following in a sufficiently precise manner to facilitate
> testing these assertions:

I disagree that these are not sufficiently precise or more vague than other
normative text dealing with the varied nature of key system implementations.
I've further explained each below. (For simplicity, I've used
"individualization" as a generic term for such initialization.) Suggestions for
more precise text is welcome.

> (1) messages
"Message" is used throughout the spec. Basically, any communication intended to
be sent over a network or provided to/from another endpoint (i.e. server).
> (2) one-time application-independent
"One-time" refers to the rarity of such events. For example, a client generally
only needs to be individualized once. As mentioned in the note, this also
applies to re-individualization.
Application-independent means that the exception does not apply to anything
that includes application data, its origin, etc.
> (3) pre-defined URL
A URL that is pre-determined in the CDM implementation and does not depend on
the application, application origin, etc.
> (4) handled by the user agent
The user agent MAY handle (in response to an indication from the CDM) and/or
drive the individualization process without involving the application. The user
agent would be responsible for any permissions/prompts and performing the
necessary network traffic.
> (5) related operations
Operations related to what was described in the previous sentence (i.e.
individualization).
> (6) performed by the user agent
Same as #4. #4 introduces the possibility and #5 and #6 constrain it.
> 
> [1] https://dvcs.w3.org/hg/html-media/rev/f8e25bb791fe


(In reply to Glenn Adams from comment #12)
> (In reply to Mark Watson from comment #10)
> > Although I do not agree with everything in the draft TAG opinion on EME [1],
> > they do say:
> > 
> > "Although CDMs are necessarily underspecified for robustness reasons, this
> > should not be used as a loophole to drive through vendor-specific behavior.
> > Out-of-band communication (via the CDM or otherwise) should not be possible,
> > nor should vendor-specific extensions or extension points be blessed into
> > the spec."
> > 
> > Direct CDM <-> license server communication goes directly against this
> > recommendation.
> 
> I can accept a scenario where CDM communication is mediated by the UA, but
> the TAG opinion piece seems to want to prohibit that as well "... or
> otherwise". The new language in EME seems to offer the possibility of some
> degree of UA mediated communication. This is something I would like to see
> preserved, and not legislated away.
> 
> > [1] https://github.com/w3ctag/spec-reviews/blob/master/2014/10/eme.md

The new text is consistent with the TAG's spec review except for the very
narrow exception for individualization. I think there are legitimate reasons*
for allowing the user agent to handle this on platforms that require it without
jeopardizing interoperability, privacy, or security, especially given the
restrictions in the text. We can seek clarity from the TAG on this specific
exception.

* This includes simpler applications, simpler servers, client/device deployment
and innovation without requiring license server updates, and privacy with
respect to whether the device has previously been initialized.

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

Received on Wednesday, 15 October 2014 19:30:50 UTC