Summary: ERC-8128 is best understood as per-request API authentication infrastructure rather than as a login message format or a wallet-connect session flow. Its core move is to reuse RFC 9421 HTTP Message Signatures, then bind those signatures to Ethereum accounts via personal_sign / ERC-1271 so a caller can authenticate ordinary HTTP traffic without bearer secrets, cookie issuance, or a custom wallet-auth handshake for every API. The key analytical distinction is that ERC-8128 focuses on authenticating and authorizing individual HTTP requests — including what parts of the request are cryptographically bound and whether the signature is replayable — which makes it a useful comparison class for EIP-4361, CAIP-122, CAIP-25, and x402-style machine commerce flows.
What it does:
Defines how HTTP requests can be authenticated with Ethereum accounts using RFC 9421 Signature-Input and Signature headers
Requires explicit keyid, created, and expires parameters, with optional nonce to make signatures non-replayable
Distinguishes between Request-Bound signatures that cover a concrete request and Class-Bound signatures that authorize a broader class of requests
Distinguishes between Non-Replayable signatures with nonce tracking and weaker Replayable signatures that verifiers may accept only with extra invalidation mechanisms
Uses EIP-191-style personal_sign semantics for EOAs and ERC-1271 verification paths for smart-contract accounts
Is already being implemented in multiple SDKs, including Rust and TypeScript libraries for signing, verification, middleware, and fetch-style clients
Key claims:
The draft ERC says HTTP APIs still mostly rely on bearer credentials such as cookies, API keys, and JWTs, and frames ERC-8128 as a way to bind cryptographic proof to the HTTP request itself instead of to a long-lived shared secret. That is the clearest signal that this belongs in the corpus as API-auth infrastructure rather than as another wallet-login UX spec.
The motivation section explicitly says Sign-In with Ethereum solves interactive frontend authentication but does not solve generic HTTP traffic for API clients, servers, and agents. That makes ERC-8128 analytically useful because it separates browser login from signed machine-to-machine or wallet-to-API request authentication.
The spec makes request binding and replay protection the real control surfaces. A signer chooses what request components to bind and whether to include replay protection, while the verifier decides what combinations it is willing to accept.
The baseline conformance rule is unusually important: compliant implementations MUST accept signatures that are both Request-Bound and Non-Replayable. That gives the standard a portable security floor instead of allowing each verifier to claim compliance while only supporting weaker application-specific modes.
The spec’s keyid="eip8128:<chain-id>:<address>" format, plus explicit EIP-191 and ERC-1271 verification semantics, shows that ERC-8128 is trying to standardize Ethereum-native HTTP auth without inventing a new account system.
The draft also explicitly says no out-of-band negotiation or capability discovery is required for the baseline model. That matters because it positions ERC-8128 as a zero-handshake interoperability layer for signed HTTP requests, not as another session-bootstrap protocol.
Independent Rust and TypeScript implementations from QNTX and Slice already expose sign-and-verify flows, fetch helpers, middleware, replay-protection hooks, and verifier policies, which is strong evidence that the proposal is being treated as deployable integration infrastructure rather than as a purely theoretical ERC.
ERC-8128 is a strong comparison class for EIP-4361, CAIP-122, CAIP-25, and x402 because it helps separate four layers that are often blurred together: who the wallet subject is, how login begins, how long-lived sessions are negotiated, and how each later HTTP request is individually authenticated and scoped.
Whitepaper: No standalone ERC-8128 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the draft ERC text, the associated discussion venue, and early implementation READMEs collected in ../../whitepapers/erc-8128-primary-sources-2026-05-11.md.