Mandact — The Trust Layer of the Agent Economy

Standards

The standards behind the agent mandate

SD-JWT VC, OID4VCI, OID4VP, Token Status List, Web Bot Auth, Verifiable Intent, AP2, RFC 9396, RFC 7662, DIDs: what each standard governs — and how Mandact uses it.

SD-JWT VC: the format of the agent mandate

SD-JWT VC (Selective Disclosure JSON Web Token, Verifiable Credential) is the credential format used by the EUDI wallet and the Swiss E-ID infrastructure. Individual claims are hashed and disclosed only when needed — the verifier sees the necessary fields, not the whole document.

OID4VCI: how credentials are issued

OpenID for Verifiable Credential Issuance (OID4VCI) standardises how a wallet or an agent fetches a credential from an issuer — with a token, a nonce and proof of possession. It is the issuance path of the EUDI and E-ID world.

OID4VP: how an agent shows its mandate

OpenID for Verifiable Presentations (OID4VP) covers the opposite direction: a verifier makes a request, the holder answers with a presentation that discloses only the requested claims. It is the presentation path of the EUDI wallet.

Token Status List: revocation anyone can check

The Token Status List is a compact, signed bit array in which an issuer publishes the status of many credentials. A verifier looks up whether a specific credential is still valid — without revealing to the issuer which one it is checking.

Web Bot Auth (RFC 9421): the agent identifies itself at the HTTP layer

Web Bot Auth uses HTTP Message Signatures per RFC 9421: an agent signs every request with its key and points to a directory where the key is published. Networks such as Cloudflare and Visa's Trusted Agent Protocol thus recognise it as a registered agent.

Mastercard Verifiable Intent: a three-layer chain for agent purchases

Verifiable Intent (VI) is Mastercard's open specification for agent purchases: a three-layer SD-JWT chain of the principal's identity (L1), the mandate (L2) and the transaction context (L3). It is one of the two contributions from which the FIDO Alliance develops its agentic commerce specification.

AP2 (Agent Payments Protocol): mandates for agent payments

Google's Agent Payments Protocol chains intent, cart and payment mandates as signed credentials and has been with the FIDO Alliance since April 2026. Version 0.2 allows payments without a human present, based on pre-authorised instructions.

RFC 9396 Rich Authorization Requests: more than a scope

Rich Authorization Requests extend OAuth with structured authorization_details: instead of a coarse scope like payments, the request describes exactly what should be allowed — type, amount, recipient. This lets an access token carry real authority.

RFC 7662 Token Introspection: querying the status live

Token introspection lets a resource server ask the authorisation server whether a token is still active and what it allows. For mandates it is the mechanism that enforces a revocation immediately.

did:web and did:key: identifiers for issuers and agents

Decentralized Identifiers (DIDs) are identifiers with an associated document of public keys. did:web publishes this document under a domain, did:key derives it directly from the key — two variants for two roles.