GNAP

• Name: GNAP (Grant Negotiation and Authorization Protocol)
• URL: https://www.rfc-editor.org/rfc/rfc9635
• Category: grant-negotiation protocol / delegated API authorization standard / key-bound client-instance access-control infrastructure
• Summary: GNAP is best understood not as a generic OAuth replacement slogan or a payments product, but as a lower-layer protocol for negotiating delegated software access over time. Its core move is to separate client-instance identity, resource-owner consent, subject-information return, access-token issuance, request signing, and resource-server coordination into explicit protocol surfaces. That makes GNAP a useful comparison class for Open Payments, x402-adjacent machine-commerce APIs, wallet-auth systems, and OAuth-style delegation flows: the important question is not just who gets a token, but how a specific client instance identifies itself, how grants can evolve, how requests are cryptographically bound, and how loosely coupled authorization servers and resource servers stay interoperable.
• What it does:
  • Lets a client instance request delegated authorization to one or more resource servers and optionally request subject information in the same protocol family
  • Separates protocol roles explicitly into authorization server, resource server, client instance, resource owner, and end user instead of collapsing them into a flatter client/server login story
  • Supports multiple interaction patterns for authorization, including redirect-based interaction, user-code flows, asynchronous authorization, and software-only authorization
  • Lets grants continue over time through continuation, polling, modification, revocation, token rotation, and refreshed access rather than assuming one-shot issuance is the whole lifecycle
  • Binds client requests and access tokens to key material, with proof-of-possession options including HTTP Message Signatures, mutual TLS, detached JWS, and attached JWS
  • Extends beyond client-facing grant issuance with RS-facing discovery, token introspection, resource-set registration, and downstream-token derivation for loosely coupled authorization-server/resource-server deployments
• Key claims:
  • RFC 9635 is explicit that GNAP is not an extension of OAuth 2.0 and is not intended to be directly compatible with OAuth 2.0. That matters because GNAP is trying to expose a different control surface rather than merely polishing older OAuth ergonomics.
  • The core RFC defines GNAP as a mechanism for delegating authorization to software and conveying the artifacts of that delegation, including access to APIs and subject information. That makes it analytically broader than a simple bearer-token issuance flow.
  • The role split is one of the most reusable parts of the design. GNAP distinguishes the software instance, the software publisher, the end user, the resource owner, the authorization server, and the resource server more cleanly than many wallet-auth or API-key systems do.
  • The negotiation framing is important: the specification repeatedly treats authorization as a grant process that can continue, be modified, be revoked, or complete asynchronously instead of as a single redirect callback moment.
  • GNAP’s key-binding and request-signing model is also a core mechanism rather than an implementation detail. The spec gives multiple proof-of-possession methods, which makes client-key custody and request-integrity policy part of the trust model.
  • RFC 9767 adds an especially valuable lower layer for the corpus because it shows GNAP is not only about client-to-authorization-server interaction. It also defines how resource servers discover authorization servers, introspect or understand tokens, register resource sets, and derive downstream tokens in more loosely coupled deployments.
  • GNAP belongs in the corpus because it makes the lower-layer authorization machinery behind systems like Open Payments more legible. Without it, payment-initiation and machine-commerce projects risk being flattened into generic payments API stories when a large part of their real control surface sits in grant negotiation, client identity, token binding, and RS/AS coupling.
• Whitepaper: No standalone whitepaper surfaced in this pass. The canonical primary materials are the IETF standards RFC 9635 and RFC 9767, with supporting notes saved in ../../whitepapers/gnap-primary-sources-2026-05-13.md.
• Sources:
  • https://www.rfc-editor.org/rfc/rfc9635
  • https://www.rfc-editor.org/rfc/rfc9635.txt
  • https://www.rfc-editor.org/rfc/rfc9767
  • https://www.rfc-editor.org/rfc/rfc9767.txt
  • https://oauth.net/gnap/
  • https://openpayments.dev/overview/getting-started/

Internal linkages

• Keep this one lean.
• Best reads: open-payments, x402, and walletconnect-auth.

Control surface

• GNAP is where authorization gets made explicit instead of smuggled into login copy: client-instance identity, key binding, grant continuation, token shape, and RS/AS coordination are the real machinery.

• That also means the leverage is pretty plain. The party running the authorization server, defining signing requirements, and deciding continuation or introspection policy gets a lot of practical authority before any downstream payment or wallet action happens.

• Treat GNAP as delegated-access infrastructure, not as a payments rail or chain primitive. The settlement or execution system sits downstream in stacks like open-payments or beside it in request-auth systems like x402.

• Last reviewed: 2026-05-26 UTC