Summary: ERC-5573 is best understood as the authorization layer that SIWE by itself lacks rather than as a generic login enhancement. Its core move is to extend ERC-4361 Sign-In with Ethereum messages with a deterministic, human-readable plus machine-readable capability object so a wallet owner can authenticate to one service while also authorizing that service to exercise scoped actions against another resource service. Mechanistically, ERC-5573 matters because it turns a wallet signature from simple session bootstrap into an offchain capability grant: authority is constrained by explicit resources, action namespaces, time bounds, and optional parent-capability proofs, while actual enforcement shifts to the relying party and resource service that interpret and verify the ReCap.
What it does:
Extends ERC-4361 SIWE messages with ReCap capability objects encoded as a urn:recap: resource URI
Requires the capability grant to also appear as a deterministic human-readable statement appended to the SIWE message so wallets and users can inspect what is being authorized
Lets a relying party receive scoped rights over specific resources and actions rather than only a blanket authentication assertion
Uses the SIWE URI, Issued At, Expiration Time, and Not Before fields to attenuate capability scope in time and target-party context
Defines a JSON schema for capability objects with att resource/action entries and optional prf parent-capability references
Specifies translation and verification algorithms so machine-readable capability objects and wallet-visible text stay in sync
Key claims:
The draft ERC says SIWE authenticates an Ethereum account to an offchain service but does not canonically authorize that service to act against a third-party resource service, which is the clearest reason to catalog ERC-5573 as authorization infrastructure rather than login UX polish
The motivation explicitly compares the design to combining OpenID Connect for authentication with OAuth2-like delegated authorization, signaling that ERC-5573 is trying to import capability-style consent into wallet sign-in flows
The spec requires the final SIWE Resources entry to contain the ReCap URI and requires the human-readable statement to be deterministically generated from the machine-readable capability object, which makes wallet consent legible while trying to prevent UI text from drifting away from actual granted authority
The ReCap Details Object keys rights by resource URI and ability strings like namespace/ability, and each ability can carry an array of qualification objects, which shows the standard is built for fine-grained offchain attenuation rather than binary connect/disconnect permissions
Optional prf entries let a signer reference parent capabilities by CID when the SIWE address is not itself the controller of the delegated resources, which is a strong signal that ERC-5573 is designed to compose capability chains rather than only first-party grants
The verification algorithm keeps ERC-4361 signature verification as the underlying auth primitive and layers capability verification on top, showing that ERC-5573 does not replace SIWE but repurposes it into a combined authentication-plus-authorization envelope
SpruceID’s siwe-recap implementation repository describes the output as containing both an unambiguous machine-readable representation and a deterministically generated human-readable description, which is useful evidence that the draft has real implementation-facing tooling rather than only aspirational spec text
Whitepaper: No standalone ERC-5573 whitepaper or litepaper surfaced in this pass. The clearest current sources were the draft ERC page, the raw ERC markdown in the Ethereum ERCs repository, and SpruceID’s siwe-recap implementation README; see ../../whitepapers/erc-5573-primary-sources-2026-05-08.md.