IETF · October 2024
Grant Negotiation and Authorization Protocol
RFC 9635
J. Richer (ed.), F. Imbault
Grant Negotiation and Authorization Protocol (RFC 9635) is RFC, October 2024. If you are designing greenfield agent auth and can choose a protocol, GNAP is the completed IETF alternative to OAuth. In practice, MCP and most SaaS APIs chose OAuth 2.1, so GNAP is currently adjacent rather than the default.
At a glance
- Problem
- OAuth 2.0's fixed grants, bearer tokens, and redirect-centric interaction cannot cleanly express some delegation and key-bound client cases. GNAP is a different protocol (not an OAuth extension) for negotiating grants, including fine-grained access and identity assertions.
- Identity / authn / authz
- Authorization protocol that can also carry identity assertions. Intentionally not compatible with OAuth 2.0.
Actors
- Client instance
- Authorization server
- Resource owner
- Resource server
When this matters for agents
When this matters for agents: greenfield authorization with key-bound clients and negotiated grants. GNAP is a completed IETF alternative to OAuth (RFC 9635), not wire-compatible. In practice MCP and most SaaS APIs chose OAuth 2.1, so GNAP is adjacent rather than the default. AAuth occupies some of the same 'key-bound HTTP client' space with JWT vocabulary.
Flow in plain language
Client POSTs a grant request including its key and requested access. AS returns a grant response that may include access tokens, interaction instructions, or continuation. Tokens are typically key-bound. Interaction can be redirect, user-code, or other modes.
Key tokens and claims
- GNAP access token
- Often presented with proof of the client key, not as a naked bearer secret.
Implementer notes
Proposed Standard. The GNAP WG has concluded. Parallel existence with OAuth is expected. AAuth occupies some of the same 'key-bound HTTP client' design space but stays closer to HTTP signatures + JWT vocabulary.
Related
Primary sources
- RFC 9635https://www.rfc-editor.org/rfc/rfc9635.html