Summary

  • RFC 9767 makes active a contextual conjunction: issuer, revocation, time, proof, audience and requested access must all fit the resource server named in the introspection call.
  • The authorization server supplies a bounded validation result. The resource server separately validates the current presentation, applies local policy and chooses the actual response.
  • A defensible operational record therefore needs four receipts: introspection, per-request proof, local decision and observed effect. Cache age and downstream token derivation must remain visible between them.

The seductive boolean

A client arrives at a resource server with an access token. The resource server asks an authorization server whether it is active. The answer is true. It is tempting to compress the whole exchange into one sentence: the authorization server approved the request.

That sentence is wrong in exactly the way distributed systems make expensive. It erases the question the authorization server actually answered. It erases which resource server asked, which proof method accompanied the token, whether minimum access was supplied, how fresh the answer was and what the resource server did next.

RFC 9767, Grant Negotiation and Authorization Protocol Resource Server Connections, exists because the core GNAP protocol keeps the authorization server and resource server as distinct roles. They may share a deployment, but they need not. An authorization server can protect many resource servers; a resource server can receive a token it cannot interpret by itself. The extension gives those parties a common language without merging their authority.

That architectural modesty is the Article’s central fact. The AS describes a token in a supplied context. The RS decides how its own resource responds. Evidence crosses the interface. Operational responsibility does not disappear into it.

Who asks the question

The introspection call is not made in the client’s voice. The client presents a token to the RS. The RS then signs its own request to the AS using the RS’s key. The body includes the presented token value, normally the proof method used by the client, the identity of the resource server and, optionally, the minimum access needed for the pending request.

Those inputs prevent active from becoming a universal property painted onto a token. A token can be active for one RS and unsuitable for another. It can be active for a read operation and insufficient for a write. It can be issued and unexpired while the indicated proof method is wrong. The AS must consider every parameter supplied. If it cannot understand part of the requested context, it must not declare the token active.

The RS identity has its own trust boundary. RFC 9767 requires signed RS-facing calls but leaves key enrolment outside scope. An AS might preregister an RS, accept a key by another process or use a trust-on-first-use arrangement. A valid request signature therefore proves possession under the chosen enrolment model; it does not, by itself, prove that the model assigned the right resources or that the RS will act properly.

That is why an operational trace should record more than the boolean. It should record the AS endpoint, RS identity and key reference, request signature verification, token identifier or protected digest, proof method, minimum access, request time and response time. Without that context, active is an orphaned conclusion.

What active actually joins

RFC 9767 defines active as a conjunction. The token must have been issued by the AS processing the call. It must not be revoked or expired. It must be bound through the proof method indicated in the request. It must be appropriate for presentation at the identified RS. If the RS supplied an access requirement, the token must also be appropriate for it.

The conjunction matters more than the friendly green word. It turns the response into a compact verdict over several predicates. An audit cannot safely infer which predicate was decisive from false; the specification also uses false when the AS cannot make a determination, including when it does not find the token. False is fail-closed output, not a standardized diagnosis of revocation.

True is equally bounded. It does not say that the request body was harmless, that the subject intended this action, that a fraud screen passed, that a quota remained, that the resource existed or that the service later completed. It says the token survived the checks represented in this call.

The response can return access rights, key information, flags and time or identity claims. Yet even an active response is deliberately selective. Access can be filtered for the particular RS and may be an empty array. The token value itself must not be returned. The interface aims to give the RS what it needs without turning every RS into an observer of the entire authorization domain.

This is a thin coordination layer in Heng Lu’s sense. Common syntax makes a result portable between roles. It should not be inflated into a standing authority over the local decision that follows.

The resource server’s decision

RFC 9767 is unusually explicit about the last step. After processing introspection, the RS must determine the appropriate course of action. If rights are insufficient, it might return an error or a public resource. The final response remains at the RS’s discretion.

That discretion is not a loophole in authorization. It is the location of application authority. The AS knows the grant and token state. The RS knows the endpoint, method, object state, local obligations, safety controls and response alternatives. Only the RS can turn the abstract right into a concrete operation on the resource it serves.

Local discretion is therefore accountable, not arbitrary. A useful decision record says which resource and action were requested, which returned rights were considered, which local rule evaluated them, which other conditions applied, which software and policy versions ran, and what response was selected. If the RS returns public data rather than an error, that distinction must not be rewritten later as “authorization succeeded.”

Nor should an AS receipt be allowed to close an incident. A later 200 response might contain an application error. A successful write might fail to commit in a downstream store. A response can be generated and lost before the client receives it. The token verdict, RS action and observed effect occupy different failure domains.

Token validation is not proof validation

Key binding narrows who can present a token, but it creates another separation that dashboards often flatten. The RS must validate the token and the proof for the current request. Proof of possession alone is insufficient: a compromised key or confused deputy might generate a cryptographically correct request outside the token’s rights.

The inverse also fails. A token that the AS describes as active does not prove that this HTTP message carries the required client proof. RFC 9767 says proof validation should be performed independently for each request because method, target and message content can vary. A proof result from one message must not be cached and applied to another.

