OAP
← All RFCs/RFC 0036Draftv1.2Edit on GitHub →

RFC 0036: AP2 Payment Mandate Interoperability Adapter

Status: Draft Author(s): T. Fengler (Editor) Working Group: Commercial Layer Created: 2026-05-26 Targets: 1.2 Extends: RFC 0013, RFC 0014, RFC 0032 Affects: RFC 0001 (Sessions), RFC 0004 (Delegation), RFC 0006 (Scope Policy), RFC 0007 (CCC), RFC 0009 (Reputation), RFC 0013 (Commerce Models), RFC 0014 (Commerce Primitives), RFC 0032 (Payment Instrument Adapter Protocol).

1. Summary

This RFC defines a normative interoperability adapter specification that bridges Google's Agent Payments Protocol (AP2, September 2025, co-developed with 60+ industry partners) and the Open Agent Protocol's (OAP) commercial governance layer.

AP2 standardizes agent payment pre-authorizations using a chain of three cryptographically bound Mandates modeled as W3C Verifiable Credentials (VCs): Intent Mandate, Cart Mandate, and Payment Mandate. AP2 utilizes JSON-LD formats, ECDSA signatures, and Selective Disclosure JSON Web Tokens (SD-JWTs) for privacy-preserving claims.

This specification maps AP2's 3-mandate chain to OAP's Payment Mandates, Payment Sessions, and Settlement Confirmations as defined in RFC 0032. It enables dual-signature validation (ECDSA for AP2 and EdDSA for OAP), secure mandate chain integrity checks, automatic OAP Receipt generation, and full integration with OAP's Policy Engine and B2B Confidentiality & Compliance Contexts (CCC). It also standardizes the bridging of the A2A x402 protocol extension for cryptographic settlement rails.

2. Motivation

2.1 The Industry Standard Convergence

Google's AP2 protocol, launched in late 2025 with backing from 60+ major technology and retail partners, has emerged as a major commercial protocol for consumer-facing agent payments. AP2 standardizes the concept of pre-authorized agent spending via three linked verifiable credentials, avoiding repeated Strong Customer Authentication (SCA) challenges while preventing unauthorized transaction alteration.

At the same time, OAP's commercial layer (RFC 0013, RFC 0014, RFC 0032) provides the industry's most robust multi-layer policy engine, hash-chained transaction receipting, and compliance isolation (CCC) required for enterprise B2B and highly regulated agent transactions.

Rather than forcing wallet operators and agents to choose between the public scale of AP2 and the enterprise governance of OAP, this RFC provides a normative bidirectional adapter that maps between the two protocols. By standardizing this adapter, OAP agents can utilize AP2-compatible consumer wallets to transact at AP2-enabled merchants, and enterprise-grade OAP Wallets can seamlessly process and govern AP2 transaction chains under organization-specific policies.

2.2 Bridging the Cryptographic Divide

The two protocols utilize different cryptographic and packaging standards:

  • AP2 relies on W3C Verifiable Credentials, JSON-LD, ECDSA signatures (secp256r1 or secp256k1), and SD-JWTs for selective disclosure of consumer identity and cart items.
  • OAP relies on JSON schemas, EdDSA signatures (Ed25519) on DID-anchored keys, and a sequential, hash-chained transaction receipt architecture.

The adapter specified herein resolves this cryptographic mismatch by defining dual-signature validation mechanics, allowing an OAP-governed system to act as a bridge that validates AP2 credentials while producing compliant OAP receipting.

3. Specification

3.1 Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 and RFC 8174.

AP2 Intent Mandate: A W3C Verifiable Credential signed by a principal (user) authorizing an agent to explore shopping options within a specific category, budget, and time-frame. This maps to the OAP Payment Mandate.

AP2 Cart Mandate: A W3C Verifiable Credential signed by the agent that binds a specific shopping cart (products, quantities, and merchant DID) to the Intent Mandate. This maps to the OAP Payment Session.

AP2 Payment Mandate: A W3C Verifiable Credential, packaged as an SD-JWT, signed by the user's issuer/wallet containing the final authorized payment token or instrument details linked to the Cart Mandate. This maps to the OAP Settlement Confirmation.

