Client ID Metadata Document Software Statement Issuance

1.1. Protocol Overview

A client that holds an initial access token authorizing issuance, or a statement it can renew, uses token exchange at the token endpoint without a user agent (Section 5). A client can instead initiate the redirect flow at the authorization endpoint (Section 6) and redeem the resulting software statement code at the token endpoint.¶

The issuer fetches and snapshots the client's CIMD (Section 3.1), decides whether to issue, and signs the statement. The client carries the statement to trusting authorization servers in its audience, at registration ([REGISTRATION]) or at runtime ([STATEMENT]).¶

                +--------------------------+
                | Client ID Metadata       |
                | Document (client_id URL) |
                +--------------------------+
                  ^                      ^
            hosts |                      | fetches and
                  |                      |   snapshots
+----------+      |                      |      +---------------+
|          +------+                      +------+    Issuing    |
|  Client  |                                    | Authorization |
|          |--(1) software statement request -->|    Server     |
|          |<-(2) software statement -----------|   (approval)  |
+----------+      (signed JWT)                  +---------------+
     |
     | (3) presentation, publication, or registration
     v
+---------------+  +---------------+       +---------------+
|   Trusting    |  |   Trusting    |  ...  |   Trusting    |
| Authorization |  | Authorization |       | Authorization |
|   Server 1    |  |   Server 2    |       |   Server M    |
+---------------+  +---------------+       +---------------+

+--------+                                  +----------------------+
| Client |                                  | Authorization Server |
+--------+                                  +----------------------+
    |                                                 |
    | (A) Authorization request                       |
    |     response_type=software_statement_code       |
    |     client_id=<metadata document URL>           |
    |     code_challenge, [audience], [dpop_jkt]      |
    |------------------------------------------------>|
    |                                                 |
    | (B) Software statement code response            |
    |     (software_statement_code, state, iss)       |
    |<------------------------------------------------|
    |                                                 |
    | (C) Redemption                                  |
    |     (software_statement_code, code_verifier,    |
    |      completion_mode=deferred)                  |
    |------------------------------------------------>|
    |                                                 |
    | (D) Software statement response or              |
    |     deferred response (deferral_code)           |
    |<------------------------------------------------|
    |                                                 |
    | (E) Poll(s) (deferral_code), if deferred        |
    |------------------------------------------------>|
    |     pending state or final response             |
    |<------------------------------------------------|

3.1. Metadata Snapshot

CIMDs can change while a request is pending. For each request, the authorization server retrieves and validates the document (Section 3) and computes the metadata digest of the exact octets it retrieved, as Section 3.1 of [STATEMENT] requires. These octets and their digest are the request's metadata snapshot. A deferral created at redemption is bound to the code's snapshot and audience. The authorization server MUST bind the snapshot and the requested audience to each software statement code and deferral it creates, and issues the statement over that snapshot.¶

The authorization server MAY retrieve the document again before issuing the software statement. If it does so and the digest differs, it MUST either re-evaluate the request under the new document, binding the new document as the snapshot, or reject the request. This applies even if the change touches no member its policy examines. A statement over a superseded snapshot fails the digest comparison (Section 5.2 of [STATEMENT]). Replacing the snapshot is the authorization server's own action and changes no parameter of the request, such as the requested audience.¶

The authorization server MUST NOT combine values from different document versions.¶

Replacing the snapshot does not alter the sender-constraint context fixed for a deferral at origination ([DTR]). If a replacement snapshot no longer authorizes the key material behind that context, for example because the client-authentication key is absent from the new document, the authorization server MUST invalidate the deferral. The client then makes a new request under its current keys.¶

The authorization server MUST reject a document containing duplicate object member names (Section 5.2 of [STATEMENT]).¶

An issuer can require jwks inline (Section 13.2 of [STATEMENT]).¶

[CIMD] permits a document to carry a software_statement member. An issuer evaluates the document as served and MUST NOT refuse a document because it carries the member. Trusting authorization servers ignore a statement embedded there (Section 3 of [STATEMENT]), and refusing would leave a client whose document embeds a statement unable to renew it.¶

4.1. Audience

The audience parameter of an authorization request (Section 6) or token exchange (Section 5) names a target service at which the client intends to use the statement, with the semantics of Section 2.1 of [RFC8693]. The parameter can be repeated to request several. Each value MUST be an authorization server issuer identifier as defined by [RFC8414]. Values MUST NOT be duplicated, and order is insignificant.¶

The authorization server selects the final audience according to policy. It MUST NOT place in the statement's aud claim any value the request did not carry, except as Section 5.2 provides.¶

If no requested audience is acceptable, the authorization server MUST reject the request with the invalid_target error code, as defined by [RFC8707] at the authorization endpoint and by Section 2.2.2 of [RFC8693] at the token endpoint. An authorization server whose policy requires a restricted audience rejects a request carrying none, other than a renewal whose subject statement names an audience, with the same error.¶

