Client ID Metadata Document Software Statement Lifecycle

1.1. Protocol Overview

The following non-normative sequence summarizes a statement's lifecycle at one authorization server:¶

1. An issuer issues a statement as [STATEMENT] defines, optionally with a reference to its entry in a Token Status List (Section 6.2).¶

2. The authorization server admits a client on the statement, or registers one under [REGISTRATION], and records the statement. The iat floor for the statement's iss and sub, kept for each use the statement permits, advances to its iat if that is later. A multi-tenant server keeps such floors per tenant for statements confined to a tenant, and server-wide for others (Section 4).¶

3. The issuer issues a later statement about the same software, for example over a changed document. Once the authorization server accepts it, the earlier statement is superseded for new grants and registrations, and grants already opened on the earlier statement continue. An issuer that uses a withdrawal mechanism and narrows its review also withdraws the earlier statement, as Section 3 recommends.¶

4. To withdraw a statement, the issuer changes its status (Section 6.2) and can send a status change event (Section 7) that prompts servers to check it. The authorization server learns of the withdrawal when it next resolves the status, and keeps a refusal record for the statement (Section 3).¶

5. When the client refreshes a grant that needs a replacement, such as one whose recorded statement is covered by a refusal record or has expired where the server requires a current statement (Section 5.1), the client can offer a later statement, and a server that supports pulled statements can pull one (Section 5.2). The grant continues under that statement if the server accepts it. Otherwise the refresh is rejected (Section 8).¶

A trusting authorization server that implements this specification applies all of Section 3 through Section 5 and Section 8, whatever withdrawal mechanism it uses, if any. For an issuer, publishing status and sending events are optional, and supersession and refresh replacement work without them.¶

The iat floor (Section 4) limits only the acceptance of a statement to open something new, such as an admission, a registration, or a refresh replacement. A refusal record (Section 3), and expiry where the server requires a current statement (Section 5.1), also limit the continuation of a grant that records the statement. Table 1 shows what a statement's standing at one authorization server allows. Each row describes one condition on its own. A statement can meet more than one, such as being both superseded and covered by a refusal record, and then the limits of every row it meets apply.¶

A registration ([REGISTRATION]) advances the iat floor and follows the same pattern: a refusal record covering its governing statement ends its validity at the server holding the record, and a superseded governing statement leaves it valid until that statement expires.¶

5.1. Requiring a Current Statement

When the establishment's recorded statement has expired, the authorization server SHOULD require a current statement on refresh-token use (Section 12.1). A refresh under an establishment needs a replacement (Section 5.2) if a refusal record covers the recorded statement, or if the recorded statement has expired and either the server requires a current statement or a required issuer (Section 4 of [STATEMENT]) covers the establishment's sub in the establishment's tenant. The server MUST reject a refresh that needs a replacement unless it accepts one, even if it does not otherwise require a current statement. If a required issuer covers that sub and tenant and the recorded statement is from another issuer, the server MUST reject the refresh, and the client opens a new grant by runtime presentation. A raised iat floor (Section 4) does not by itself require a replacement.¶

5.2. Refresh Replacement

A replacement is a presentation use of its statement (Section 3 of [STATEMENT]).¶

On refresh-token use under an establishment, the authorization server first completes the checks of Section 5.7.1 of [STATEMENT] on the establishment's proven key, unchanged, before it considers any replacement. A server that implements this specification then proceeds as follows. A refresh rejected at any step leaves the grant's state unchanged.¶

1. Decide whether Section 5.1 requires a replacement or rejects the refresh, having consulted any withdrawal mechanism as Section 3 recommends.¶