Dual-Signature Verification: The process of validating a message or credential containing both an ECDSA signature (validating the AP2 protocol claim) and an EdDSA signature (validating the OAP conformance claim).

A2A x402 Extension: A protocol extension that adds native cryptocurrency and stablecoin payment rail capabilities (e.g., Lightning Network, EVM stablecoins) to the AP2 mandate structure, mapping directly to RFC 0032 payment rails.

3.2 AP2 Mandate Chain Architecture

The AP2 payment flow operates via three chained credentials, where each step inherits and binds the cryptographic state of the previous step:

graph TD
    User["Principal (User)"] -->|Signs secp256r1| IM["1. AP2 Intent Mandate (VC)"]
    Agent["AI Agent"] -->|Signs secp256r1| CM["2. AP2 Cart Mandate (VC)"]
    IM -->|Cryptographically Bound| CM
    Wallet["User Wallet (Issuer)"] -->|Signs SD-JWT secp256r1| PM["3. AP2 Payment Mandate (VC)"]
    CM -->|Cryptographically Bound| PM

The adapter maps this 3-step chain to the OAP RFC 0032 entities:

AP2 EntityOAP EntityPrimary Mapping Mechanic
AP2 Intent MandateOAP Payment MandateMaps principal DIDs, global spend limits, expiration windows, and allowed categories.
AP2 Cart MandateOAP Payment SessionMaps cart items, merchant DIDs, and session amounts into a short-lived OAP Session.
AP2 Payment Mandate (SD-JWT)OAP Settlement ConfirmationExtracts verified payment preimages or token hashes and formats them as OAP Settlement records.

3.3 AP2 Intent Mandate ↔ OAP Payment Mandate Mapping

A conforming adapter MUST translate an AP2 Intent Mandate into an OAP Payment Mandate and vice-versa.

3.3.1 Inbound Mapping (AP2 to OAP)

When an agent or wallet receives an AP2 Intent Mandate, the adapter MUST convert it into a compliant RFC 0032 Payment Mandate structure:

  • mandate_id: Map directly from the AP2 credential's id (or format as urn:oap:mandate:{id}).
  • principal_did: Extracted from the credentialSubject.holder or credentialSubject.userDid field in AP2.
  • agent_did: Extracted from the credentialSubject.agentDid field.
  • wallet_did: Extracted from the issuer DID of the credential or derived from the wallet endpoint.
  • constraints.max_single_payment: Extracted from AP2's limits.singleTransactionLimit.
  • constraints.max_daily_spend: Extracted from AP2's limits.dailyLimit.
  • constraints.allowed_categories: Extracted from AP2's scope.allowedCategories.
  • validity.not_before / not_after: Extracted from the credential's validFrom and validUntil timestamps.

3.3.2 Outbound Mapping (OAP to AP2)

The reverse mapping MUST package an OAP Payment Mandate into a W3C Verifiable Credential matching the AP2 Intent Mandate schema, signing the credential using the principal's ECDSA private key.

3.4 AP2 Cart Mandate ↔ OAP Payment Session Mapping

A Cart Mandate represents a concrete shopping basket. The adapter maps this to the short-lived OAP Payment Session.

3.4.1 Inbound Mapping (AP2 to OAP)

The adapter constructs the OAP Payment Session:

  • session_id: Derived from the Cart Mandate id.
  • mandate_id: Extracted from the Cart Mandate's reference to the parent Intent Mandate (parentIntentId).
  • amount: Extracted from the Cart Mandate's cart.totalAmount object (carrying value and ISO currency code).
  • counterparty_did: Extracted from the cart.merchantDid field.
  • purpose: Derived from cart.description or set to a standard category description.
  • commerce_primitive: Defaulted based on the merchant category (e.g., retail_purchase).

3.4.2 Verification of Cart Integrity

The adapter MUST verify that the hash of the cart items listed in the Cart Mandate matches the hash embedded in the subsequent checkout transaction. If there is a mismatch, the adapter MUST fail the OAP Session creation with a code of invalid_cart_hash.

