Feedback rcombs

[backkem]

This issue is to capture and address the feedback of @rcombs in this comment. Original feedback:

Unfortunately, I'm no longer at Plex, so I can't confidently say what they'd be interested in today, but I can evaluate these proposals based on how I'd have been able to make use of them when I worked on Plex Media Server; I'd imagine that my concerns here will be relevant to other comparable applications as well.

The prompt + preflight-and-header approach from the current version of this repo appears to resolve the first-run setup use-case to some extent; at minimum, it allows secure-loaded web apps the same provisioning capabilities that were previously available only to insecurely-loaded ones, which is a major improvement. The main caveats are:

It doesn't seem to provide any secure connection mechanism, so any authentication or encryption would need to be built on top of plaintext HTTP, and would be extremely challenging to implement for general purposes; this essentially means that uses of this would ~always rely on the security of the LAN
It's limited only to Fetch, and requires specific API parameters to be passed, so it wouldn't be possible to do direct

The LP2P API is very intriguing. The current details listed there are somewhat sparse, but the "Local HTTPS" section seems like it probably does exactly what I'd have wanted: provides a specialized API for initial mutual authentication with the server, then allows regular web APIs to communicate with the server securely over ordinary HTTPS by using a TLS certificate with a negotiated fingerprint. I have a few questions about it:

What address would the client use to communicate with the local HTTPS server? Something like https://[fingerprint]._openscreen._udp:[port?]/?
If the client and server have some way of authenticating each other without user input (e.g. a shared secret received from a cloud service and cached locally by both, or some form of mutual proof-of-private-key-possession auth), would they be able to set up a connection that way, or would that always require opening a user prompt for a PAKE code? The PAKE route might not always be viable for per-session auth with headless devices.
If there's somewhere else more appropriate to discuss the LP2P case in more detail, I'd be happy to chat more there, and also to pull in my former colleagues at Plex.

As for my current professional position, I'm not aware of any current interest in this kind of API at Discord (though I'm speaking purely on my own behalf here), but I could imagine a number of worlds where such an interest materializes in the future, so I'll want to keep watching this space regardless 😄

[backkem]

User research
Again, thanks for taking the time to provide feedback. Showing real-world demand for this functionality is an important area that needs more work. Additional viewpoints help shape the spec and illustrate its merit.

Local HTTPS
It's clear this needs to be written/fleshed out more. Let me give some more insight: The OpenScreen Protocol provides us with a way to establish mutual TLS certificates using an authentication mechanism (a PAKE by default). In essence, this is a secure way to upgrade a connection on a LAN to a TLS tunnel. For the purposes of 'local HTTPS' the idea is to use the resulting certificates as a 'trust anchor' or 'root certificate'. A local HTTPS server can use the certificate to sign a certificate for the host address it's serving on. Ideally, this avoids impact on the URL the page is hosted at. Note that the security characteristics of the later still need to be studied in detail.

This shouldn't have to be limited to Fetch, any functionality running over TLS could do the same.

Video
The current specification has a DataChannel and WebTransport based API. They're mostly focused on data communication. I'm certainly open to considering a media variant. Alternatively, it seems like the Media over QUIC effort is doing Media over WebTransport. I'll reach out to see if we need anything to accommodate their work.

Authentication methods (reducing user input)
Naturally, I agree that constant re-authentication would be frustrating. #18 explores ways to reduce the reliance on user input. Ideas include:

• Signaling: allowing authentication using an intermediary (much like WebRTC).
• Certification Path Validation: a recursive/hierarchical version of authentication where a parent set of mutual TLS certificates is used to create shorter lived children. The goal is to allow two user-agents establish a longer standing 'trust relation' and dole this out for individual origins to use.
• Matter: using an established Matter 'fabric' (a Fabric is an authenticated group of, usually IoT, devices) for authentication.