These audience semantics apply only to software statement requests and do not affect proprietary uses of the parameter for access-token targeting.¶

4.2. Prohibited Parameters

A software statement request does not grant access to a protected resource, and it asks for a statement rather than presenting one. An authorization request, software statement code redemption, or token exchange under this specification MUST NOT contain the scope parameter, the resource parameter ([RFC8707]), the authorization_details parameter ([RFC9396]), or the software_statement parameter (Section 5.4 of [STATEMENT]). The authorization server MUST reject a request containing any of them with the invalid_request error code. In an authorization request or token exchange, the audience parameter (Section 4.1) is not prohibited: it describes the requested artifact rather than requesting access. Code redemption prohibits it (Section 8).¶

5.1. Initial Access Tokens

An initial access token presented under this profile:¶

• MUST be time limited.¶

• MUST be limited to the issuer.¶

• MUST be bound to an exact client identifier URL or an explicitly authorized client identifier namespace.¶

• MUST have at least 128 bits of entropy if it is opaque.¶

• MUST be sender-constrained to a client key if it is reusable, for example through DPoP or mutual TLS, and the authorization server MUST verify that binding against the key the exchange request proves.¶

• MUST be single-use if it is a bearer token.¶

The authorization server MUST enforce every restriction the token carries, such as on audiences or metadata, and MUST prevent replay beyond its permitted number of uses. A use is consumed when the authorization server commits to an outcome: issuing a statement, creating a deferral, or denying issuance. Concurrent presentations of a single-use token MUST NOT both be committed.¶

Issuance policy determines whether an initial access token authorizes the client only to request a statement or also authorizes its issuance.¶

5.2. Renewal

A client renews by presenting its current or most recent software statement as the subject token. The authorization server MUST verify the following:¶

• The authorization server issued the statement.¶

• The statement's sub claim equals the request's client_id parameter.¶

• The client authenticated with a key carried both by the document the statement's cimd_digest claim names and by the current document.¶

That authentication is the holder binding: without it, whoever held a copy of the statement could renew. To check the reviewed document's keys, an issuer offering renewal needs the octets of each document it issues a statement over (Section 13.4).¶

A client rotating keys inline renews while its document carries both the old and the new key. For a document naming jwks_uri, the binding is to whatever that location serves. A public client holds no such key and obtains a new statement through the redirect flow (Section 6).¶

A renewed statement MUST NOT be broader than the subject statement: its aud is within the requested audience narrowed to the subject statement's aud (or within that aud if the request names none), it carries any aud_tenant claim of the subject statement, and its statement_uses permits no use the subject statement does not. It is matched to the subject statement by iss and sub ([LIFECYCLE], [REGISTRATION]).¶

An issuer MUST NOT accept as the subject token a statement it has withdrawn, or one whose status it publishes as other than VALID ([LIFECYCLE]). Renewing such a statement would reissue the decision that withdrawal ended.¶

The authorization server MAY accept a statement that has expired, and SHOULD bound how long after expiry it will do so.¶

If the current document's digest equals the subject statement's cimd_digest, whether renewal requires fresh review is issuance policy. If the digests differ, the issuer MUST apply the decision it would apply to a first issuance for that document, and MUST NOT renew on the strength of the prior statement alone. Without this rule, whoever can change the document could obtain the issuer's signature over an unreviewed change.¶

7.1. Software Statement Code Response

The software statement code response applies the authorization response protections of [RFC9700]. The authorization server returns the following parameters to the client's redirection endpoint, using the selected response mode:¶

software_statement_code:

REQUIRED. A short-lived, single-use artifact redeemed at the token endpoint (Section 8). It MUST be bound to the client identifier, redirection URI, PKCE challenge, metadata snapshot, requested audience, and, when the dpop_jkt parameter was present, that JWK thumbprint.¶

The value MUST contain at least 128 bits of entropy from a cryptographically secure random source, be opaque to the client, expire shortly after issuance, and not be accepted more than once.¶

state:

REQUIRED if the authorization request contained the state parameter. The exact value received in the authorization request.¶

iss:

REQUIRED. The authorization server issuer identification parameter defined by [RFC9207].¶

A software statement code is not an authorization code and MUST NOT be redeemable as one.¶

Before redeeming a software statement code, the client MUST verify the state parameter, if it sent one, and MUST validate the authorization response iss parameter according to [RFC9207].¶

Because scripts at the redirection endpoint can access the fragment, the fragment response mode SHOULD NOT be used. A client MAY request the form_post response mode [FORM-POST].¶

The following is an example of a software statement code response using the default query response mode (line breaks for display purposes only):¶

