AI Agent Authentication and Authorization

AI Agent Authentication and Authorization is the document that says the quiet part out loud: the agent identity problem is mostly already solved, and the industry is busy reinventing it anyway. Pieter Kasselman (Defakto Security), Jean-François Lombardo (AWS), Yaroslav Rosomakho (Zscaler) and Brian Campbell (Ping Identity) filed it as an individual IETF submission on 2 March 2026, intended status Informational. It defines no new protocol. Its entire contribution is a claim about composition — an agent is a workload — and then a walk through which existing specification covers each step once you accept that.

• One identifier, and it is a URI - An agent MUST be assigned exactly one WIMSE identifier, which MAY be a SPIFFE ID of the form spiffe://<trust-domain>/<path>. Stable for the lifetime of the workload identity, because authorization, delegation and audit all key on it.
• The identifier is worthless without a cryptographic binding - Credentials are X.509 certificates, Workload Identity Tokens (WITs), or SPIFFE SVIDs in JWT/X.509/WIT form. They SHOULD be short-lived and MUST carry an explicit expiry.
• Static API keys are named as an antipattern - In the draft’s own words, bearer artifacts that are “not cryptographically bound, do not convey identity, are typically long-lived and are operationally difficult to rotate.” That is one sentence, and it invalidates how most of the API economy currently lets agents in.
• Attestation is identity proofing for machines - TEE evidence, software integrity measurements, supply-chain provenance, orchestration-layer attestation. What gets attested determines whether a credential is issued at all, which type, and what it contains.
• Two places to authenticate - Transport layer via mTLS, or application layer via WIMSE Proof Tokens (a signed JWT carrying aud, exp, jti and wth — a hash of the associated WIT — bound to HTTP through a Workload-Proof-Token header) or HTTP Message Signatures. The application layer exists because proxies and load balancers break transport identity continuity.
• Delegation is OAuth, all the way down - OAuth 2.0 access tokens for the user delegation case, Token Exchange for reaching legacy environments, Transaction Tokens to attenuate a long-lived grant into a single call, OAuth Identity and Authorization Chaining across domains, and CIBA when the authorization server decides a human has to approve.
• Local confirmation is not authorization - An MCP-style “approve this tool call?” prompt does not constitute an authorization decision. The agent MUST translate that confirmation into a real OAuth authorization event before touching the protected resource.
• Discovery instead of static config - Agents SHOULD learn their world at runtime: OAuth 2.0 Authorization Server Metadata and OpenID Connect Discovery for the AS, OAuth 2.0 Protected Resource Metadata (RFC 9728) for how a tool is protected and which AS protects it, and Client ID Metadata Documents or Dynamic Client Registration so a client can be known without bilateral pre-registration.
• Observability is a security control - Audit records MUST be tamper-evident and MUST capture the authenticated agent identifier, the delegated subject, the resource, the decision, a correlation ID, and the attestation or risk state behind it. Participants MAY subscribe to OpenID Shared Signals (CAEP or RISC) and MUST stop using cached tokens once revocation arrives.

The reason this belongs in the catalog is what it implies for API providers rather than for agent builders. Almost every scored provider in the network authenticates agents the same way it authenticates a curl command from 2014: a long-lived key in a header. This draft is the first document with real IETF weight to call that unsuitable, and it does it without asking anyone to adopt something new — every piece it names already has an RFC or a working-group draft behind it. The composition, though, is genuinely hard to prove from outside. A framework document defines no well-known path and no header of its own, so there is nothing to probe for at a provider’s domain the way there is for /.well-known/ai-catalog.json. What is observable is the constituent parts — whether the provider serves RFC 9728 protected resource metadata, whether it supports dynamic client registration, whether its OpenAPI declares mTLS or signature-based schemes rather than only apiKey, and whether it can issue a token scoped to a delegating user rather than to an integration account. Those are the checks worth tracking, and they are worth tracking now precisely because so few providers pass any of them.

The draft expires 3 September 2026 and has not been adopted by a working group, so treat it as a reading of where WIMSE and OAuth are heading rather than as something to conform to. The parts it composes are the stable bet.