3.5 AP2 Payment Mandate (SD-JWT) ↔ OAP Settlement Confirmation Mapping

The AP2 Payment Mandate contains the finalized payment authorization token. In consumer deployments, this is packaged as a Selective Disclosure JWT (SD-JWT) to selectively hide the user's real-world identity from the merchant while proving the payment capability.

3.5.1 Inbound Mapping (AP2 to OAP)

The adapter processes the AP2 Payment Mandate:

  • settlement_ref: Extracts the transaction identifier or authorization code from the JWT's disclosed claims (e.g., payment.transactionId or payment.authCode).
  • amount: Extracted from the confirmed payment.finalAmount claim.
  • instrument_id: Derived from the payment rail selected (e.g., card-visa, lightning-btc).
  • timestamp: Extracted from the JWT's iat or payment.timestamp claim.

3.5.2 Decoupling Disclosures

If the payment mandate utilizes SD-JWT selective disclosure, the adapter MUST verify all disclosed disclosures against the JWT signature. The resulting OAP Settlement Confirmation MUST include a hash of the raw SD-JWT inside the instrument_metadata field to preserve auditability without storing personal information plain-text.

3.6 Dual-Signature Verification

To satisfy both AP2's W3C compliance and OAP's policy layer, the adapter supports a dual-signature envelope.

When an agent invokes a wallet or merchant:

  1. The payload MUST contain the AP2 signature block (ECDSA utilizing secp256r1 with a kid referencing the sender's DID document).
  2. The payload MUST contain the OAP signature block (EdDSA utilizing ed25519 with a kid referencing the OAP agent key).

A conforming adapter MUST validate both signatures:

  • If the ECDSA signature is invalid, the adapter MUST reject the request with an HTTP 400 Bad Request / JSON-RPC error mapping to invalid_ap2_signature.
  • If the EdDSA signature is invalid or fails key-rotation policies under RFC 0024, the adapter MUST reject the request with invalid_oap_signature.

3.7 AP2 Mandate Chain Validation

Before executing any payment, the adapter MUST run the following mandate chain validation sequence:

  Verify Intent Mandate (Principal) -> PASS
                |
                v
  Verify Cart Mandate (Agent) --------> PASS (Verify parentIntentId == Intent.id)
                |
                v
  Verify Payment Mandate (Wallet) ----> PASS (Verify parentCartId == Cart.id)
  1. Verify Intent Mandate: Ensure the principal's signature is valid and the timestamp is current.
  2. Verify Cart Mandate: Ensure the agent's signature is valid, the parentIntentId matches the Intent Mandate's id, and the total cart amount is less than or equal to the Intent Mandate's single transaction limit.
  3. Verify Payment Mandate: Ensure the wallet operator's signature is valid, the parentCartId matches the Cart Mandate's id, and the payment amount matches the Cart Mandate's amount exactly.

If any link in the chain fails validation, the adapter MUST reject the flow immediately.

3.8 OAP Receipt Generation from AP2 Settlements

Upon successful validation of the AP2 mandate chain and confirmation of settlement, the adapter MUST generate an OAP Receipt. The Receipt:

  • MUST be typed as commerce_settlement_confirmed.
  • MUST include the prev_hash pointing to the prior receipt in the principal's OAP Receipt chain.
  • MUST contain the base64-encoded SHA-256 hash of the AP2 Payment Mandate SD-JWT.
  • MUST be signed by the agent's EdDSA key.

This ensures that the AP2 transaction's finality is cryptographically bound into the principal's secure transaction history.

3.9 A2A x402 Extension for Crypto Payments

The A2A x402 extension adds cryptocurrency and stablecoin payment rail capabilities to AP2 mandates. The adapter bridges this by mapping x402 claims directly into the corresponding RFC 0032 payment instruments:

  • EVM Stablecoins (USDC/USDT): x402 EVM transaction details map directly to the evm_stablecoin rail in OAP. The on-chain transaction hash is treated as the OAP settlement_ref.
  • Lightning Network: x402 Lightning invoices and preimages map to the lightning_network rail. The payment preimage acts as the OAP settlement_ref proving irrevocable payment finality.

4. Wire Format Examples

4.1 AP2 Intent Mandate (W3C VC - Input)

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://openagentprotocol.eu/contexts/ap2-v1.jsonld"
  ],
  "id": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
  "type": ["VerifiableCredential", "AgentIntentMandate"],
  "issuer": "did:web:wallet.example",
  "issuanceDate": "2026-05-26T12:00:00Z",
  "expirationDate": "2026-06-26T12:00:00Z",
  "credentialSubject": {
    "holder": "did:web:alice.example",
    "agentDid": "did:web:alice-agent.example",
    "scope": {
      "allowedCategories": ["retail_purchase", "physical_goods"]
    },
    "limits": {
      "singleTransactionLimit": {
        "amount": "250.00",
        "currency": "EUR"
      },
      "dailyLimit": {
        "amount": "1000.00",
        "currency": "EUR"
      }
    }
  },
  "proof": {
    "type": "JsonWebSignature2020",
    "created": "2026-05-26T12:00:05Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:web:alice.example#key-1",
    "jws": "eyJhbGciOiJFUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..MEQCIH3..."
  }
}

