Result of Call for adoption - use case for "Trusted application, untrusted intermediary"

On the consensus call for adopting the “trusted application, untrusted intermediary” use case: The question, posted on Nov 20<https://lists.w3.org/Archives/Public/public-webrtc/2018Nov/0033.html>, was:


“The question is whether we should include in our “NV Scenarios” document the scenario currently described in https://w3c.github.io/webrtc-nv-use-cases/#securecommunications* - where the application (Web page) is fully trusted, but uses a relay service that should not be able to decode the transmitted media.”


The use case in question was described at the time as:

Secure Communications

A service that supports end-to-end confidentiality of communications in mesh and

centralized conferencing scenarios. While the service provides the Javascript

application which is considered trusted, backend services such as the SFU are considered untrusted. This use cases adds the following requirements:


 ----------------------------------------------------------------

  REQ-ID          DESCRIPTION

  ----------------------------------------------------------------

  N26           The application must be able to enable end-to-end

                payload confidentiality and integrity protection.

  N27           The browser must be able to obtain e2e keying

                keying material so as to enable content to be

                rendered.

  N28           TBD: restrictions on the application so as to

                prevent unauthorized recording of the session.


The discussion that ensued demonstrated varying interpretations of the use case as well as the requirements arising from it.  The description’s use of the term “trusted” with respect to the application lead some to conclude that this implied application access to keying material, while others noted that requirement N27 refers only to browser access to keying material. There was also debate as to what degree the use case (included in the New Use Cases section), was in fact a new use case, or just an improvement to an existing use case.


The chairs draw the following conclusions from the debate:


  *   There is clear indication that the existing use case is ambiguous, given the widely varying interpretations.

  *   There is clear indication that participants consider the use case important.

  *   There is clear indication that some participants hold strongly that there are additional requirements that need to be part of the use case description, which constrain the solution space to certain solutions. These constraints have, however, not been clearly expressed in the form of modifications to the use case.

  *   There is clear indication that some participants don’t agree that these constraints are reasonable for the use cases they envision.


Since the debate, the chairs have removed this use case from the FPWD version of the use cases document,<https://www.w3.org/TR/webrtc-nv-use-cases/> and will work with the participants to figure out which of the following are viable paths forward:


  *   Add back a single use case description, with additional constraints described

  *   Add back multiple use cases, with differing constraints


Bernard, for the chairs