---
title: "Agent protocols compared: VI, AP2, TAP and Web Bot Auth"
url: https://knowyouragent.ch/en/knowledge/agent-protocols-compared
lang: en
updated: 2026-10-13
license: © Innopulse Consulting GmbH
---

# Agent protocols compared: VI, AP2, TAP and Web Bot Auth

The approaches for AI agents answer different questions. Some identify the agent, others prove the customer's intent, others again govern checkout. Anyone comparing them should first ask: which question does the approach solve?

[Leutrim Miftaraj](https://knowyouragent.ch/en/about/leutrim-miftaraj), Founder, Innopulse Consulting GmbH
Published 13 October 2026

## Key points

- The approaches answer two questions: who is asking, and what did the customer want?
- Web Bot Auth and the Trusted Agent Protocol identify agents; Verifiable Intent and AP2 prove intent.
- SD-JWT and HTTP signatures following RFC 9421 are the common building blocks.
- Openness differs more than technology; it decides whether independent verification is possible.

## Two levels: identity and intent

One group of approaches answers the question “Who is asking?”. [Web Bot Auth](https://knowyouragent.ch/en/knowledge/glossary/web-bot-auth) and the [Trusted Agent Protocol](https://knowyouragent.ch/en/knowledge/glossary/trusted-agent-protocol) sign HTTP requests so websites can recognize an agent's operator. Another group answers “What did the customer want?”. [Verifiable Intent](https://knowyouragent.ch/en/knowledge/glossary/verifiable-intent) and [AP2](https://knowyouragent.ch/en/knowledge/glossary/ap2) bind a purchase to a signed intent with limits.

Both levels are needed. A valid identity says nothing about authority, and a signed intent is of little use if it remains unclear which agent presents it. The Agentic Commerce Protocol sits across both: it describes the exchange at checkout.

## The comparison

| Approach | Origin | Answers | Format | Verification in KYA |
|---|---|---|
| Verifiable Intent | Mastercard | Intent and limits of a purchase | Layered SD-JWT | full |
| AP2 | Google | Intent, cart, payment | Mandates; variant on SD-JWT | VI variant full, classic JSON recognized |
| Trusted Agent Protocol | Visa | Agent toward merchant | HTTP signatures (RFC 9421) | Signature following RFC 9421 |
| Web Bot Auth | Cloudflare, IETF draft | Operator of a request | HTTP signatures (RFC 9421) | full |
| Agentic Commerce Protocol | OpenAI, Stripe | Checkout flow | Interface specification | out of scope |
| KYA evidence | open verification profile | Mandate, decision, receipt, time | SD-JWT VC, JWS, kya-pack/1 | full |

As of 13 October 2026. The approaches evolve quickly; the linked specifications are authoritative.

## Cryptography and formats

The approaches build on a few well-established building blocks. For credentials with selective disclosure, SD-JWT is becoming the norm, also used by government wallets such as the Swiss e-ID and the EUDI wallet. For identifying agents on the web, [HTTP Message Signatures following RFC 9421](https://knowyouragent.ch/en/knowledge/glossary/http-message-signatures) dominate. Common algorithms are Ed25519, ECDSA and RSA-PSS.

For verifying parties, that is good news. Whoever can verify SD-JWT, JWS and RFC 9421 covers most of today's approaches. Differences lie mainly in the fields and bindings each approach defines.

## Openness and licenses

Openness differs more than technology. Verifiable Intent and the Web Bot Auth reference implementation are available under the Apache 2.0 license. AP2 is designed as an open protocol. The sample code of the Trusted Agent Protocol is subject to Visa's own product terms.

For independent verification, what counts is whether specification and test data are freely available. Only then can a second implementation be built that reaches the same results. KYA therefore publishes its [verification profile](https://knowyouragent.ch/en/standard/verification-profile) under CC BY 4.0 and its [test vectors](https://knowyouragent.ch/en/standard/test-vectors) under Apache 2.0.

## Which approach for what?

- **A website wants to know whose agent is asking:** Web Bot Auth, and for Visa payments the Trusted Agent Protocol.
- **A payment should be bound to the customer's intent:** Verifiable Intent or AP2.
- **A shop wants to offer agents a checkout:** Agentic Commerce Protocol.
- **An action should be proven independently of payment network and vendor:** mandate, decision and receipt following the KYA verification profile.

In practice, several approaches appear together. An agent can sign its requests following Web Bot Auth and at the same time present an intent following Verifiable Intent.

## One verifier for all approaches

For merchants, banks and platforms, it would be laborious to verify each approach separately and assess the results differently. KYA therefore maps all supported formats onto the same [ten checks](https://knowyouragent.ch/en/method/checks) and [five levels](https://knowyouragent.ch/en/method/levels). A merchant can thus define a uniform rule, regardless of which approach an agent uses.

What KYA does not verify, the certificate states explicitly instead of failing silently. [Try the examples](https://knowyouragent.ch/en/verify).

## How the approaches are evolving

The approaches for agents are young and change quickly. Several providers are working on common foundations in bodies such as the IETF and the FIDO Alliance, and individual approaches are converging, such as AP2 and Verifiable Intent. For verifying parties, this means: whoever relies on open building blocks such as SD-JWT and RFC 9421 and ties verification to a neutral [verifier](https://knowyouragent.ch/en/knowledge/glossary/verifier) does not have to rebuild everything with every change.

## Frequently asked questions

### Do Verifiable Intent and AP2 compete?

Both bind a purchase to the customer's intent. One AP2 variant uses the same layered logic as Verifiable Intent; the approaches are converging.

### Is Web Bot Auth enough for a purchase?

No. Web Bot Auth proves whose agent is asking, not what it may do. A purchase also requires proof of authority.

### Why does KYA verify the Trusted Agent Protocol only partly?

KYA verifies the underlying HTTP signature following RFC 9421. For the additional fields, there is no freely licensed reference against which an implementation could be proven.

### Which approach should a merchant support first?

That depends on customers and payment methods. A verifier that checks several approaches by the same rules makes sense, so no commitment to a single approach is needed.

### Where can I find the specifications of the approaches?

In the linked sources at the end of this article. The approaches evolve quickly; the current version of each specification is authoritative.

### Can KYA add new approaches?

Yes, if specification and test data are freely available. New formats are mapped onto the same ten checks and backed by test vectors.

### Do I need separate keys for every approach?

Not necessarily. Many approaches use the same algorithms. Which keys an agent needs is defined by the operator and the approach.

## Sources

- Verifiable Intent (Mastercard): [https://github.com/agent-intent/verifiable-intent](https://github.com/agent-intent/verifiable-intent)
- Agent Payments Protocol (AP2): [https://github.com/google-agentic-commerce/AP2](https://github.com/google-agentic-commerce/AP2)
- Trusted Agent Protocol (Visa): [https://github.com/visa/trusted-agent-protocol](https://github.com/visa/trusted-agent-protocol)
- Web Bot Auth: Architektur-Entwurf (IETF): [https://datatracker.ietf.org/doc/draft-meunier-web-bot-auth-architecture/](https://datatracker.ietf.org/doc/draft-meunier-web-bot-auth-architecture/)
- RFC 9421: HTTP Message Signatures: [https://www.rfc-editor.org/rfc/rfc9421](https://www.rfc-editor.org/rfc/rfc9421)
- Agentic Commerce Protocol: [https://www.agenticcommerce.dev/](https://www.agenticcommerce.dev/)

---
Quelle: https://knowyouragent.ch/en/knowledge/agent-protocols-compared · KYA – Know Your Agent