Standards around agent authority
As of October 2026. Which standards answer which question and which gap independent verification closes.
In short
Identity standards say who acts; AP2 and Verifiable Intent describe intent. KYA independently verifies whether an action was provably covered.
Four layers
| Layer | Question | Typical standards |
|---|---|---|
| Identity | Who is acting? | OAuth, OpenID Connect, workload identities, DIDs, Web Bot Auth |
| Authority and intent | What is allowed, what was intended? | SD-JWT VC, AP2, Verifiable Intent |
| Receipt | What actually happened? | Signed receipts, hash chains, RFC 3161 |
| Independent verification | Can a third party recompute it? | Open formats, test vectors, reproducible reports |
Most initiatives work on the first two layers. KYA works on the fourth and verifies the third.
SD-JWT VC and OpenID4VP
SD-JWT VC is the IETF format for verifiable credentials with selective disclosure: the issuer signs hashes, the holder discloses only the parts needed. A key binding JWT proves that the presenter holds the bound key. OpenID for Verifiable Presentations governs how such a credential is requested and presented. For agent mandates this is the obvious foundation, because a mandate must disclose its scope but not every detail of the principal.
IETF Token Status List
A compressed bit list in which every issued credential has an index. One or more bits indicate valid, revoked or suspended. For agents, revocation is not a side issue: a mandate that cannot be revoked is an authority without an emergency brake.
RFC 3161 and trust anchors
An RFC 3161 timestamp confirms that a specific hash existed at a specific time. How much it proves depends on the anchor: a timestamp is as trustworthy as the authority it can be traced back to. Qualified timestamps under ZertES or eIDAS have a special legal effect but require a recognized provider. More on this
Web Bot Auth
Web Bot Auth uses HTTP Message Signatures per RFC 9421 so that an automated client signs its requests and a website can recognize it. That answers which agent is requesting – not whether it may perform a specific action on someone's behalf.
AP2 and Verifiable Intent
The Agent Payments Protocol (AP2) describes mandates for agentic commerce in three forms: intent, cart and payment. Verifiable Intent describes a verifiable record of the intent approved by the user and is aligned with AP2. Both contributions moved into the FIDO Alliance's standardization in April 2026. KYA verifies Verifiable Intent chains in immediate and autonomous mode according to the official reference; classic AP2 JSON mandates are recognized and reported as such. All approaches compared
The FIDO working groups
On 28 April 2026 the FIDO Alliance announced two workstreams: a new Agentic Authentication Technical Working Group chaired by CVS Health, Google and OpenAI, and specifications for agent-initiated commerce in the Payments Technical Working Group chaired by Mastercard and Visa. The starting points are the contributions AP2 from Google and Verifiable Intent from Mastercard.
Where KYA comes in
| Standard | Provides | KYA check |
|---|---|---|
| SD-JWT VC | Signed mandate with selective disclosure | Integrity, issuer, agent and principal, validity, scope |
| Key binding | Agent's proof of possession | Agent and principal |
| Token Status List | Revocation status | Revocation |
| JWS | Signed decision | Integrity, issuer, scope |
| Hash chain | Immutable sequence of receipts | Integrity, execution receipt |
| RFC 3161 | Point in time with anchor | Timestamp |
| Verifiable Intent, AP2 | Purchase and intent mandates | Integrity, issuer, agent and principal, validity, scope, delegation, execution receipt |
Sources
- FIDO Alliance, announcement of 28 April 2026: https://www.fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/
- Verifiable Intent, reference repository: https://github.com/agent-intent/verifiable-intent
- IETF, SD-JWT-based Verifiable Credentials: https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
- IETF, Token Status List: https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/
- OpenID for Verifiable Presentations 1.0: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
- RFC 3161, Time-Stamp Protocol: https://www.rfc-editor.org/rfc/rfc3161
- RFC 9421, HTTP Message Signatures: https://www.rfc-editor.org/rfc/rfc9421
- RFC 8785, JSON Canonicalization Scheme: https://www.rfc-editor.org/rfc/rfc8785