OSP protocol split

[backkem]

I opened this ticket to continue the exploration of splitting the OSP protocol up into parts: a Connection spec and a Messaging spec.

OSP Connection (OSP-C) The connection spec would contain mDNS discovery and the authentication step to exchange TLS.

It may be worth exploring if the OSP-C protocol can be defined independent from OSP use. Pushing all OSP specific pieces to the OSP-M spec, such as the values used for _openscreen._udp.local mDNS queries.

OSP Messaging (OSP-M) The messaging spec would contain the CBOR message delivery, presentation, remote playback and streaming protocols. The spec should probably define a normative way of layering OSP-M on top of OSP-C + QUIC. Likewise, this spec would likely define how a potential OSP-over-Matter is wired up.

OSP stack overview I made an overview of what the stack may look like after such a split:

Local Peer-to-Peer (LP2P) considerations Since the group is exploring synergies with the Local Peer-to-Peer proposal, I wanted to quickly touch on that. One way to see the LP2P proposal is also in two pieces: A connection establishment between devices and a transport/messaging API. This is quite similar to the above. I explore this below.

Browser P2P connection I made an overview of what the stack may look like after such a split:

Browser P2P networking I made an overview of what the stack may look like after such a split:

For this overview I used the suggestion from ibelem/local-peer-to-peer#11 to use the WebTransport API and layered a simple messaging protocol on top for ease-of-use.

Sidenote: I think it would be great if the QUIC + WebTransport approach extended to WebRTC as once proposed by p2p-webtransport.

[backkem]

Here's some thoughts on making OSP-C open to other uses:

• Introduce a new agent-capability for send-data and receive-data (or just a symmetric exchange-data). To allow an agent to support only simple message passing. E.g.: ibelem/local-peer-to-peer#13.
• Introduce a new agent-capability for protocol-handoff and an accompanying message that allows the entire QUIC connection to be handed off for tunneling another protocol once agent authentication is complete, E.g.: a QuicWebTransport. Either using the same connection or opening a new one with a different ALPN (as done in p2p-webtransport). Though, the latter may not require negotiation at all.

[backkem]

Some notes on the "OSP Connection" side of things:

• TAG feedback: The protocol spec (goals, approach & definition) needs to become both more focused and more specific/detailed.
• TAG feedback: there is a recommendation to define a client and server role between agents to help structure reasoning.
• TAG feedback: An extremely high bar for security review is appropriate for this type of work, including Data Flow Diagrams and extensive thread modelling using a methodology such as STRIDE or against knowledge bases such as MITRE ATT&CK. They mention that the IETF would be a better venue for such work.
• My suggestion of the 'scope' of this protocol: A means for two peers on the same network segment to establish mutually authenticated TLS certificates, without requiring an intermediary.
• Since we're targeting the web, I would spec out peer & certificate management on user agent & origin level as well as implications of syncing beyond the user agent (e.g. on OS level or cloud assisted).
• I think it's worth exploring peer filtering, including privacy preserving techniques.