2. Obtain a replacement. A client can offer one on any refresh in the software_statement parameter. If no replacement is needed, an offered statement that fails the client_id rule below or a requirement of step 3, or that the server cannot evaluate because a retrieval needed only for that statement did not complete, is ignored, and the refresh proceeds as one offering none, as at a server that does not implement this specification. A request carrying a replacement MUST meet the client_id rule that Section 5.4 of [STATEMENT] sets for a request making a runtime presentation. A statement with the recorded iss and jti is not a replacement, and a request carrying it is processed as one offering none. When a replacement is needed and the request carries none, a server that supports pulled statements pulls, however the establishment was created, and takes as the replacement the most recently issued statement with the recorded iss and sub among those it considers under Section 5.5.1 of [STATEMENT], Section 3, and Section 4. A refresh that needs a replacement and obtains none is rejected: a reviewed grant never continues under the policy for clients the server has not reviewed.¶

   The pull uses the retrieval and selection rules of Sections 5.3 and 5.5.1 of [STATEMENT]. The continuation rules here apply instead of those sections' rules for opening a new grant, so a refresh whose pull does not complete is rejected.¶

3. Validate the replacement. If a replacement is needed, a refresh whose replacement fails any of the following requirements is rejected. The replacement:¶

   • MUST validate under Section 3.2 of [STATEMENT], Section 3, and Section 4.¶

   • MUST have the recorded statement's iss and sub.¶

   • MUST have an iat later than the recorded statement's.¶

   • MUST name in cimd_digest the document currently served at that sub, which the server confirms by retrieval or by revalidating octets it holds.¶

   • MUST name a document that carries the establishment's proven key, in its jwks or at its jwks_uri (Section 5.6.1 of [STATEMENT]), or, for an establishment created under Section 5.6.2 of [STATEMENT], a document that still satisfies that section.¶

   • MUST name a document that permits the establishment's Selected Method (Section 2 of [STATEMENT]) and that does not make the statement review-only (Section 5.6.3 of [STATEMENT]). Refresh keeps the sender-constraint mechanism (Section 5.7.1 of [STATEMENT]), so a replacement cannot change it.¶

   A replacement that meets these requirements is accepted.¶

4. Bound access and update. The refreshed access MUST fall within the metadata of the document an accepted replacement names or, without one, the establishment's reviewed metadata. If a replacement is accepted, the refreshed grant's statement identity (iss and jti), iat, effective expiry, any claim an extension uses to locate the statement, reviewed metadata and the digest it matched, and issuer trust decision become the replacement's, in one atomic update. Concurrent replacements resolve to the most recently issued statement.¶

A replacement accepted on refresh MUST apply only to the grant refreshed.¶

If the server bounds establishments (Section 11.3 of [STATEMENT]), a count persists across replacements: a replacement accepted on refresh does not add to it.¶

Figure 1 shows the order of these steps, and Table 2 the error each rejection returns. Section 8 lists every code. Three rules take precedence over the table. At any step, a request that needs a retrieval that did not complete is rejected with temporarily_unavailable (Section 6 of [STATEMENT]), except a retrieval needed only to evaluate a statement that step 2 ignores. Otherwise, a request for which the document currently served at the establishment's sub cannot be obtained or fails validation is rejected with invalid_client (Section 6.3 of [STATEMENT]; Section 6.1 of [CIMD]). A proof that its mechanism does not accept is rejected with that mechanism's own error, such as invalid_dpop_proof, or answered with its challenge, such as use_dpop_nonce (Section 6.5 of [STATEMENT]).¶

        refresh-token request
                  |
                  v
          proven key checks
                  |
                  v
     1. is a replacement needed?
                  |
       +----------+------------------+
       |                             |
       | needed, or one offered      | not needed,
       v                             | none offered
     2. obtain it, offered or pulled |
       |                             |
       v                             |
     3. validate it                  |
       |                             |
       +----------+------------------+
                  |
                  v
     4. bound the access, apply any
        accepted replacement
                  |
                  v
            tokens issued

6.1. Issuer Key Sets

