RFC 8120 is one of those quietly ambitious specifications that tried to fix a problem the web still hasn't fully solved: phishing-resistant password authentication. It defines a framework layered on top of HTTP's existing WWW-Authenticate/Authorization challenge machinery — the same slot occupied by Basic and Digest — but with genuinely modern cryptography underneath.

The problem it attacks is subtle. Basic auth simply hands the password to the server. Digest hashes it, but the server still learns enough to verify it and is trusted absolutely. Neither mechanism gives the client any way to verify that the server actually knows the password. If you type your credentials into a spoofed page, the attacker collects them and you get no signal. TLS certificates protect the transport, but users routinely ignore certificate warnings and phishers register look-alike domains with perfectly valid certificates.

RFC 8120's answer is mutual authentication via Password-Authenticated Key Exchange (PAKE). Client and server run a cryptographic protocol where each proves knowledge of the shared secret without either transmitting it. If the server doesn't actually know your password (say, because it's a phishing site with only a stolen hash or nothing at all), the exchange fails and the browser knows to warn you — before you type anything sensitive into a form.

Crucially, RFC 8120 is a framework, not a specific algorithm. It defines:

• Two new HTTP authentication schemes: Mutual and Mutual-with-body.
• A four-phase message flow: challenge, key-exchange request, key-exchange response, and authentication verification — mapped onto sequences of 401 responses and follow-up requests.
• Header syntax carrying algorithm identifiers, session IDs, nonces, and PAKE parameters (typically base64url-encoded big integers).
• A concept of authentication realms and session persistence, so a browser doesn't renegotiate on every request.

The actual PAKE math lives in a companion document, RFC 8121, which specifies augmented PAKE algorithms (Iso-KAM3 family) suitable to plug into this framework. That layering was deliberate — cryptographic primitives age faster than protocol wire formats.

The design decisions worth noticing:

• Explicit UI signaling. The spec assumes the browser will render a trusted, non-spoofable indicator when mutual auth succeeds — analogous to (but stronger than) the padlock icon. Without this UX affordance, the cryptography accomplishes little.
• Works without TLS. Because the PAKE itself resists MITM, the protocol technically stands alone — though the spec still recommends TLS for confidentiality of the payload.
• Server stores a verifier, not the password. Like SRP, a stolen database doesn't immediately yield plaintext credentials.

The backstory is charming: the work came out of Japan's AIST (National Institute of Advanced Industrial Science and Technology), and the authors shipped an actual Firefox extension and Apache module implementing the whole stack. It never achieved wide browser adoption, partly because the web instead moved toward federated identity (OAuth, OIDC) and hardware-backed credentials (WebAuthn/passkeys), both of which solve overlapping problems differently.

But 8120 remains fascinating today. Passkeys solved phishing resistance by replacing passwords entirely; RFC 8120 tried to solve it while keeping passwords. For legacy systems, IoT devices, or contexts where per-device credential enrollment is impractical, its approach — cryptographically upgrading the humble password prompt — is still one of the cleaner ideas in HTTP authentication.