Skip to content
Agent Identity

IETF · 30 August 2026

OAuth profile for agent grants (identifying agent clients)

draft-mishra-oauth-agent-grants-02

S. Kumar (Orchestrum Technologies LLP)

Individual draftDraft — expect changeAuthorizationAgent-specificField guide

If your constraint is 'we will not deploy a new protocol, only profile OAuth', this is the checklist.

At a glance

Problem
AI agents invoking APIs on behalf of users need a profile: identify the agent instance, get consent, issue resource-bound sender-constrained tokens, attenuate via token exchange, rotate refresh tokens — without new JWT claims or endpoints.
Identity / authn / authz
Mostly authorization, using existing OAuth identity of the user plus client identity of the agent.

Actors

  • Agent client instance
  • User
  • Authorization server
  • Resource server

01

The gap for agents

AI agents invoking APIs on behalf of users need a profile: identify the agent instance, get consent, issue resource-bound sender-constrained tokens, attenuate via token exchange, rotate refresh tokens — without new JWT claims or endpoints. If your constraint is 'we will not deploy a new protocol, only profile OAuth', this is the checklist.

Positions itself as a profile, not a rival to AAuth. Cross-domain hops should use identity chaining rather than private formats.

02

Actors and trust boundaries

Agent is an OAuth client instance. User is the resource owner. AS and RS are standard. No new parties. Grantex is an incomplete reference implementation and is not required for conformance.

03

Mechanics

draft-mishra-oauth-agent-grants-02, 30 August 2026 (catalog previously said only '2026'), expires 3 March 2027, author S. Kumar (Orchestrum Technologies LLP) despite the 'mishra' filename. PAR + PKCE + resource indicators + JWT access tokens + PoP + RFC 8693 attenuation with act. No new endpoints, no new JWT claims.

actfrom spec
Quoted reuse of RFC 8693: delegation chain when the agent is a distinct actor. This profile defines no new claims.

04

Step-by-step flows

Flow 1

OAuth-only agent grant

  1. 1

    Identify the agent client instance (pre-register, CIMD, or DCR).

  2. 2

    PAR + PKCE + resource=API. User consents.

  3. 3

    AS issues audience-restricted, sender-constrained at+jwt (DPoP or mTLS).

  4. 4

    Downstream hops: token exchange with nested act, attenuated scope. Never expand.

05

Identity vs authentication vs authorization

Mostly authorization, using existing OAuth identity of the user plus client identity of the agent. Not a new identity system.

06

How it composes

07

What bites agent implementers

  • Thinking Grantex is the spec

    The draft says the reference implementation is non-normative and incomplete.

  • Adding claims anyway

    The point of this draft is not to mint aap_* fields. If you need structured agent claims, look at AAP — and compare carefully.

08

Stability — what you can ship

Individual informational draft-02, 30 August 2026. https://datatracker.ietf.org/doc/html/draft-mishra-oauth-agent-grants-02 Pin it. Not a WG item.

Catalog claims (short form)

act
Delegation chain when the agent is a distinct actor.

Implementer notes

Individual draft. Positions itself as a profile, not a rival protocol to AAuth. Cross-domain hops should use identity chaining rather than private formats. Reference implementation 'Grantex' is explicitly non-normative.

Relationship to others

Primary sources

  • HTML of draft-02https://datatracker.ietf.org/doc/html/draft-mishra-oauth-agent-grants-02