An issuer's Status List key set is the JWK Set at the jwks_uri of its authorization server metadata [RFC8414], discovered from the configured iss. For an issuer that is not an authorization server (Section 4 of [STATEMENT]), it is the JWK Set at a Status List key set URL in the trust configuration. The https and certificate requirements of Section 4 of [STATEMENT] for a statement key set URL apply to that URL. An issuer MUST serve its statement key set, its Status List key set, and the key set at the jwks_uri of any transmitter configuration metadata it publishes (Section 7.3) at three different locations, with no key in more than one of them.¶

6.2. Status Publication

An issuer that uses Token Status List publishes the status of its statements as [STATUSLIST] defines. A statement locates its entry in the issuer's Status List Token through the status claim, whose status_list member gives the status list URI and index (Section 6.2 of [STATUSLIST]). It is the claim by which this specification locates a statement, and an establishment records that claim (Section 5.7 of [STATEMENT]). An issuer that publishes status:¶

• MUST publish status, and carry the status claim, for every statement it issues under a given iss from the point it begins publishing. A trusting authorization server treats a statement without the claim as one it cannot check for withdrawal, which its effective expiry bounds (Section 3).¶

• MUST NOT assign the same combination of status list URI and index to more than one statement, including across successive Status List Tokens published at that URI. Withdrawing a statement then affects no other.¶

• MUST sign each Status List Token with a key in its Status List key set (Section 6.1).¶

• MUST include the exp claim in every Status List Token it publishes. An older token then cannot stand in for a newer one indefinitely.¶

• MUST give each Status List Token it publishes at a given list URI an iat claim value later than that of any token it published there before (Section 6.3).¶

6.3. Status Resolution

Whether a server resolves statuses for an issuer, and which statuses other than VALID it refuses, is part of its trust configuration for that issuer (Section 4 of [STATEMENT]). If a statement carries the status claim and the server resolves statuses for its issuer, a status of INVALID is a withdrawal, as is any other status except VALID that the server's policy for that issuer refuses. On a withdrawal, the server holds a refusal record (Section 3). Token Status List defines no expiry for a withdrawal. A Status List Token's exp bounds its use as evidence, not a refusal derived from it, which lasts until a later Status List Token reports a status the server does not refuse.¶

Resolution follows [STATUSLIST]. A statement whose status index lies outside the list is rejected, as [STATUSLIST] requires. A server SHOULD retrieve the list on the list's own schedule, within the expiration and caching bounds its exp and ttl claims set (Section 13.7 of [STATUSLIST]), rather than once per request (Section 11.2, Section 13).¶

A server MUST NOT accept a Status List Token whose iat claim is earlier than that of the latest token it has accepted from that status list URI, and MUST treat one whose iat claim is equal but whose contents differ as a resolution failure. It keeps that latest iat, with a SHA-256 digest of the token it accepted at that iat, for each status list URI while it records any statement that references the list, even after it discards the token, so that it can recognize a different token with the same iat. A host serving an older token then cannot restore a status the issuer has withdrawn.¶

A server MUST verify a Status List Token only with keys from the issuer's Status List key set (Section 6.1), never with keys from the token itself. It reuses a retrieved key set only as Section 5.3 of [STATEMENT] permits for a statement key set.¶

7.1. Stream Configuration

An issuer that supports the events defined here publishes transmitter configuration metadata as [SSF] defines, discoverable from its issuer identifier. Stream creation, subject management, verification, and delivery follow [SSF].¶

A trusting authorization server that supports these events SHOULD create one stream per configured issuer that offers them (Section 11.3).¶

The subjects appropriate to a stream are those of the issuer's statements whose aud claim is absent or names the receiving authorization server. A transmitter SHOULD scope each stream to those subjects.¶

A receiver SHOULD request the event this specification defines, and SHOULD use the stream verification facility of [SSF] periodically.¶

7.2. Status Changed Event

The event type identifier is urn:ietf:params:oauth:event-type:software-statement-status-changed (Section 14.1).¶