4.2 Mapped OAP Payment Mandate (Output)

{
  "mandate_id": "urn:oap:mandate:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
  "version": "1.0",
  "principal_did": "did:web:alice.example",
  "agent_did": "did:web:alice-agent.example",
  "wallet_did": "did:web:wallet.example",
  "constraints": {
    "max_single_payment": { "amount": "250.00", "currency": "EUR" },
    "max_daily_spend": { "amount": "1000.00", "currency": "EUR" },
    "max_monthly_spend": null,
    "allowed_categories": ["retail_purchase", "physical_goods"],
    "require_confirmation_above": { "amount": "150.00", "currency": "EUR" },
    "allowed_instruments": ["sepa-ct", "card-visa", "lightning-btc"],
    "allowed_jurisdictions": ["EU"]
  },
  "validity": {
    "not_before": "2026-05-26T12:00:00Z",
    "not_after": "2026-06-26T12:00:00Z"
  },
  "cooling_off_class": "irreversible_financial",
  "signatures": [
    {
      "by": "did:web:alice.example",
      "alg": "EdDSA",
      "value": "z3A1F4G2..."
    }
  ]
}

4.3 AP2 Cart Mandate (W3C VC - Input)

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://openagentprotocol.eu/contexts/ap2-v1.jsonld"
  ],
  "id": "urn:uuid:7c9e0a2b-8c7d-4f3e-9b5a-1c2d3e4f5a6b",
  "type": ["VerifiableCredential", "AgentCartMandate"],
  "issuer": "did:web:alice-agent.example",
  "issuanceDate": "2026-05-26T12:05:00Z",
  "credentialSubject": {
    "parentIntentId": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
    "merchantDid": "did:web:acme-running.example",
    "cart": {
      "totalAmount": {
        "amount": "89.99",
        "currency": "EUR"
      },
      "itemsHash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "items": [
        {
          "itemId": "SKU-RUN-43-BLK",
          "title": "ACME ProRunner 43 Black",
          "quantity": 1,
          "unitPrice": "89.99"
        }
      ]
    }
  },
  "proof": {
    "type": "JsonWebSignature2020",
    "created": "2026-05-26T12:05:02Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:web:alice-agent.example#key-1",
    "jws": "eyJhbGciOiJFUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..MEYCIQ..."
  }
}

4.4 Mapped OAP Payment Session (Output)

{
  "session_id": "urn:oap:session:7c9e0a2b-8c7d-4f3e-9b5a-1c2d3e4f5a6b",
  "status": "authorized",
  "mandate_id": "urn:oap:mandate:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
  "expires_at": "2026-05-26T13:05:00Z",
  "amount": { "value": "89.99", "currency": "EUR" },
  "instrument_id": "card-visa",
  "counterparty_did": "did:web:acme-running.example",
  "purpose": "Purchase of ACME ProRunner 43 Black",
  "commerce_primitive": {
    "preset": "retail_purchase"
  },
  "idempotency_key": "cart_7c9e0a2b_89_99",
  "signature": {
    "alg": "EdDSA",
    "by": "did:web:wallet.example",
    "value": "z5F8G9J1..."
  }
}