HTTP/1.1 302 Found
Location: https://client.example.org/cb?
  software_statement_code=V7e1gP8zT2mN4qR6sW9xY3aB5cD7fH0jK2pL4uQ6vX&
  state=4L7xQ2mN9pR6sT1vW8yZ3aB5cD0fG2hJ&
  iss=https%3A%2F%2Fserver.example.com

10.1. Terminal Denial

When the authorization server decides not to issue the requested software statement, it returns a token error response as defined in Section 5.2 of [RFC6749] with the access_denied error code (Section 3.5 of [RFC8628]), and MUST include the Cache-Control: no-store response header field. This applies to code redemption and token exchange alike, including when the denial answers a polling request (Section 9).¶

The denial is terminal for the request. A denied deferral behaves as [DTR] specifies for a request resolved with an error, and a client that receives the access_denied error code in response to a polling request MUST NOT send another polling request with that deferral_code. A denial does not preclude a later issuance request. Whether to accept one is issuance policy.¶

13.1. Retrieval and Approval-Queue Bounds

An authorization server can rate-limit token exchanges, cache successful retrievals and back off after failures as Section 11.1 of [STATEMENT] describes, and bound pending deferrals per client identifier and requester. Because the redirect flow reaches the approval queue before any client-authenticated step, the same rate limits and pending-approval bounds per client identifier can apply there.¶

13.2. Handling the Issued Statement

A client ought to key the statement on issued_token_type and keep it out of logs.¶

13.3. Approval Interface

An approval interface ought to state that the decision vouches for the client's CIMD, ought not to imply that the approver is granting the client access to resources, and ought to present the following:¶

• The client identifier URL, with its origin shown as the client's identity, and with display metadata such as the client_name and logo_uri members marked as asserted by the client (a look-alike document can carry another vendor's name).¶

• The document content the statement will vouch for, identified by its metadata digest.¶

• The audience the issuer intends to place in the statement.¶

• The tenant the decision is confined to, if the statement will carry the aud_tenant claim ([STATEMENT]).¶

• The intended lifetime.¶

If the client requested a different or broader audience, the interface ought to make narrowing visible.¶

13.4. Audit and Logging

An authorization server ought to keep an audit record that binds each decision, whether approval or denial, to the following:¶

• The metadata digest (Section 3.1) of the document the deciding party evaluated.¶

• The policy under which the decision was made.¶

• The identity of the deciding party.¶

• The time of decision.¶

An authorization server ought to retain the exact retrieved octets of the approved document for audit, because a re-serialized copy cannot reproduce the digest. A deployment that requires approver attribution can retain it in an audit record or define a statement claim and its privacy semantics.¶

14.1. Review and Approval Practice

Because the client authors its CIMD, an issuer ought to corroborate security-relevant metadata through evidence beyond the document itself. Issuance policy can relate the redirection URI's origin to the client identifier URL or the CIMD's client_uri member.¶

The policy governing who can approve issuance ought to be at least as restrictive as the policy under which the issuer registers a client manually. A token exchange carries no in-band evidence of user participation, so an authorization server ought not to treat one as implying prior user consent. An initial access token that authorizes issuance (Section 5.1) records a decision made, when the token was issued, under the policy that governs approval in the redirect flow.¶

To keep a look-alike document from reaching approval, an issuer ought to limit what an approver can approve to client identifiers under publisher namespaces it has enrolled. A document naming attesters in client_attesters ([ATTESTERS]) endorses them for the software under review and deserves particular scrutiny.¶

14.2. Deferral Lifetimes

Issuers ought to set deferral code lifetimes that reflect their actual approval latency, which for a review involving human judgment can be hours or days (Section 9).¶

14.3. Signing Keys

An issuer ought to protect its signing keys according to the scope of its trust relationships and support controlled key rotation.¶

15.1. Authorization Response Security

The software statement is a signed credential and can contain sensitive deployment information, so it is never returned in an authorization response (Section 7). The client's iss check (Section 7.1) counters mix-up.¶

For the reason Section 5.6.3 of [STATEMENT] gives, Section 6 refuses a redirection URI that another application on the same device could claim. A native public client can host an https endpoint or use the token exchange profile (Section 5).¶

A software statement code in a URL is visible to browser history, referrer fields, logs, and other observers. It is short lived, single use, and unredeemable without the PKCE verifier and any bound dpop_jkt key. The form_post response mode (Section 7.1) keeps the code out of URLs.¶

15.2. Token Exchange Considerations

Validating the subject token before metadata retrieval or enqueueing (Section 5) limits resource consumption by unauthorized requesters. Other bounds are local policy (Section 13.1).¶

A subject token appears in a form body, so any component recording request bodies can expose it. Clients and authorization servers MUST protect a subject token as a bearer credential unless its format provides proof of possession. An authorization server ought to keep subject tokens out of logs, traces, and audit records, and an initial access token ought to be integrity protected and kept confidential in transit and at rest.¶