The event reports that the issuer has changed the published status of one or more statements for the subject. A transmitter MUST NOT transmit the event until a Status List Token reflecting the change is retrievable at the status list URI, including through any caching layer it operates. A receiver resolving before then would fetch the status from before the change.¶

The event does not say what the new status is, and a receiver MUST NOT infer one from it. Resolving a status of VALID after an event is not an error.¶

The subject of every event defined here is client software. Events carry it in the sub_id claim of [SSF] using the uri subject identifier format (Section 3.2.7 of [RFC9493]). The uri member carries the client's CIMD URL exactly as it appears in the sub claim of the statements the event concerns.¶

A trusting authorization server MUST match the subject by exact comparison of the uri member against a statement's sub claim.¶

The payload ([RFC8417]) of an event defined here has the following claims:¶

event_timestamp:

OPTIONAL. The claim defined by [CAEP], a NumericDate value that here gives the time at which the issuer changed the status the event reports. It is informational: a receiver does not use it to order, bound, or scope anything.¶

software_statement_jti:

OPTIONAL. The jti claim value of a single statement whose status changed (Section 7.4).¶

reason_admin:

OPTIONAL. An administrative message, as [CAEP] defines the claim.¶

The following is a non-normative example of the payload of a SET carrying this event for one statement:¶

{
  "iss": "https://issuer.example",
  "jti": "4d3559ec67504aaba65d40b0363faad8",
  "iat": 1792022400,
  "aud": "https://as.example",
  "sub_id": {
    "format": "uri",
    "uri": "https://client.example/app"
  },
  "events": {
"urn:ietf:params:oauth:event-type:software-statement-status-changed":
    {
      "event_timestamp": 1792022390,
      "software_statement_jti": "c2a907b34d28"
    }
  }
}

7.3. Event Issuer Trust and Keys

A trusting authorization server MUST NOT accept an event from an issuer it has not configured. It MUST verify the SET using keys from the jwks_uri member of the issuer's transmitter configuration metadata [SSF], discovered from the issuer identifier it has configured, and never from a key-location value carried in the event. The SET's iss claim is that issuer identifier, which is also the iss claim value of the statements the event concerns.¶

A receiver MUST NOT create or keep a stream whose transmitter configuration metadata gives as its jwks_uri the location of the issuer's statement key set or Status List key set (Section 6.1).¶

A SET carrying an event defined here MUST have an aud claim containing the audience of the stream that delivers it, which [SSF] lets the transmitter and receiver agree on. A receiver MUST NOT create or keep a stream whose audience does not identify it.¶

7.4. Receiver Processing

The affected statements are those the transmitting issuer made about the subject, never statements another issuer made about the same software. They are the statement the event's software_statement_jti claim names or, if the event names none, those the receiver holds or has cached a status for. An event about a subject for which the receiver holds no state requires nothing of it. A receiver ignores events for subjects outside the client identifier namespaces for which it accepts the transmitting issuer (Section 4 of [STATEMENT]).¶

A trusting authorization server that receives an event defined here MUST process it as follows:¶

1. Verify the SET as [RFC8417], [SSF], and Section 7.3 require.¶

2. Reject an event whose aud claim does not contain the audience of the stream that delivered it (Section 7.3).¶

3. Resolve the subject (Section 7.2).¶

4. Retrieve the Status List Token each affected statement's status claim references, as [STATUSLIST] defines, using a copy that the status list URI served, or confirmed by revalidation, in response to a request begun after the event arrived, without waiting for the schedule that would otherwise apply.¶

5. Apply the resolved status as Section 6.3 defines.¶

If step 1 or 2 fails, the receiver reports a SET error as [RFC8935] or [RFC8936] provides. Otherwise, it acknowledges the SET, whatever steps 3 to 5 produce.¶

One request begun after several events arrived serves every one of them that concerns the list it retrieves. An event is never grounds for refusal. Until the request succeeds, the copy the receiver holds remains in effect within its validity. If resolution does not complete, the receiver proceeds as it would had no event arrived.¶