5. Backward Compatibility

This RFC defines an optional interoperability adapter. Existing OAP Core 1.0/1.1 and RFC 0032 implementations are unaffected if they do not require AP2 interoperability.

Conforming AP2 adapters MUST implement backwards-compatible fallback mechanisms:

  1. Fallback to RFC 0032 Native: If the wallet does not support AP2 mandates, the adapter MUST fallback to the direct OAP Session initiation flow of RFC 0032 section 3.4.
  2. Fallback to A2A Legacy: When interacting with older A2A agent profiles that do not support W3C VCs, the adapter MUST translate raw JSON-RPC task payloads instead of validating the JSON-LD mandate chain.

6. Security Considerations

Cross-Protocol Replay Attacks: Because AP2 mandates are W3C Verifiable Credentials signed by the principal, an adversary who captures these credentials could attempt to replay them against another OAP Wallet. The adapter MUST prevent this by:

  • Verifying the wallet_did inside the Intent Mandate matches the receiving Wallet's DID.
  • Maintaining a cache of processed AP2 Credential IDs (id URI field) and rejecting any already-processed mandate credential.

Signature Confusion: Because the adapter processes dual-signature payloads containing both ECDSA and EdDSA signatures, a malicious actor could attempt to trick the system by omitting one signature type or binding an ECDSA key to an EdDSA verification pipeline. The adapter MUST verify each signature against its dedicated public key type and DID validation path independently.

Cart Overcharging: A merchant could alter prices between the Cart Mandate generation and the actual payment invocation. The adapter MUST verify that the final Payment Mandate amount matches the Cart Mandate amount exactly.

7. Privacy Considerations

Selective Disclosure Compliance: The adapter MUST preserve the privacy characteristics of AP2's SD-JWT structure. When converting the AP2 Payment Mandate to an OAP Settlement Confirmation, the adapter MUST NOT log or expose the claims that the user opted to keep hidden (such as their billing address or real-world name) unless required by regulatory regimes (e.g., AML/KYC for high-value transactions).

Receipt Anonymization: For transactions marked as highly confidential under an active OAP CCC (RFC 0007), the generated OAP Receipt MUST replace individual itemized cart details with a single encrypted payload hash, keeping the purchase contents shielded from external ledger audits.

8. Conformance Impact

An OAP implementation claiming AP2 Interoperability Adapter Conformance (AP2-IAC) MUST:

  1. Conform to all requirements of RFC 0032 (Payment Instrument Adapter Protocol).
  2. Successfully execute the AP2 Intent Mandate ↔ OAP Payment Mandate mapping rules (Section 3.3).
  3. Successfully execute the AP2 Cart Mandate ↔ OAP Payment Session mapping rules (Section 3.4).
  4. Successfully execute the AP2 Payment Mandate (SD-JWT) ↔ OAP Settlement Confirmation mapping rules (Section 3.5).
  5. Implement the dual-signature verification mechanism (Section 3.6).
  6. Implement the 3-step AP2 Mandate Chain Validation sequence (Section 3.7).
  7. Produce valid OAP Receipts of type commerce_settlement_confirmed containing hashed SD-JWT references (Section 3.8).

9. References

  • RFC 0013, Commerce Models for the Agent Economy.
  • RFC 0014, Commerce Primitives, A Generalized Commercial Layer.
  • RFC 0032, Payment Instrument Adapter Protocol.
  • RFC 0007, Confidentiality and Compliance Context.
  • RFC 0006, Scope Policy.
  • W3C, Verifiable Credentials Data Model v2.0 (2025).
  • IETF, Selective Disclosure JSON Web Token (SD-JWT) RFC 9831 (2025).
  • Google, Agent Payments Protocol (AP2) v1.0. Technical specification (2025).
  • Coinbase, A2A x402 Extension for Crypto Payments (2025).