AUTHORIZATION
AP2, FIDO, and Verifiable Intent
AP2 v0.2 supplies the authorization foundation. FIDO and Mastercard's Verifiable Intent work addresses related proofs of user intent. Rialto does not replace either effort.
Status matters. Rialto is a tentative contribution to an active field—not an adopted AP2, FIDO, EEA, EAS, or Ethereum standard, a deployed reference implementation, or a claim of originality or consensus. ERC-8004 and ERC-8183 are Draft ERCs. This page summarizes one possible design; the repository text is the source for this discussion draft.
Narrower claims, stronger foundations
AP2 defines authorization artifacts and verification responsibilities. Rialto explores how a verified AP2 transaction may opt into EVM settlement and related Ethereum infrastructure without redefining AP2 intent or claiming to cover non-EVM rails.
Scope note: Ethereum settlement is an optional AP2-compatible profile, not a universal first-party AP2 rail. This draft does not claim the same EIP-712 envelope applies to card, ACH, SEPA, or FedNow.
Version note: AP2 v0.2 uses versioned Checkout and Payment Mandates secured through SD-JWT. The candidate mapping pins that model instead of mixing it with older Intent/Cart SDK types.
x402 note: Core x402 is a payment protocol, but the official AP2 sample still says its AP2-compatible x402 extension is forthcoming and must be enhanced to create all key mandates. This draft does not treat AP2-to-x402 mandate binding as finished.
Evidence note: AP2 dispute evidence is distributed across several roles. This exploration supplements opted-in EVM flows; an on-chain digest does not make off-chain evidence available or adjudicate it.
Built on prior work, not starting from zero
Rialto should converge with and credit the work already shaping agent authorization, payments, delegation, attestations, identity, and escrow. Mention here is attribution, not an assertion that any project endorses Rialto.
PAYMENT + DELEGATION
x402 and MetaMask delegation
AP2's a2a-x402 sample, x402 v2, MetaMask's Delegation Framework, and EIP-7702 supply important primitives—not a completed AP2 binding. ERC-7715 remains Draft, and a wallet's returned grant may differ from the request.
TRUST + ESCROW
EAS, Shibui, ERC-8004, and ERC-8183
EAS and Shibui inform the optional trust-policy workstream. Draft ERC-8004 and ERC-8183 retain their own authorship and governance for agent identity and service-job escrow.
COMMUNITY PROPOSALS
AP2 issues and experiments
Mandate binding, PactEscrow, BlindOracle, conformance vectors, post-checkout records, and proof-of-when proposals are relevant prior art—not adopted standards.
Rialto's possible contribution is deliberately narrow: test whether these pieces compose safely, document gaps and assumptions, and offer candidate EVM mappings for discussion. See the references and acknowledgements for links.
Four candidate workstreams, separately discussable
WORKSTREAM A
AP2 Artifact Commitment
Explores preserving the selected AP2 version's artifact type, digest algorithm, serialization rule, and transaction binding.
WORKSTREAM B
EVM Settlement Authorization
Studies a chain- and contract-bound EIP-712 authorization with explicit asset, payee, amount, nonce, deadline, and cap scope.
WORKSTREAM C
EAS Trust Resolution
Builds on EAS and Shibui patterns to consider registered UIDs, attester authorization, expiry, revocation, and local policy.
WORKSTREAM D
Optional ERC-8183 Escrow
Considers compatible ERC-20 service jobs only, with explicit evidence, evaluator, timing, timeout, and fallback policy.
01Verify AP2 presentation and required selective disclosures
02Build a versioned AP2 artifact commitment
03Verify chain-specific settlement authorization
04Apply optional trust policy
05Settle directly or use optional job escrow
AP2 commitment, without a new hash fiction
Rialto does not define keccak256(canonical CartMandate / IntentMandate JSON). It preserves the selected AP2 artifact's hash semantics. AP2 v0.2 uses checkout_hash and transaction_id; proposed open-mandate conformance work currently uses SHA-256 over RFC 8785 canonicalized unsigned Open Checkout Mandate claims and is not yet normative for all artifact types.
| Field | Purpose |
|---|---|
ap2Version | Pinned AP2 version identifier |
artifactType | Hash of the exact versioned vct |
digestAlgorithm | Explicit algorithm registry value |
artifactDigest | Digest produced by the applicable AP2 rule |
transactionIdDigest | Fixed-size transaction binding where applicable |
EAS supplies claims; consumers supply trust policy
Core EAS retrieves attestations by UID. This candidate workstream therefore considers an indexer or Shibui-style registry rather than the nonexistent getAttestation(counterparty, schema) call.
resolve(subject, topic)
→ obtain registered UID(s)
→ EAS.getAttestation(uid)
→ check schema, recipient, attester, expiry, revocation, payload
→ check attester authorization and local trust policy
EAS-native recipient, attester, expirationTime, and revocation fields should not be duplicated in schema data. Revocation is visible only after inclusion under the verifier's finality rule and a sufficiently fresh read; indexers and caches can lag. An optional ERC-8004 link uses the full (agentRegistry, agentId) pair, not a chain-ambiguous integer.
Escrow is optional and use-case specific
ERC-8183 models an ERC-20-funded job with Open, Funded, Submitted, Completed, Rejected, and Expired states. It does not define card or bank settlement. It permits expiry refund from Funded or Submitted, so Rialto requires an explicit evaluation window and timeout policy.
The core call sequence is createJob → setBudget → fund(expectedBudget); there is no createJob(mandateHash) overload. The AP2 binding needs a specified description, hook, or adapter. A direct merchant transfer cannot later be refunded by an ERC-8183 job that never held those funds.
A deliverable or reason hash proves integrity of later-presented evidence. It does not prove delivery, quality, availability, or legal sufficiency. Evaluator selection, conflicts, fees, outage, fallback, appeals, evidence access, and external consumer rights remain higher-level requirements.
Work needed before any standards proposal
- Versioned JSON schemas and Solidity interfaces
- Exact EIP-712 type strings and known-answer vectors
- AP2 base64url/raw-digest conversion vectors
- Solidity, TypeScript, and Python cross-verification
- Replay, nonce, expiry, cap, and signer-type tests
- ERC-7715 requested-versus-granted permission tests
- AP2-to-x402 binding and settlement-reconciliation tests
- Payee and AP2
cnfidentity-binding tests - EAS registration, revocation, replacement, and stale-index tests
- ERC-8183 expiry-race and evaluator-failure tests
- Threat model and privacy analysis
- Registry and evaluator governance specification
- Deployment and upgrade runbook
- Independent smart-contract security review
Possible research path
- Align scope and terminology with AP2/FIDO contributors and related work such as Verifiable Intent.
- Prototype workstreams A and B against pinned AP2 v0.2 fixtures on one EVM testnet.
- Adapt Shibui's registered-UID and attester-authorization pattern for workstream C.
- Prototype workstream D separately for an ERC-20 service-job flow.
- Publish conformance vectors, a threat model, governance rules, and a security review before representing Rialto as implementation-ready.
This path is not a commitment by any cited project or a claim that a new standard is necessary. Read the complete discussion draft, inspect the illustrative demo, or contribute on GitHub.