A receiver MUST treat an event it has already applied as successfully delivered and acknowledge it as [RFC8935] or [RFC8936] requires, rather than reporting a delivery error. Rejecting a retry can stall or disable a stream carrying later events. A receiver recognizes a repeated delivery by the SET's jti claim, which is unique within an event feed (Section 2.2 of [RFC8417]), so it detects duplicates per stream.¶

Two constraints bound every event:¶

• A receiver MUST NOT let an event by itself create standing, extend a statement's lifetime, or otherwise increase what a client can do. A receiver MUST ignore any payload claim that would have such an effect.¶

• A receiver MUST continue to resolve status as Section 6.3 provides, independently of this mechanism. Stream loss, transmitter unavailability, or delivery failure then leaves resolution in force.¶

10.1. Server State

A server implementing this specification keeps the following state:¶

• a refusal record for each statement it has learned is withdrawn, or that its operator refused (Section 3);¶

• an iat floor for each iss, sub, and use, per tenant for statements confined to a tenant and server-wide for others (Section 4);¶

• for each establishment, its recorded statement and what step 4 of Section 5.2 records with it;¶

• with Token Status List, the Status List Tokens it holds and, for each status list URI, the latest iat it has accepted and a digest of that token (Section 6.3); and¶

• with status change events, its streams and the SET jti values it has applied on each (Section 7.4).¶

10.2. Resolution in Response to Events

A receiver can bound the rate of the retrievals that events cause by deferring a retrieval briefly and coalescing events that concern the same status list URI (Section 7.4). Its scheduled resolution continues regardless.¶

11.1. Withdrawal Practice

What a server does when it cannot consult a withdrawal mechanism it relies on is local policy (Section 3). For Token Status List, Section 8.3 of [STATUSLIST] recommends rejecting a statement whose status the server cannot resolve. Refusing makes issuer availability a precondition for every request the statement governs. Proceeding leaves a withdrawn statement acceptable until it expires.¶

A refusal that the server's operator entered, rather than one derived from a withdrawal mechanism, persists on the operator's own terms.¶

Withdrawal does not replace lifetime: an issuer chooses exp assuming no trusting authorization server uses a withdrawal mechanism.¶

11.2. Resolution Schedule and Lifetimes

Retrieving the list on its own schedule (Section 6.3) keeps each request a statement governs independent of issuer availability. Because events can be suppressed, a deployment ought to choose a resolution schedule and statement lifetimes it would accept with no event stream (Section 7.4).¶

11.3. Stream Coverage and Monitoring

A stream can cover every subject appropriate to it (Section 7.1), or the receiver can add each subject through the subject management of [SSF] when it first accepts a statement about that software. A withdrawal whose event was transmitted before the subject was added to the stream is found at a later resolution (Section 7.4).¶

A receiver ought to alert on stream loss rather than assume quiescence.¶

12.1. Withdrawal and Open Grants

A withdrawal revokes no issued token (Section 3). Beyond the cases of Section 13.7 of [STATEMENT], Section 5.1 can prevent further refresh of a grant until the server accepts a replacement (Section 5.2), and a server that removes an issuer from trust can end the grants opened and registrations created on that issuer's statements by entering refusal records for them.¶

12.2. Supersession and Refresh Replacement

The iat floor (Section 4) exists because one statement is consumable more than once (Section 11.3 of [STATEMENT]). Without it, a client holding an older, broader statement could keep opening registrations and establishments with it after its issuer narrows the review, until that statement expires. The floor closes this at a server only once the server accepts the later statement. A server that has not seen the later statement still accepts the earlier one, which is why Section 3 recommends that an issuer withdraw an earlier statement when it issues a later, narrower one.¶

Refresh verifies possession of the establishment's proven key before it considers a replacement (Section 5.2), so holding a statement gives a party nothing at refresh without the key, and a replacement cannot move a grant to another key.¶

