Summary

  • RFC 9701 lets an authenticated resource server receive a signed, and optionally encrypted, JWT token-introspection response with explicit issuer, audience, creation time and a nested token-state object. That response is evidence supplied to access control, not an access token or a completed authorization.
  • A defensible decision binds caller authentication, response classification, signature and optional decryption, envelope audience and freshness, nested token audience and scope, privacy policy, replay controls, local rule and the operation actually enforced.

The cryptographic verifier returns success. The JWT came from the expected authorization server, its signature is valid, and its nested object says active:true. An implementation that treats those three facts as the access decision has already crossed the boundary RFC 9701 works to preserve.

The document extends OAuth token introspection. The base protocol lets a protected resource ask an authorization server about an access token and receive a JSON object. RFC 9701 adds a cryptographically secured JWT form for cases in which the resource server needs stronger assurance about who issued the answer. Its motivating example includes verified personal data used in certificate creation, where attribution and potential liability make a plain transport response insufficient.

That is a valuable upgrade. A signature binds an assertion to an issuer and exact bytes. Optional encryption limits who can read it. Neither mechanism grants the requested operation. The authorization server provides facts and policy-filtered claims; the resource server still owns the decision and its consequences.

The caller must be known before the token is described

The first control appears before the response format. RFC 9701 requires the authorization server to identify, authenticate and authorize the resource server calling the introspection endpoint. The caller may use a client-authentication method or a separate access token that identifies the resource server, but an anonymous request must not receive the protected token data.

This is stricter than merely placing the endpoint behind TLS. A successful TLS channel identifies a transport peer according to its configuration; the introspection service must still map the caller to a resource-server identity, determine whether that server is an audience for the access token, and decide which fields it may receive. If the token is invalid, expired, revoked or not intended for that caller, the nested answer must be active:false and must omit all other introspection members.

The negative shape matters. It prevents the error response from becoming an oracle that reveals a subject, client, scopes or expiry to an unauthorized server. Conversely, active:true is not a universal fact about the token. It is the authorization server's answer for this resource server under the token and configuration it evaluated at that moment.

RFC 9701 says the returned scope should be narrowed to what is relevant to the caller. Identity and other privacy-sensitive claims follow resource-server-specific policy and a legal basis. The same access token can therefore yield different legitimate response shapes to two authenticated resource servers. A field absent from one answer is not proof that the authorization server lacks it; a field present in another is not permission to redistribute it.

One JWT contains two time and authority layers

The resource server asks for the format with Accept: application/token-introspection+jwt. The response carries that media type, and the JWT header uses typ: token-introspection+jwt. At the top level, the response must contain iss, aud, iat and a token_introspection object.

The division is deliberate. Top-level iss identifies the authorization server that created the answer. Top-level aud identifies the resource server meant to consume it. Top-level iat records when the answer was created. Inside token_introspection, claims such as sub, scope, exp, aud or iat describe the introspected access token.

The same word can therefore answer two different questions. Envelope aud says who may consume this response; nested token aud says where the underlying token is intended to be used. Envelope iat dates the statement; nested token timestamps describe the token. A parser that flattens both objects can apply the correct number to the wrong authority.

That is why RFC 9701 recommends omitting top-level sub and exp. The response JWT is not a different encoding of the access token. It must not be presented to the resource server's own access-token gate as though the authorization server had minted another bearer credential.

The IANA media-type record, JWT claims registry and OAuth parameters registry give implementations shared names. Registration prevents vocabulary collisions. It cannot prove that running software kept the two claim layers separate.

Cryptographic success is a typed receipt

RFC 9701 permits a signed response or a response that is signed and then encrypted as a Nested JWT. Signing is the issuer receipt. Encryption is a recipient-confidentiality control. Their order preserves the authorization server's signed statement inside an envelope readable by the intended resource server.

Configuration is another evidence surface. Dynamic registration under RFC 7591 can treat each resource server as a client and record its authentication and key material. RFC 9701 adds metadata for the introspection-response signing algorithm, key-encryption algorithm and content-encryption algorithm. An authorization server can publish supported choices using RFC 8414; the resource server can register encryption keys through jwks_uri or jwks.

The formats come from JWS, JWE and JWT. Those standards explain how to verify, encrypt and nest the object. They do not choose a deployment's trusted issuers, acceptable algorithms, key-rotation window, response-age limit or failure policy.

An algorithm in metadata is capability, not execution. A kid is a lookup hint, not proof that the selected key was trusted at the decision time. A valid signature says the signed bytes were produced under a corresponding key and remain intact. The verifier still needs an issuer-bound key set, algorithm policy, audience comparison, time policy and response-type check. The audit record must identify all of them.

