ERC-8128’s reusable mechanism is not wallet login; it is Ethereum-authenticated HTTP request signing built on RFC 9421 semantics.
The spec’s most important decomposition is between request binding and replay protection. That split makes the security posture explicit instead of hiding it inside an opaque API-auth product.
The baseline interoperability rule matters a lot: compliant verifiers MUST accept signatures that are both Request-Bound and Non-Replayable. That creates a portable minimum-security mode.
The proposal fills a gap left by EIP-4361 and CAIP-122. Those standards help with human-facing authentication flows, while ERC-8128 targets generic HTTP traffic for APIs, agents, servers, and machine commerce.
The keyid format plus EIP-191 / ERC-1271 verification rules show the proposal is trying to extend existing Ethereum account semantics into HTTP auth rather than inventing a parallel identity system.
The two reviewed implementation READMEs are useful because they show the proposal already lives at the integration layer: middleware, signed fetch clients, nonce stores, verifier policies, and end-to-end examples all exist.
Specific source signals worth retaining
Draft ERC text: best source for motivation, baseline conformance requirements, request-bound vs class-bound semantics, replay rules, keyid format, and the zero-handshake design goal.
QNTX Rust README: best evidence that ERC-8128 is already being implemented as practical server/client middleware with explicit nonce-store and replay-policy abstractions.
Slice TypeScript README: useful confirmation that the spec is also being implemented for browser / fetch-native environments, including verifier clients and well-known discovery-document formatting.
Ethereum Magicians thread: useful as provenance that the proposal is being discussed in the normal ERC venue, even though the draft text itself carried most of the substance in this pass.
Why this entry belongs in the corpus
It strengthens the wallet-auth cluster by adding the missing per-request API-auth layer beneath or beside login/session standards.
It gives a cleaner way to compare bearer-token systems, SIWE-style auth, CAIP session negotiation, and x402-style paid APIs without flattening them into one generic “wallet auth” bucket.
The durable insight is that crypto auth standards often differ less in who the subject is than in where the real control sits: login message composition, session negotiation, route policy, replay handling, or per-request integrity guarantees.