This is where related standards help mark the boundary. JWT defines a compact claim format, not an application decision. HTTP Message Signatures defines how components can be covered, not whether the signer is entitled to the operation. DPoP and mutual-TLS profiles constrain token presentation in their own ecosystems, but they do not erase resource-server policy. The implementation must join the right token, key, method, target and message at the moment of use.

A clean record therefore gives the introspection response and current proof separate identifiers. If a team stores only “token active,” it cannot later show whether the request signature covered the correct target, whether the nonce or freshness rule passed, or whether another request reused a valid-looking artifact.

The cache is a local time machine

Introspection costs latency and availability. A resource server can cache validation results, avoiding repeated network calls or cryptographic work. RFC 9767 states the bargain plainly: the cache improves performance while reducing the liveness and accuracy of the information. A revoked token can remain accepted while an earlier positive result is still in use.

That makes cache lifetime a decision about delegated authority. A ten-minute positive cache means the RS is willing, under its own policy, to substitute a past AS fact for a live one for up to ten minutes. The AS did not silently make that choice merely because it once returned true.

Expiry is only one bound. A cache key must retain the context that shaped the answer: token, RS, proof method and requested access where used. Collapsing two introspection questions onto one token-only cache entry can convert a narrow answer into a broad one. Negative caching also needs care because false combines revocation, expiry, mismatch and indeterminacy.

The RFC notes that proactive revocation signalling is possible but outside its scope. OAuth token revocation and ACE revocation-notification work describe adjacent mechanisms, but a deployment still has to prove that a signal reached the right cache and changed later decisions. A revocation request is not a resource-server invalidation receipt.

Record the cache hit, original response time, age, configured limit, expiry bound, invalidation source and reason for bypass. Otherwise a later reviewer cannot tell whether the RS acted on a live AS judgment or its own earlier snapshot.

Disclosure is also a control surface

Introspection improves least disclosure when the AS filters claims for a particular RS. It can also create surveillance. Each call tells the AS that a specific token is being used at a specific resource server at a particular time. If an AS protects sensitive services, those observations may reveal patterns even when the content stays encrypted.

Structured tokens present a different trade-off. They can be validated locally and reduce live call visibility, but they may reveal claims to every RS that can parse them. RFC 9767 permits structured, opaque and combined models. There is no universal privacy winner; the accountable choice names who learns what, when and for how long.

Key material changes the trust map too. An introspection response for an asymmetric proof can expose a public key. A symmetric proof requires the RS to know the shared secret, which can let it construct a fresh request with the token. The label “key-bound” therefore hides two materially different compromise surfaces.

Resource references deserve the same restraint. An RS can register a resource set and receive an opaque handle. The client can use that handle in a later access request, but neither client nor RS should parse hidden structure from it. Random or encrypted references reduce leakage and discourage applications from depending on accidental encoding. A handle coordinates; it does not define rights independently of the AS’s stored meaning.

A downstream token starts another accountability leg

RFC 9767 also covers a common service chain. RS1 receives the client’s token but needs to call RS2. RS1 cannot pretend to be the original client or modify that client’s grant. Instead it can ask the AS for a derived token, present the existing token as context, identify itself as the new client with its own key and sign the request.

The AS must first determine that the incoming token is appropriate for RS1. It may then issue a new token for RS2. That token can be bound to RS1 and limited to the rights RS1 needs. RS2 can repeat the pattern for another hop.

Derivation is safer than passing a bearer token through the chain, but it is not end-to-end proof. The new token says something about the delegated context at the next leg. It does not prove that RS1’s input was correct, that RS2 performed the requested operation, or that RS1 returned a truthful result to the original client.

OAuth token exchange offers a useful adjacent comparison: exchanging or impersonating artifacts creates new subject, actor and audience questions. Whatever protocol carries the token, each hop needs a custody record: incoming request, derived-token request, issuance result, downstream presentation, local decision and observed effect. A chain of valid tokens is not yet a chain of completed work.

The four-receipt test

An operations team can prevent most authority drift by refusing a single all-purpose “authorized” event. Preserve four receipts.

The first is introspection: exact question, signed RS identity, token reference, proof method, requested access, AS answer, returned claims, time and cache policy. The second is presentation proof: the current message components covered, key and algorithm, freshness inputs and validation result. The third is the RS decision: resource, operation, local policy version, other controls and chosen response. The fourth is effect: commit identifier, downstream acknowledgments, response delivery evidence and later reversal where applicable.

Tests should break each join. Present an active token to the wrong RS. Ask for access outside its rights. Supply an unknown access element. Replay a proof on another request. Age a cached positive beyond a revocation. Return an empty filtered access array. Lose the downstream response after a successful operation. Compromise RS1 and attempt to reuse an incoming bearer token at RS2.

The pass condition is not a permanent green light. It is that every component fails within its own authority, records uncertainty and never invents the next receipt.

Sources