> For the complete documentation index, see [llms.txt](https://docs.toolkit.equs.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.toolkit.equs.ai/standards/agentic/ap2/flow-1.md). # Flow 1: Use Your Own Agent Wallet Your agent keeps its own key and grant; the platform puts the mandate in front of the User and verifies what comes back **Flow 1** is for agents that already have a wallet of their own, or that you'd rather keep entirely on your side. Your back end sends the agent's **public** key with the mandate request, the User approves in their wallet, and the platform verifies the response. The private key never reaches the platform, and nothing is stored for you. What the platform doesn't do on this flow is **close** the mandate. Holding the grant, and signing Closed mandates over it with the agent's key, are yours. ```mermaid flowchart LR A["Your back end asks for a mandate,
with the agent's public key"] --> B["User approves
in the EQUS Wallet"] B --> C["Your back end collects
and verifies the response"] C --> D["Your agent
holds the grant"] D --> E["Your agent signs Closed mandates
with its own key"] style C fill:#e6f4ea,stroke:#34a853 style E fill:#e8f0fe,stroke:#4285f4 ``` ### At a glance | | | | ----------------- | ------------------------------------------------------------------------------------------------------------- | | **Calls on** | Integration API | | **Agent key** | Yours. Only the public key is sent | | **Grant storage** | Yours | | **Closing** | Yours, with the agent's private key and your own delegation tooling | | **Human present** | Supported: send Closed mandates only, and the verified response is the Closed mandate - nothing left to close | | **Status** | Available | **Pick this flow** when your agent already runs its own key management, when nothing about your agent may be held by the platform, or when the User is present and approves one concrete checkout - the simplest AP2 journey there is. ### The agent key `agentKey` is the agent's public key, written as JWK. Use a P-256 key, like the one below: ```json { "kty": "EC", "crv": "P-256", "x": "…", "y": "…", "alg": "ES256" } ``` The platform writes it into every Open mandate in the request, so only whoever holds the matching private key can act on them later. It is **required** when the request carries Open mandates, and **not allowed** when every mandate is Closed. * **Send the public part only.** The request needs nothing else. * **Prefer a fresh key per request.** Every mandate bound to the same key can be linked through it. * **The platform can't prove the agent holds the key.** OID4VP gives the Verifier no way to ask for proof of possession before the request, so the key you send is taken as given. Make sure it's the right one. ### Holding and closing the grant For Open mandates, verification leaves you with the **grant**: the User's credential, with the mandates they signed on top of it as a bound hop naming your agent's key. The platform keeps nothing, so store it with the agent. Closing adds a terminal hop to that same credential - see [Delegation](/standards/agentic/delegation.md). When a merchant offers a checkout, the agent signs the Closed mandates with its private key, carrying the merchant-signed checkout and naming the merchant as the audience. Mandate shapes are in [Mandate Reference](/standards/agentic/ap2/mandate-reference.md). {% hint style="warning" %} **Keep the Closed content inside what the User approved** - the items, merchants, amounts and dates - and link each checkout to its payment. The signatures prove who signed, not that the content fits: the merchant or payment provider verifying the artifact has to check that, and will reject it if it doesn't. Checking before you sign saves your agent from producing artifacts that get turned away. {% endhint %} ### What you'll do {% stepper %} {% step %} #### Configure Create a Verifier and a single-input VP Schema - see [Agentic Payments (AP2)](/standards/agentic/ap2.md) - and have your agent's key pair ready. {% endstep %} {% step %} #### Integrate Pick how the User approves: through Embed UI - see [Method 1: Embed UI + API](/standards/agentic/ap2/flow-1/embed-ui-and-api.md) - or through screens you build - see [Method 2: Build Your Own UI](/standards/agentic/ap2/flow-1/build-your-own-ui.md). {% endstep %} {% step %} #### Implement closing Give your agent a place to store verified grants, and the signing step that turns a grant into Closed mandates for one checkout - see Holding and closing the grant, above. The platform has no call for this on Flow 1. {% endstep %} {% endstepper %} ### How it works The common case, Human not present. With Closed mandates instead, the verified response is already the Closed mandate, and there is nothing to store or close. ```mermaid sequenceDiagram autonumber actor U as User participant W as EQUS Wallet participant A as Your back end and agent participant P as Platform participant M as Merchant Note over U,M: The User sets the bounds A->>P: request Open mandates - Red Sneakers, up to USD 500
plus the agent's public key P->>A: mandate request - requestUri, txId A->>W: show the request to the User U->>W: approve the bounds W->>P: the mandates, signed by the User
over their credential A->>P: collect and verify the User's response - txId P->>A: verified - the User's credential with the signed
mandates on top, bound to the agent's key Note over A: store the grant with the agent Note over U,M: Later, with the User elsewhere A->>M: shop within the bounds M->>A: checkout, signed by the merchant A->>A: close the grant - sign Closed mandates for this
checkout and payment, with the agent's private key A->>M: Closed mandates - the grant plus
this checkout and payment M->>M: check the signatures back to the User's credential,
and that the purchase fits the bounds Note over A,M: closing, delivery and payment happen outside the platform ``` ### Choose a method

:window-restore:

Method 1: Embed UI + APIEmbed UI opens the User's Web Wallet over your page; your back end creates and verifies.Method 1: Embed UI + API

:code:

Method 2: Build Your Own UIYou deliver the request, collect the response and verify it from your back end.Method 2: Build Your Own UI
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.toolkit.equs.ai/standards/agentic/ap2/flow-1.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.