Category: wallet-authentication standard / offchain session bootstrap / self-custodied identity-provider alternative
Summary: EIP-4361 is best understood as login and consent infrastructure for Ethereum accounts rather than as a generalized identity system. Its core move is to standardize the exact message format, origin binding, replay protection, and wallet-verification expectations for offchain sign-in flows that were already happening informally. The important categorization clue is that EIP-4361 does not create portable reputation or identity by itself; it defines the authentication handshake between wallet, relying party, and browser origin, which makes wallet UX and domain verification the practical control points.
What it does:
Standardizes a signed plaintext message format for offchain authentication, including domain, address, URI, version, chain ID, nonce, and issuance time
Supports optional session-bound fields such as expiration time, not-before time, request ID, and resources
Uses ERC-191 for EOA signing and expects ERC-1271-aware verification for contract accounts
Requires relying parties to validate message structure, expected field values, signature correctness, and session binding to the signing address
Requires wallets to verify request origin against the stated domain and warn on lookalike login prompts that mimic SIWE text without conforming to the standard
Positions wallet-based authentication as a self-custodied alternative to centralized web identity providers
Key claims:
The final ERC says Sign-In with Ethereum provides “a self-custodied alternative to centralized identity providers,” which is the clearest sign this belongs in the corpus as wallet-auth infrastructure rather than a mere dapp UX convention
The motivation section says many services were already authenticating Ethereum accounts through message signing and frames ERC-4361 as an interoperability layer over that behavior, showing that its real contribution is standardization of an existing power surface rather than invention of a new primitive
The specification defines a strict ABNF message format with domain, URI, chain ID, nonce, and timestamp fields, which matters because it turns ambiguous wallet-signature prompts into machine-readable authentication requests that wallets can reason about
The spec requires contract-account verification to resolve against the specified chain ID and points implementers to ERC-1271, which makes smart-account support part of the standard’s security model rather than an afterthought
Wallet implementer rules say wallets must prevent phishing by checking that the request actually originated from the stated domain and should warn when the SIWE phrase appears in non-conforming messages, which means wallets become the frontline policy and anti-phishing layer
Relying-party guidance says sessions must be bound to the signing address rather than mutable resolved resources, which is a useful reminder that ENS names, avatars, and other enrichments are ancillary to the actual authentication anchor
The docs emphasize that listed resources are interpretable by the relying party but remain out of scope of the standard, which is important because it keeps ERC-4361 focused on authentication framing rather than trying to standardize downstream authorization semantics
The reference implementation README says the work was sponsored by the Ethereum Foundation and ENS and developed through public repositories and user interviews, reinforcing that ERC-4361 was designed as shared ecosystem infrastructure instead of a proprietary login product
Whitepaper: No standalone EIP-4361 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the final ERC, the raw ERC markdown, the SIWE documentation site, and the reference implementation README collected in ../../whitepapers/eip-4361-primary-sources-2026-05-08.md.