Because a replacement must name the document currently served (step 3 of Section 5.2), a client cannot move a grant to a reviewed document it no longer serves.¶

12.3. Forged and Replayed Events

An event names no status, so a forged, replayed, delayed, or reordered event cannot change whether any statement is acceptable. Its only effect is a resolution the receiver would otherwise have performed on its own schedule.¶

The remaining exposure is resource cost: an attacker holding the issuer's SET signing key, or a misbehaving transmitter, can trigger resolutions (Section 10.2) and nothing more, because the key set that verifies SETs shares no location or key with the statement key set or the Status List key set (Section 6.1).¶

12.4. Event Suppression

Because a receiver resolves status independently (Section 7.4), an attacker who suppresses events delays a withdrawal at most until the receiver's next scheduled resolution that completes and, for new admissions, never beyond the affected statements' effective expiry (Section 11.2).¶

The absence of events looks the same on a healthy stream and a suppressed one. Periodic stream verification (Section 7.1) makes the difference observable (Section 11.3).¶

14.1. OAuth URI Registry

[RFC8417] establishes no registry of event types, so this specification takes its identifier from the oauth sub-namespace [RFC6755] and requests registration of the following value in the IANA "OAuth URI" registry:¶

URN:

urn:ietf:params:oauth:event-type:software-statement-status-changed¶

Common Name:

Client ID Metadata Document Software Statement Status Changed Event Type¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 7.2¶

14.2. OAuth Authorization Server Metadata Registry

This specification requests registration of the following value in the IANA "OAuth Authorization Server Metadata" registry established by [RFC8414]:¶

Metadata Name:

software_statement_replacement_supported¶

Metadata Description:

Boolean value indicating whether the authorization server applies Client ID Metadata Document software statement refresh replacements.¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 9¶

15.1. Normative References

[REGISTRATION]

McGuinness, K., "Client ID Metadata Document Software Statement Registration", Work in Progress, Internet-Draft, draft-mcguinness-oauth-cimd-sw-stmt-registration-00, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-cimd-sw-stmt-registration-00>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8417]

Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018, <https://www.rfc-editor.org/rfc/rfc8417>.

[RFC8935]

Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, M., and A. Nadalin, "Push-Based Security Event Token (SET) Delivery Using HTTP", RFC 8935, DOI 10.17487/RFC8935, November 2020, <https://www.rfc-editor.org/rfc/rfc8935>.

[RFC8936]

Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, M., and A. Nadalin, "Poll-Based Security Event Token (SET) Delivery Using HTTP", RFC 8936, DOI 10.17487/RFC8936, November 2020, <https://www.rfc-editor.org/rfc/rfc8936>.

[RFC9493]

Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, December 2023, <https://www.rfc-editor.org/rfc/rfc9493>.

[SSF]

Tulshibagwale, A., Cappalli, T., Scurtescu, M., Backman, A., Bradley, J., and S. Miel, "OpenID Shared Signals Framework Specification 1.0", 29 August 2025, <https://openid.net/specs/openid-sharedsignals-framework-1_0.html>.

[STATEMENT]

McGuinness, K., "Client ID Metadata Document Software Statement", Work in Progress, Internet-Draft, draft-mcguinness-oauth-cimd-sw-stmt-00, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-cimd-sw-stmt-00>.

[STATUSLIST]

Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf-oauth-status-list-21, 21 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-21>.

15.2. Informative References

[CAEP]

Cappalli, T. and A. Tulshibagwale, "OpenID Continuous Access Evaluation Profile 1.0", 29 August 2025, <https://openid.net/specs/openid-caep-1_0.html>.

[CIMD]

Parecki, A. and E. Smith, "OAuth Client ID Metadata Document", Work in Progress, Internet-Draft, draft-ietf-oauth-client-id-metadata-document-03, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-03>.

[RFC6755]

Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, <https://www.rfc-editor.org/rfc/rfc6755>.

[RFC7009]

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.