Summary
- RFC 9635 gives a client a key-bound continuation access token to continue one GNAP grant request, not to call a protected resource.
- While that request is pending, no API token may be granted and no subject information may be released. Even after interaction, the authorization server must re-evaluate the request before issuing anything useful to a resource server.
“The user finished the approval screen” is often treated as a final system state. It is not. It can mean that a browser returned to a client, that a client has received a continuation URI, or that a signature proves possession of a key. Each is meaningful. None is the same fact as “this client may now perform the requested API action.”
RFC 9635, the Grant Negotiation and Authorization Protocol, is clear about the separation. A client begins a grant request at an authorization server. If approval or interaction is still needed, the request is pending. In that state, the server may return continuation information, but it may not grant API access tokens or release subject information. The grant is still a conversation about access, not access itself.
The credential in that response has a deliberately narrow job. RFC 9635 calls it a continuation access token. It must be bound to the client's key, must not be a bearer token, and must be presented with key proof to the continuation URI. The authorization server validates the proof and uses it to identify the ongoing request. That is a solid control against a stray caller taking over a grant conversation. It is not an API permission in another costume.
The specification makes the boundary hard, not rhetorical. An ordinary access token must not work at a continuation endpoint. Conversely, a continuation access token must not be usable for an authorised request to a resource server, even where the resource server and authorization server sit in the same deployment. One opaque string may look like another in a log, but the verifier, URI, state machine and permitted effect are different.
Interaction completion does not erase that difference. After interaction, the authorization server moves the request back to processing and re-evaluates the full context. That happens whether the resource owner approved or denied the interaction. Only an approved request can return API access tokens or subject information. A finalized request is stricter still: it cannot issue new tokens, return subject information or restart interaction. Future access needs a new grant request.
Token management is a third surface that teams often merge into the same green status. An API access-token response can include a distinct management URI and a management credential used to rotate or revoke that token. Rotation preserves the original token's rights; it is not a request to broaden them. Different rights require a continuation update and fresh evaluation, or an entirely new grant. Management continuity is not permission expansion.
The same restraint appears at the resource boundary. A GNAP API token lets the client present an authorization credential to an API under the token's prescribed proofing rules. A resource server can challenge a missing or invalid token. That still tells us nothing about the commercial or operational meaning of the requested call, whether its prerequisites are current, or whether its effect occurred. The protocol tells each verifier what credential belongs on its surface. It does not merge the verifiers into one owner of every later decision.
For operators, the useful evidence chain is therefore longer than a success callback: grant-request identifier and requested access; pending state; continuation URI and bound-key proof; interaction result; authorization-server re-evaluation; issued API-token scope; resource-server validation; request receipt; and separately observed outcome. Preserve those records as different facts. It is the difference between a system that can explain why it let a conversation proceed and a system that accidentally treats progress in the conversation as an executed right.
Sources
- RFC 9635 — Grant Negotiation and Authorization Protocol
- RFC 9635 publication record
- IETF Datatracker — RFC 9635
- RFC 9396 — OAuth 2.0 Rich Authorization Requests
- RFC 8707 — Resource Indicators for OAuth 2.0
- RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession
- RFC 9470 — OAuth 2.0 Step Up Authentication Challenge Protocol
- Heng Lu — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption
- Heng Lu — Running-Code Primacy
- Heng Lu — Reality Layers, Symbolic Power and Clarity
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance