[Meta] Open Screen Application Protocol

[markafoltz]

Following TPAC 2023, we agreed to investigate splitting the current specification into two or more specifications, for several reasons. Three main factors were:

• Simplifying the specification and making it easier to digest;
• Permitting multiple implementations at the transport layer to accommodate new device interconnection strata like WebTransport and Matter;
• Allowing application level concerns to be worked on in the W3C, while security sensitive networking and certificate management could be handled in other fora in the future, like the IETF.

This meta issue tracks work items to deliver the application layer protocol, which is layered above DNS-SD, QUIC, and TLS. Meaning, it can be implemented with an alternative to those technologies, if that alternative meets the necessary requirements.

Outstanding work items:

• Craft the initial document with open issues for remaining work items.
• Define discovery and transport requirements for application protocol #342
• Describe message delivery semantics independent of QUIC #343

[backkem]

I'd like to argue for the following:

• The rendezvous protocol covers discovery and authentication and it has a goal to create "connection materials" for a transport protocol that carries the application level protocol.
  • There can be a simple protocol for ephemeral rendezvous (carrying forward the OSP rendezvous work) and more long-lasting rendezvous using a Matter fabric for example (ref).
  • I think this warrants a new name that is more generic than "Open Screen" protocol.
• The connection materials form a "thin waist" serving as a local-first alternative to Public key infrastructure, roughly consists of:
  • address: A URL, for ad-hoc agents I would suggest this
  • trust anchor: mutually authenticated TLS certificates established between the peers.
  • browser-specific concerns: a clear client & server role + a definition of how the above address & certificate information can be exposed to various origins. Potentially requiring child certificates to be issued for individual origins, signed by the previously mentioned "trust anchor" (and maybe a way to use the "trust anchor" to secure local HTTPS services but this likely warrants a separate spec).
  • Optionally, we can define shortcuts that allow the existing connection to be re-used as a transport for the application protocol rather than opening a new connection. Although on the local network there doesn't seem to be much difference between these approaches, with the exception of resource usage.
• These "connection materials" should be sufficient to open a secure transport that can carry the application protocol.
  • Both the rendezvous and eventual transport can likely be defined somewhat transport protocol agnostic as long as it is URL & TLS based. For example one could run this over SCTP/DTLS (which would be nice for the WebRTC folks), but I do think mainly targeting QUIC makes sense going forward.

[backkem]

Side-note: I'm happy to accommodate for rapid experimentation in go-lp2p if it makes sense at any point.

[markafoltz]

The intention of the Open Screen Application Protocol is to work across multiple discovery, authentication, and transport mechanisms. As we craft requirements for those mechanisms, I look forward to your feedback as to whether the various alternatives you're investigating would be suitable. This work is tracked in Issue #342.

I don't see anything to "argue" here.

[markafoltz]

One more detail. It's an open question whether authentication and certificate creation and exchange can be specified by the application protocol, or whether it is tied too closely to the networking aspects to make that possible. That is an area that deserves a deeper dive.

In general "local https" approaches were not considered viable at the time we started this work, because it was quite complicated to get a CA to issue a certificate that essentially names a local network device that browsers would trust. However there's likely been progress in this area since we started this work.

[markafoltz]

The draft above does not include the authentication protocol (SPAKE2), but it could be added back depending on further discussions.

[backkem]

I saw Mark hinted at a JavaScript implementation of the application protocol in the TPAC 2024 slides and wanted entertain a hypothetical full-stack version of the concept:

• Use the Local Peer-to-Peer API for peer discovery & authentication. Allowing the user agent to open secured connections between the peers.
  • Using the "OSP network protocol", Matter or others.
• Use this to open a RTCQuicTransport to transport control messages.
• Likewise, open a RtpTransport (or hypothetical RoQ based RtpQuicTransport) to transport media.