Wi-Fi passwords aren't really that secure a thing these days, anyways. If you need your Wi-Fi to be secure, you need to be doing RADIUS authentication or similar.

It's just from a UI standpoint that it's very seamless. You don't have to see the password, you don't have to enter it anywhere, one device just shares the Wi-Fi password with another device nearby.

Your key is too simple if it's easier to spell out. :)

Seems eminently sensible, no dependency on WiFi or Bluetooth stacks and works cross-platform.

A QR also lets you force the recipient onto a guest SSID instead of your LAN

Using a shared symmetric ChaCha20 w/ Poly1305 key to encrypt and authenticate the client's sign-on Curve255 exchange, you'd get a variety of usage modes for free without adding any special cases to the access point's side of the protocol.

The basic use case is that your device knows the password, so it listens for the periodic SSID announcement with the signed short-term DH public key. Your device then performs its side of the DH key agreement, and encrypts-and-MACs the public value with the password-derived key. The access point decrypts your public DH value, completes key agreement, and uses the agreed key to encrypt your short session ID, its expiry time, and a 256-bit ChaCha20/Poly1305 key[0] for the session, and send it back to your device.

In the case of temporarily granting access to a guest, the guest's device would generate a public DH value and send it to you. You'd then encrypt-and-MAC that exchange message and send it back to your friend's device. The friend's device would then be able to forward the DH exchange to the access point and sign on once. They'd have a session ID and encryption key that's valid until expiry.

In the case of a coffee shop granting temporary access to a paying customer, the phone could put its ephemeral public DH value in a QR code, and the cash register could scan the QR code, encrypt-and-MAC the public DH parameter, and directly send the value to the access point, at which point the customer's device could sniff and decrypt the sign-on message to learn its session ID and session key.

Each device gets its own session ID and session key, so they can't eavesdrop on each other.

If Curve22519 ends up getting broken, an attacker would still need to break ChaCha20 or learn the password in order to grab session keys. The client-side DH parameter still holds 252 bits of entropy (Curve25519's cofactor is 8, so the generator generates a 2*252 subgroup), and computing an Elliptic curve logarithm on this value still requires first decrypting the ChaCha20-encrypted sign-on message.

You wouldn't get perfect forward secrecy, but you would get forward secrecy through the timed key rotation of both the short-term DH keys and rotation of any symmetric keys used to avoid storing any per-session state in the access point.

[0] The session encryption key wouldn't simply be the DH-agreed key in order to allow the access point to avoid keeping per-session state and instead derive session keys from session IDs using periodically rotating symmetric encryption keys known only to it. The access point would need to guard against session IDs rolling over faster than they expired (and expiry would need to coincide with key rotation), but it's a simple check.