GNAP is trying to standardize delegated authorization as a negotiation process between a specific client instance, an authorization server, one or more resource servers, and a resource owner/end user pair. That framing is broader than a one-shot token issuance pattern.
The core RFC is explicit that GNAP is not an OAuth 2.0 extension and is not meant to be directly compatible with OAuth 2.0. The design is intentionally trying to expose cleaner protocol surfaces for cases OAuth historically bundled together.
One of the most useful analytical splits is the role model itself: client instance, authorization server, resource server, resource owner, and end user are treated as distinct actors with separate trust relationships.
GNAP repeatedly treats authorization as something that can continue and evolve. The table of contents and introductory sections emphasize continuation, pending interaction polling, request modification, revocation, token rotation, and asynchronous authorization rather than only redirect completion.
The request-security layer is a first-class part of the protocol. The core RFC includes proof-of-possession and request-signing paths via HTTP Message Signatures, mutual TLS, detached JWS, and attached JWS, which makes key custody and binding policy part of the trust model.
RFC 9767 is especially valuable because it makes the authorization-server/resource-server boundary explicit. It adds RS-facing discovery, token introspection, resource-set registration, and downstream-token derivation for loosely coupled deployments.
Open Payments is a strong downstream example because its docs explicitly say it uses GNAP for grants and request signatures while keeping payment execution and settlement outside the protocol. That makes GNAP a useful lower layer beneath machine-commerce and payment-initiation systems, not just a generic identity RFC.
Specific source signals worth retaining
RFC 9635 Introduction: GNAP lets a client instance request delegated authorization to resource servers and subject information, and treats the process as a grant that can be negotiated over time.
RFC 9635 Introduction / Appendix framing: GNAP solves many of the same use cases as OAuth 2.0 and OpenID Connect but is not an OAuth extension.
RFC 9635 role definitions: the distinction between end user and resource owner is kept explicit, which matters for enterprise, delegated, and multi-party flows.
RFC 9635 request-security sections: request binding and proof-of-possession are protocol-native, not purely deployment-specific afterthoughts.
RFC 9767 Introduction: loosely coupled AS/RS deployments need interoperable APIs for token validity, access-right understanding, and downstream token handling.
Open Payments docs: GNAP appears in practice as the grant layer beneath wallet-address discovery and payment instruction APIs, which helps anchor why this RFC belongs in a crypto-adjacent corpus at all.
Why this entry belongs in the corpus
It gives the payments and machine-commerce cluster a lower-layer authorization baseline beneath Open Payments, x402-style paid APIs, and wallet-auth/payment-initiation systems.
It helps separate client-instance identity, grant negotiation, request signing, token presentation, RS/AS coupling, and subject-information return instead of flattening them into one generic API auth or generic payments story.
The durable insight is that many crypto-adjacent payment and wallet protocols inherit most of their real control surface from the authorization substrate below them. GNAP makes that substrate unusually legible.