IETF · 7 February 2026 (draft-01 expired 11 August 2026)

Agent Authorization Profile (AAP) for OAuth 2.0

draft-aap-oauth-profile-01

A. Cruz

Individual draftDraft — expect changeAuthorizationAgent-specificField guide

Another 'profile OAuth' proposal. Compare carefully with draft-mishra-oauth-agent-grants before implementing either.

At a glance

Problem: AS/RS need structured, auditable claims about agent identity, task context, constraints, delegation chains, and human oversight — without a new protocol.
Identity / authn / authz: Authorization profile on OAuth/JWT. Client is the agent; often client-credentials for M2M, plus extra claims.

Actors

Agent (OAuth client)
Authorization server
Resource server

The gap for agents

AS/RS need structured, auditable claims about agent identity, task context, constraints, delegation chains, and human oversight — without a new protocol. Another 'profile OAuth' proposal. Compare carefully with draft-mishra-oauth-agent-grants before implementing either.

Not the same document as draft-fane-opena2a-aap (OpenA2A Agent Authorization Protocol). The acronym collision is real; always cite the draft name.

Actors and trust boundaries

Agent is the OAuth client; often client-credentials for M2M, plus extra claims the RS must evaluate. May integrate SPIFFE SVIDs as client auth. The RS that ignores AAP claims has unconstrained agents with extra JSON.

Mechanics

draft-aap-oauth-profile-01, 7 February 2026, expires 11 August 2026 — as of the 15 September 2026 research date this revision appears expired without a visible -02 on datatracker. Author A. Cruz. Standard OAuth issuance; RS must evaluate AAP claims before performing operations. Claim names are defined in the draft — verify against the text, do not invent from memory.

AAP structured claimsillustrative: Task/context/oversight fields defined by the profile. Quoted only by reference: read the draft for names; do not copy unofficial blogs.

Step-by-step flows

Flow 1

Issue an AAP-profiled token

1
Agent authenticates as an OAuth client (secret, key, or SPIFFE).
2
AS issues a JWT that includes the AAP claim set for this task.
3
RS validates OAuth/JWT baseline then AAP constraints (task, oversight, chain) before the operation.

Identity vs authentication vs authorization

Authorization profile on OAuth/JWT. Client is the agent. Identity of the user is whatever OAuth already put in sub, if anything.

How it composes

OAuth 2.0
Base protocol.
Token Exchange
Delegation chains.
SPIFFE / SPIRE
Optional client auth.
AIMS (agent auth BCP)
AIMS would rather you compose RFCs than add a parallel claim dialect — compare.
OAuth agent grants
The other OAuth profile; this one adds claims, that one refuses to.

What bites agent implementers

Expired individual draft
draft-01 expired 11 August 2026. Confirm datatracker before implementing. Do not treat as a living standard.
AAP acronym collision
OpenA2A AAP is a different document. Cite draft-aap-oauth-profile.

Stability — what you can ship

Individual draft-01, 7 February 2026, expired 11 August 2026 unless renewed. https://datatracker.ietf.org/doc/draft-aap-oauth-profile/. Do not ship as a dependency without a current revision.

Catalog claims (short form)

AAP structured claims: Task/context/oversight fields defined by the profile — verify against the draft, do not invent names from memory.

Implementer notes

Not the same document as draft-fane-opena2a-aap (OpenA2A Agent Authorization Protocol), which is a brokered capability-grant protocol. The acronym collision is real; always cite the draft name. Draft-01 expired 11 August 2026 — confirm datatracker for a renewal before implementing.

Relationship to others

Primary sources

Datatrackerhttps://datatracker.ietf.org/doc/draft-aap-oauth-profile/