Add support for resource-server constrained grant status queries for asynchronous delivery use cases

This is a specification question, not a code change, and the payload names no file, test or entry point. Read the Grant Management draft it references (#883) and the existing text on who may call the grant query operation. Done means a maintainer-agreed decision on whether a Resource Server may query grant status, which requires the working group rather than a newcomer patch.

Re-raising on GitHub. This was originally filed as Bitbucket issue openid/fapi#861 on 2026-07-07, during the migration freeze, and was not carried over by the import. Related to #883 (Grant Management draft status).

Summary

The Grant Management API is currently modelled primarily as a client-facing API: a client that has obtained or is associated with a grant can query, merge, replace, or revoke that grant.

There is an important asynchronous resource-server use case that does not appear to be directly covered: a Resource Server may need to determine whether an underlying grant is still active before continuing an asynchronous push, subscription, standing instruction, event delivery, or other out-of-band payload delivery to the client.

This issue proposes that the specification either:

1. explicitly clarifies whether Resource Servers are permitted to query grant state when authorised by the Authorization Server; or
2. defines/profiles a constrained, read-only grant-status query capability for Resource Servers.

Use case

A client obtains user authorisation and uses an access token to instruct a Resource Server to set up an asynchronous arrangement. Examples include:

• event notifications;
• webhook delivery;
• account or transaction data push;
• standing consent-based data delivery;
• long-running export jobs;
• payment or consent status callbacks;
• background fulfilment of a previously authorised resource action.

At setup time, the Resource Server has a valid access token and can verify that the client is authorised to create the arrangement.

Later, the Resource Server may need to push payloads or perform work without the client being in the request path. Before doing so, the Resource Server needs to know whether the underlying grant is still active and still covers the relevant resource, scope, or action.

Forcing the client to obtain a fresh access token using a refresh token can be awkward or impossible in this model, because the Resource Server is the party initiating the later action. The client may not know when the Resource Server is about to send the payload, and requiring a just-in-time client-initiated refresh changes the asynchronous architecture into a polling or callback coordination problem.

A concrete instance is a centralised authorization server serving many Data Providers (resource servers) in an ecosystem, where a Data Provider must confirm consent is still live before emitting a data-ready notification that itself contains personal data.

Problem

OAuth token validation and introspection answer the question: is this particular access token active and usable?

They do not necessarily answer: is the underlying user grant/consent still active, and does it still authorise this Resource Server to continue a previously established asynchronous arrangement?

The Grant Management API contains the right underlying concept, a durable grant object whose state can be queried, but the current language appears to constrain the API to the client that owns or is associated with the grant. That leaves ambiguity for Resource Servers that have a legitimate need to check grant state before continuing asynchronous delivery.

Proposed direction

The specification should clarify whether an Authorization Server MAY allow a Resource Server to query grant status, subject to strict policy controls.

This should not mean that Resource Servers can generally manage grants. The Resource Server should not receive merge, replace, or revoke capabilities unless separately authorised by an ecosystem profile.

The needed capability is narrower: a Resource Server can ask whether it may continue acting on a specific grant for a specific resource, scope, action, or asynchronous arrangement.

Possible model

The Resource Server would authenticate to the Authorization Server as its own confidential client or protected system actor.

The Authorization Server would issue a narrowly scoped access token for grant-status querying. This could be either:

• a profiled use of grant_management_query; or
• a separate scope such as grant_status_query.

The Resource Server would be allowed to query only grants where all of the following are true:

• the grant is associated with a resource or audience served by that Resource Server;
• the grant is associated with the client/subscription/action for which the Resource Server is responsible;
• the Resource Server is authorised by the Authorization Server or ecosystem trust framework to perform this check;
• the Resource Server receives only the grant information relevant to its own resource, not the full cross-resource grant state.

Example

A possible request could be:

GET /grants/{grant_id}
Authorization: Bearer <rs-grant-status-token>

Where the Authorization Server recognises the caller as a Resource Server and returns a filtered, read-only view.

Alternatively, the specification could define a separate grant-status introspection endpoint, for example:

POST /grant-status/introspect
Authorization: Bearer <rs-grant-status-token>
Content-Type: application/json

{
  "grant_id": "abc123",
  "client_id": "client-789",
  "resource": "https://rs.example.com",
  "subscription_id": "sub-456"
}

Example response:

{
  "active": true,
  "authorised": true,
  "client_id": "client-789",
  "resource": "https://rs.example.com",
  "effective_scopes": ["accounts.read", "events.push"],
  "expires_at": 1783400000
}

A negative response could indicate that the grant is revoked, expired, replaced, no longer covers the relevant scope, or is not visible to that Resource Server.

Security and privacy considerations

The Resource Server should not receive a full grant-management response unless it is authorised to see that information.

A Resource Server grant-status query should be:

• read-only by default;
• audience/resource constrained;
• scoped to the Resource Server's own resources;
• optionally bound to a subscription, consent, or asynchronous arrangement identifier;
• filtered so that unrelated resources, scopes, claims, and grant metadata are not disclosed;
• audit logged by the Authorization Server;
• denied where the Resource Server cannot prove a legitimate relationship to the grant.

This avoids leaking the client's broader consent or grant state to Resource Servers that do not need it.

Why refresh tokens are not enough

One workaround is to require the client to obtain a fresh access token using a refresh token, and then have the Resource Server rely on that access token before pushing data.

That works for synchronous or client-initiated access, but it is a poor fit for asynchronous delivery because the Resource Server is the party that later needs to decide whether to act.

Refresh tokens also prove that the client can obtain a new access token; they do not directly give the Resource Server a way to check whether a previously configured asynchronous arrangement remains valid at the moment the Resource Server needs to deliver.

Requested clarification

Please clarify one of the following:

1. Is the Grant Management API intentionally limited to the OAuth client that owns or is associated with the grant?
2. May an Authorization Server authorise a Resource Server to call the query operation for grants relevant to that Resource Server?
3. Should the specification define or recommend a constrained Resource Server grant-status query profile?
4. Should this be handled by Grant Management, token introspection, Rich Authorization Requests, Shared Signals, or a separate extension?

Suggested resolution

Add text clarifying that an Authorization Server MAY expose a constrained, read-only grant-status query capability to Resource Servers where required by an ecosystem profile or deployment policy.

The text should make clear that this is not general grant management by the Resource Server. It is a limited status query used to determine whether the Resource Server may continue acting on a grant in relation to a specific resource, scope, action, or asynchronous arrangement.