[Long] Open Screen Protocol - next steps

*Hello Webscreens,I hope everyone had a good holiday break. I wanted to
kick off work in 2018 for the Open Screen Protocol.In my view, here are the
next steps for the Open Screen Protocol coming out of discussions at TPAC,
and a general direction for work in the first half of 2018.This outline is
mostly focused on delivering a complete set of specs by the end of March,
but I will cover future testing and implementation items at the end.  My
plan is to update the GitHub repository to align with this work plan; that
means archiving existing documents and closing out issues that don't
support it.My understanding is there is general interest and consensus on
two different possible implementations for Open Screen.One assumes
flexibility in implementation for both the controller and receiver, all the
way to the network and security stack - we'll call this the "QUARTC
Stack".The other is focused on interoperability with deployed standards
like ATSC 3.0 and HbbTV 2.0. We'll call this the "WebSockets
stack."Personally, I plan to make contributions focusing on the former
before the latter, but ideally work will proceed in parallel with
contributions by others.  Note that I also plan to take the action items
from the F2F [1] and update GitHub as well, and start to work on the ones
assigned to me.QUARTC Stack- mDNS and/or SSDP for discovery-
QUIC+RTCDataChannel (QUARTC) [2] for transport and message framingWork
items for the QUARTC stack: 1. Share data on reliability of mDNS vs. SSDP
and decide on which protocol(s) to require.2. Evaluate QUARTC and propose
how to map application protocol(s) onto it.WebSocket Stack- DIAL for
discovery (e.g., as used by ATSC 3.0/HbbTV 2.0)- WebSockets for transport
and message framingWork items for the WebSocket stack: 1. Write up DIAL as
an Open Screen discovery protocol (mostly referring to the existing spec,
and based on the existing SSDP evaluation)2. Map application protocol onto
WebSocketsApplication ProtocolFor the Application Protocol, at TPAC two
alternatives were proposed to the binary format that is currently in
GitHub.- CBOR [3]- Protocol Buffers (in conversation) [4]Work items: 1.
Evaluate pros and cons of these alternatives, get consensus2. Revise
application protocol to use chosen alternativeKey Exchange and
AuthenticationThere is consensus that J-PAKE is sufficient to bootstrap
authentication between the controller and receiver.  I feel that an
additional identity assertion should be available in the protocol as well
(e.g. the provision of a long lived certificate associated with each
device).Work items:- Extend application protocol to include J-PAKE for
authentication- Extend application protocol to support identity assertion
(key exchange and challenge-response)Benchmarking and Implementation After
the protocol stacks have been updated, the benchmarking plan [5] should be
updated to reflect the new proposals.Google plans to start an open source
repository with a prototype implementation of the consensus stack later
this quarter.  Details to come.Let me know if you have any questions,
concerns, or feedback; otherwise I will start aligning GitHub with this
work plan.Cheers,m.[1]
https://www.w3.org/2017/11/07-webscreens-minutes.html#ActionSummary
<https://www.w3.org/2017/11/07-webscreens-minutes.html#ActionSummary>[2]
https://docs.google.com/presentation/d/e/2PACX-1vSk0NcS8COhQ3vX3KdzEdufy72gaWONQeybRsFF843RheCusbUzj0l5XRmxiePiqTRKlE4SQbUpK_o8/pub?start=false&loop=false&delayms=3000&slide=id.g2a6f3cad35_19_30
<https://docs.google.com/presentation/d/e/2PACX-1vSk0NcS8COhQ3vX3KdzEdufy72gaWONQeybRsFF843RheCusbUzj0l5XRmxiePiqTRKlE4SQbUpK_o8/pub?start=false&loop=false&delayms=3000&slide=id.g2a6f3cad35_19_30>[3]
https://github.com/webscreens/openscreenprotocol/issues/77
<https://github.com/webscreens/openscreenprotocol/issues/77>[4]
https://developers.google.com/protocol-buffers/
<https://developers.google.com/protocol-buffers/>[5]
https://github.com/webscreens/openscreenprotocol/blob/gh-pages/benchmarks/README.md
<https://github.com/webscreens/openscreenprotocol/blob/gh-pages/benchmarks/README.md>*