Phase 7: OAuth-for-Agents specification engagement

[hanwencheng]

Context

OAuth was designed for human + app authorization. Agent + agent + user + device is a different topology — there's no equivalent "user clicks Allow on a consent screen" when agent A delegates to agent B autonomously. The existing OAuth flows don't model:

• Agent-to-agent delegation with scope narrowing
• Capability-style time-bounded grants (vs. refresh-token semantics)
• Audit-chain forwarding through multi-hop agent chains
• Device + user + agent triangulation (who is the "client" when a device's agent acts?)

OAuth-for-Agents is the spec proposal that fills this gap. Per agent-iam-strategy.md §5 Phase 5: IETF or W3C working group engagement, AFTER deployed reference implementations exist.

Companion to #124 (MCP extensions). #124 standardizes the transport-layer headers; this issue standardizes the authorization model underneath.

Scope (M7 — long horizon, multi-year)

Charter proposal

• Identify the right working group (IETF OAuth WG, W3C Credentials Community Group, or a new dedicated working group)
• Draft a charter explaining the agent-authorization gap in current OAuth
• Submit charter via the working group's process; iterate based on feedback

Position paper

• "Why OAuth Doesn't Fit Agent-Agent Delegation"
• Cover:
  • Topology differences (human-app vs. agent-agent-user-device)
  • Time semantics differences (long-lived refresh tokens vs. short-lived capabilities)
  • Audit-chain requirements (cross-server attribution)
• Cite the AgentKeys delegation model (Phase 4: Active delegation chains (delegation.grant production) #121) as reference
• Publish as a workshop / conference paper

Reference implementation

Already shipped per Phase 4 (delegation chains #121). The proposal cites our deployed implementation.

Ecosystem signal

• AgentKeys' delegation model cited by 2+ third-party agentic platforms as the reference shape
• At least one major identity provider (Auth0, Okta, etc.) signals interest in extending their offerings to cover the agent-authorization case

Precondition (HARD)

Same as #124:

• Phase 1-6 (M1-M6) all shipped and stable in production
• 10+ vendor deployments live (not pilots)
• Multiple runtime adapter integrations in active use
• AgentKeys' delegation model has been live + deployed at scale for ≥ 12 months

Do not start until preconditions met.

Out of scope (forever)

• AgentKeys-specific branding in the spec
• Proprietary extensions
• Commercial licensing of the spec

Acceptance criteria

• Charter accepted by the working group (or rejected with feedback that informs an alternative path)
• Position paper published (workshop / conference / journal)
• AgentKeys' delegation model cited as reference in at least 1 working-group document
• Spec progresses to working-draft status

Risks

Risk	Mitigation
Working group rejects the charter	Have a backup plan: publish as a public spec under MIT, build adoption from below
OAuth working group is too entrenched in human-app paradigm to accept the change	Engage with the Credentials Community Group instead, or propose a new dedicated working group
Standards work consumes years without adoption	Budget fixed time (10% of one senior eng); don't burn the team on it; AgentKeys product continues regardless
Anthropic / OpenAI / others propose competing standards	Engage early; collaborate where possible; the deployed reference impl gives us credibility regardless of who "wins" the standard

References

• docs/spec/plans/milestones-roadmap.md §8 (M7 scope) + §9 (post-M7)
• docs/research/agent-iam-strategy.md §5 Phase 5, §6 Risk 5
• IETF OAuth WG
• W3C Credentials Community Group
• Phase 4: Active delegation chains (delegation.grant production) #121 (delegation chains — reference implementation)
• Phase 7: MCP protocol extensions proposal — IAM-grade auth headers #124 (MCP extensions — sibling standards work; transport layer)

Effort

N/A — multi-year standards work. Same shape as #124: 10% of one senior eng's time over ≥ 12 months.

Pickup notes for the next agent / human

• This is a standards engagement issue, not an engineering issue. Owner: senior eng + external standards advisor.
• Do not start until preconditions met. Re-check quarterly.
• Read agent-iam-strategy.md §6 Risk 5 for why premature standards engagement is risky
• The OAuth WG has historical patterns around "vendor-lobbying" proposals — be careful to frame as ecosystem benefit, not AgentKeys positioning
• Position paper is the LOW-COST step: get it published before charter; the paper itself raises adoption signal
• The Credentials Community Group at W3C is often a better starting point than IETF OAuth WG — less politics, more receptive to agent-era topologies
• Cite the deployed AgentKeys delegation model as proof-of-feasibility; don't propose anything that isn't already in production