Cross-JWT confusion turns similarity into authority

The introspection JWT and a JWT access token can both contain iss and aud. An attacker can exploit a resource server that accepts any correctly signed JWT and pass the response object where an access token is expected. RFC 9701 counters this with the dedicated typ value, nesting of introspection members and the absence of top-level token-like claims.

This is an application of the explicit typing discipline in JWT Best Current Practices: formats that are syntactically similar must be mutually exclusive at validation time. The resource server must check the type of JWT access tokens and require every claim needed for that access-token profile. “Signature valid” is not a classifier.

The distinction also survives encryption. Successfully decrypting a Nested JWT proves possession of the recipient key and reveals the inner signed object. It does not license the application to reinterpret the inner type. Confidential delivery and semantic admission are different checks.

Nor does RFC 9701 solve replay of the underlying access token. It points to RFC 9700 for replay countermeasures. Sender constraints, proof verification, audience restriction and request binding remain distinct from an introspection-response signature. A resource server can possess a perfectly authentic statement about a token and still accept the token in a context where the presenter has no right to use it.

active:true has a clock and a destination

The response's iat makes staleness visible but does not supply a universal cache lifetime. Between the authorization server creating the JWT and the resource server executing an operation, the access token may expire, be revoked, lose scope or be displaced by a local risk decision. The resource server needs an explicit response-age policy and a rule for operations whose risk exceeds the freshness of the evidence.

The signed statement can be retained for accountability: it records what the authorization server said. Retention does not preserve its operational authority. A five-minute-old active:true can remain a valid historical signature while being too old to authorize a current transfer. Cryptographic validity and decision validity age differently.

The last authority is local. The nested scope may include write, but the requested object may be locked; the account may be suspended locally; transaction value may require step-up approval; the subject may lack the relevant role; a sender-constrained token may fail its proof; or the operation may violate a jurisdictional restriction. The resource server combines the introspection facts with those rules and emits its own allow or deny receipt.

Only then can an execution record show whether the change happened. An allow decision followed by a database timeout is not an outcome. A successful write later rolled back is not the same state as a durable write. The chain needs the operation identifier, policy version, side effect and any compensation.

Privacy is part of the authorization path

Token introspection can carry personal data. RFC 9701 requires a legal basis before release and requires the authorization server to enforce the scope of that basis throughout the process. First-party ownership does not remove the duty to enforce the service's terms and policy.

Optional encryption protects claim contents from parties that cannot decrypt the response. It does not make an excessive disclosure lawful, select the correct recipient, minimize fields or constrain what the resource server does after decryption. Those are authorization and governance controls.

The act of introspection also creates telemetry. It tells the authorization server when the client, and potentially the user, is accessing a resource server. If that observation is unacceptable, RFC 9701 says another means of conveying token data must be used. Choosing introspection is therefore a privacy architecture decision, not merely an encoding preference.

TLS deployment guidance protects the transport. It does not erase the authorization server's observation, nor does it replace message-level attribution where a signed answer must survive beyond the connection.

The useful control is a linked decision receipt

For every material operation, preserve the access-token fingerprint or protected identifier; the resource-server identity and authentication method; the exact endpoint and TLS result; request and response hashes; media type and typ; issuer-bound key and algorithm; signature and optional decryption results; envelope iss, aud and iat; nested active, token audience, expiry and narrowed scope; identity fields disclosed and their policy basis; replay or sender-constraint checks; local policy version; allow or deny; and the executed side effect.

These are not twelve copies of one fact. Each closes a separate failure mode. Together they let an investigator answer whether the wrong server obtained data, the right server accepted the wrong JWT class, a stale answer was reused, a broad scope escaped narrowing, personal data exceeded its basis, a replay check was skipped, or enforcement diverged from the decision.

Lu Heng's minimum-initial-specification doctrine fits this architecture. The shared protocol standardizes only what must interoperate: how a resource server asks for the JWT, how the response is typed, which envelope claims are required, where introspection members live and how algorithm capabilities are described. Local systems retain issuer trust, age limits, privacy rules, authorization and enforcement.

Reality-layer discipline keeps the IANA record, parsed JWT, verified signature, intended audience, reported token state, local decision and external effect from borrowing one another's authority. Running-code primacy then makes a concrete verifier and enforcement trace stronger evidence than a metadata page or a vendor statement that the feature is supported.

RFC 9701 does not weaken the authorization server by limiting its claim. It makes the claim more useful: attributable, typed and bounded. The resource server remains responsible for what happens next.

Sources