15.3. Renewal by Prior Statement

If the reviewed and current documents name a jwks_uri, whoever controls that location can supply a key that satisfies the holder binding of Section 5.2. Binding renewal to the client's key spares automated renewal a long-lived reusable initial access token, a standing credential to mint statements.¶

15.4. Signing Keys and Algorithms

A compromised software statement signing key lets an attacker mint statements for every audience that trusts it (Section 14.3).¶

Issuers SHOULD prefer signature algorithms with modern security properties, such as PS256, ES256, or Ed25519 [RFC9864], over RSASSA-PKCS1-v1_5 (RS256).¶

15.5. Approver Authority

A software statement does not identify the human or system that approved issuance (Section 13.4).¶

An approved statement is accepted at every authorization server in its audience, not only within the approver's own scope. Approval by a party authorized only for a personal or organizational scope MUST NOT produce a statement whose audience exceeds that scope, or whose aud_tenant claim names a tenant outside it.¶

17.1. OAuth Authorization Endpoint Response Types Registry

This specification requests registration of the following value in the IANA "OAuth Authorization Endpoint Response Types" registry established by [RFC6749]:¶

Response Type Name:

software_statement_code¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 6 and Section 7¶

17.2. OAuth URI Registry

This specification requests registration of the following values in the IANA "OAuth URI" registry:¶

URN:

urn:ietf:params:oauth:grant-type:software-statement¶

Common Name:

OAuth Software Statement Grant Type¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 8¶

URN:

urn:ietf:params:oauth:token-type:software-statement¶

Common Name:

OAuth Software Statement Token Type¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 10 and Section 5¶

17.3. OAuth Parameters Registry

This specification requests that IANA add this specification, Section 4.1, as an additional reference for the existing audience parameter registered by [RFC8693] and extend its usage location to include authorization requests. The parameter name and change controller are unchanged.¶

This specification also requests registration of the following value in the IANA "OAuth Parameters" registry established by [RFC6749]:¶

Parameter Name:

software_statement_code¶

Parameter Usage Location:

authorization response, token request¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 7.1 and Section 8¶

17.4. OAuth Extensions Error Registry

This specification requests that IANA update the existing invalid_target entry, adding authorization error responses to its usage locations and this specification as a reference:¶

Error Name:

invalid_target¶

Error Usage Location:

authorization error response, in addition to the locations already registered¶

Related Protocol Extension:

resource parameter¶

Change Controller:

IESG¶

Specification Document(s):

[RFC8707], this specification (Section 4.1)¶

17.5. 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_subject_token_types_supported¶

Metadata Description:

JSON array of subject token types accepted for exchange into a software statement.¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 12 and Section 5¶

18.1. Normative References

[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>.

[DTR]

de Oliveira Niero, G. and D. Liu, "Deferred Token Response", Work in Progress, Internet-Draft, draft-ietf-oauth-deferred-token-response-01, 31 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-deferred-token-response-01>.

[FORM-POST]

Jones, M. B. and B. Campbell, "OAuth 2.0 Form Post Response Mode", 27 April 2015, <https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html>.

[OAUTH-MRT]

de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. B. Jones, "OAuth 2.0 Multiple Response Type Encoding Practices", 25 February 2014, <https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html>.

[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>.

[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/rfc/rfc7591>.

[RFC7636]

Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, <https://www.rfc-editor.org/rfc/rfc7636>.

[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>.

[RFC8628]

Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, <https://www.rfc-editor.org/rfc/rfc8628>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8707]

Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9207]

Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server Issuer Identification", RFC 9207, DOI 10.17487/RFC9207, March 2022, <https://www.rfc-editor.org/rfc/rfc9207>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9700]

Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, <https://www.rfc-editor.org/rfc/rfc9700>.

[STATEMENT]

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

18.2. Informative References

[APPROVAL-DCR]

Dellaert, P., "OAuth 2.0 Approval-Based Dynamic Client Registration", Work in Progress, Internet-Draft, draft-dellaert-oauth-approval-based-dcr-00, 19 July 2026, <https://datatracker.ietf.org/doc/html/draft-dellaert-oauth-approval-based-dcr-00>.

[ATTESTERS]

McGuinness, K., "OAuth 2.0 Client Attester Endorsement", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-attesters-01, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-attesters-01>.

[AU-CDR]

"Consumer Data Standards (Australia)", n.d., <https://consumerdatastandardsaustralia.github.io/standards/>.

[LIFECYCLE]

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

[REGISTRATION]

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

[RFC9864]

Jones, M.B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, DOI 10.17487/RFC9864, October 2025, <https://www.rfc-editor.org/rfc/rfc9864>.

[UK-OPEN-BANKING]

"Open Banking UK Dynamic Client Registration Specification v3.3", n.d., <https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html>.