Cowrie Research

erc-5573-primary-sources-2026-05-08

3 min read

ERC-5573 primary sources — 2026-05-08

Project status in this pass

  • No standalone ERC-5573 whitepaper or litepaper surfaced.
  • The clearest current source of truth was the draft ERC itself, backed by the raw ERC markdown in the Ethereum ERCs repository and SpruceID’s siwe-recap implementation README.
  • The sources consistently frame ERC-5573 as capability-consent infrastructure layered on top of SIWE rather than as a generic wallet login improvement.

Primary-source snapshots

1) Canonical ERC page

  • URL: https://eips.ethereum.org/EIPS/eip-5573
  • Key excerpt/signals:
    • The subtitle calls it a “Mechanism on top of Sign-In with Ethereum for informed consent to delegate capabilities with an extensible scope mechanism.”
    • The abstract says SIWE ReCaps authorize a relying party to exercise certain scoped capabilities.
    • The motivation says plain SIWE authenticates an Ethereum account to a service but does not provide a canonical way to authorize that service to interact with a third-party resource service on the account’s behalf.
  • Why it mattered:
    • This is the clearest evidence that ERC-5573 belongs in the corpus as offchain delegated-authorization infrastructure rather than simple sign-in UX.

2) Raw ERC markdown / where the authority actually sits

  • URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-5573.md
  • Key excerpt/signals:
    • The URI field MUST specify the intended relying party.
    • Issued At, Expiration Time, and Not Before are explicitly reused to attenuate the capability validity window.
    • The spec says the resource service is expected to authenticate the relying party before invoking an action for the capability.
  • Why it mattered:
    • These details show ERC-5573 binds capability authority to a specific relying party and time window, but leaves practical enforcement with the offchain services that accept and verify the grant.

3) Raw ERC markdown / capability object structure

  • URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-5573.md
  • Key excerpt/signals:
    • ReCap data is encoded as a urn:recap: URI containing a base64url payload.
    • The ReCap Details Object uses an att map from resource URIs to ability strings like namespace/ability plus optional qualification objects.
    • Optional prf values are CIDs for parent capabilities that can justify delegated control when the signer is not the direct controller of the resource.
  • Why it mattered:
    • This is the strongest source-level evidence that ERC-5573 is a capability-language and delegation-envelope standard, not merely a prettier SIWE statement format.

4) Raw ERC markdown / deterministic translation and verification

  • URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-5573.md
  • Key excerpt/signals:
    • The final SIWE Resources entry MUST contain the ReCap URI.
    • The human-readable statement shown to users MUST be deterministically generated from the machine-readable capability object.
    • Verification first performs ERC-4361 signature verification, then checks that the signed statement ends with the correctly translated ReCap text.
  • Why it mattered:
    • This is the key mechanism that tries to keep wallet-visible consent synchronized with the underlying grant, reducing ambiguity between what the user reads and what the relying party later claims to have received.

5) SpruceID siwe-recap implementation README

  • URL: https://raw.githubusercontent.com/spruceid/siwe-recap/main/README.md
  • Key excerpt/signals:
    • The README says the crate implements EIP-5573 and is used to build wallet-signable messages with capability delegations.
    • It says generated messages contain both an unambiguous machine-readable representation and a human-readable description, with the latter deterministically generated from the former.
    • The examples show concrete offchain capability bundles for credential presentation and kepler key-value resources.
  • Why it mattered:
    • This gives useful implementation evidence that ERC-5573 has been operationalized into developer tooling, and that the standard is intended for real protocol/API authorization flows beyond a purely theoretical draft.

Working conclusion

ERC-5573 is best cataloged as SIWE’s missing authorization layer. It takes wallet-based offchain authentication and turns it into scoped delegated consent over external resources, with explicit rights, time bounds, and verification rules, while leaving real enforcement and trust concentration in the relying-party/resource-service layer that chooses how to honor those capability objects.

Graph View