Client ID Metadata Document Software Statement

1.1. Protocol Overview

The following non-normative sequence summarizes runtime admission (Section 5.1):¶

1. An issuer reviews a client's CIMD and issues a statement whose sub claim is the document's URL and whose cimd_digest claim is the digest of the document's exact octets (Section 3).¶

2. Using its CIMD URL as client_id, the client presents the statement in a token request or, for a redirect flow, a pushed authorization request (Section 5.4). A client can instead publish its statements at the software_statements_uri its document names, for an authorization server that supports pulled statements to retrieve (Section 5.5).¶

3. The authorization server verifies the statement's signature and claims against its trust configuration for the issuer (Section 3.2, Section 4), retrieves the document, and compares the document's digest with the statement's (Section 5.2).¶

4. The authorization server binds the presenter to the reviewed document, in the request or at code redemption. A confidential client authenticates with a key the document carries, and a public client uses PKCE and binds a key in the request (Section 5.6). A request whose presenter cannot be bound is rejected, except in the cases Section 5.6.3 defines, such as a document with a redirection URI another application on the same device could claim. A review-only statement admits nothing on the strength of the review: unless Section 5.6 rejects the presentation, the request proceeds as one presenting no statement, and no establishment is created.¶

5. When the binding succeeds, the request proceeds under the reviewed document's metadata, without a registration. The authorization server records the state the grant depends on, including the proven key, as an establishment, and checks that key again on refresh (Section 5.7).¶

3.1. Metadata Digest

The metadata digest is the SHA-256 hash [RFC6234] of the retrieved representation body after removal of content coding, base64url-encoded without padding (Section 2 of [RFC7515]). The body is not transcoded, normalized, or re-serialized. Any byte order mark or trailing newline is included.¶

Retrieval for digest purposes follows [CIMD] and MUST NOT use content negotiation: the retrieving party sends Accept: application/json (Section 6 of [CIMD]) and no other variant selection. Equal digests show that the issuer and the trusting authorization server obtained the same octets, so any condition that makes retrieval depend on who is asking defeats the comparison.¶

A 304 Not Modified response shows that stored octets, and their digest, are still current only if it carries a strong entity tag that matches the one stored with them under strong comparison (Section 8.8.3.2 of [RFC9110]). Otherwise, the server retrieves the body again.¶

3.2. Validating a Statement

Before accepting a statement, a trusting authorization server MUST ensure the following:¶

• The typ JOSE header parameter has the value software-statement+jwt, and the kid header parameter is present.¶

• The signature verifies under a key trusted for the exact iss value, obtained as Section 4 requires.¶

• Every required claim of Section 3 is present and of the correct type.¶

• The statement is not expired, and its iat is not unreasonably far in the future according to the server's clock-skew policy.¶

• If the statement carries nbf, the current time is not before it, according to the same clock-skew policy (Section 4.1.5 of [RFC7519]).¶

• If the statement carries aud, a value in it exactly matches one of the server's issuer identifiers that its trust configuration permits the statement's issuer to name (Section 4).¶

• If the statement carries aud_tenant, aud carries exactly one value and aud_tenant identifies the request's tenant.¶

• If the server requires a tenant-scoped decision for the request, the statement carries aud_tenant, or the server's trust configuration confines the statement's issuer to the request's tenant (Section 4).¶

• If the server's trust configuration confines the statement's issuer to a tenant, the statement carries an aud claim with exactly one value, and the request belongs to that tenant.¶

• The use being made of the statement is one its statement_uses claim permits (Section 3).¶

• The sub claim is a client identifier URL conforming to [CIMD] and falls within the client identifier namespaces for which this server accepts the issuer (Section 4).¶

• Any claim the server does not recognize, and any client metadata claim (Section 3), is ignored.¶

• The JWT validation guidance in [RFC8725] has been applied.¶

A trusting authorization server that hosts more than one tenant MUST evaluate every tenant-specific check, such as an aud value that identifies one of its tenants, the aud_tenant claim, and a required issuer (Section 4), against the request's tenant. The request's tenant is the tenant that scopes what the server issues on the statement. The server MUST determine it before evaluating the statement, by its own means or from a signed assertion it has validated, and otherwise never from a request parameter, statement claim, or document member the client supplies.¶

Rejections outside a registration endpoint use Section 6.¶

4.1. Multi-Tenant Issuers

If an issuer reviews software for several customers whose decisions are each trusted independently, it MUST issue under a distinct iss value for each customer, so that each customer's decisions, and any state a server keeps per iss value, stay separate.¶

5.1. Admission

For a runtime presentation, the authorization server proceeds as follows, rejecting at the first failure (Section 6):¶

1. Obtain the statement, presented in the request (Section 5.4) or pulled (Section 5.5).¶

2. Validate the statement (Section 3.2), completing every check that needs no client-controlled retrieval before any such retrieval (Section 5.3).¶

3. Verify the client_id rule of Section 5.4.¶

4. Resolve the reviewed document and compare its digest (Section 5.2). A server that proceeds without the statement on a mismatch ends admission on the statement here.¶

5. Apply Section 5.6 to that document, verifying the sender constraint unless the statement is review-only (Section 5.6.3). If Section 5.6 or Section 5.5.2 defers the proof to code redemption, the server verifies it there.¶

6. Evaluate the request against the reviewed metadata (Section 5.2).¶

7. Create the establishment (Section 5.7), unless the statement is review-only (Section 5.6.3).¶

5.2. Reviewed Metadata

Having validated the statement, and before verifying the proof (Section 5.1), the authorization server MUST obtain the CIMD at the statement's sub, only by retrieval or from octets it has already digested for that identifier (Section 5.3), and compare its digest with the cimd_digest claim. If octets it already holds do not match, it retrieves the document once more before treating the mismatch as a change.¶

A match means the served document is the reviewed one, and its members are the client's metadata for the request. The server takes those members from the octets whose digest matched, not from another retrieval or a copy it has not digested. A mismatch means the document changed after review, and the authorization server MUST NOT treat the changed document as reviewed. It rejects the presentation or, by local policy, proceeds without the statement. If it proceeds, it applies its policy for CIMD clients it has not reviewed to the current document and creates no establishment for the statement.¶

A trusting authorization server MUST reject a reviewed document containing duplicate object member names (Section 4 of [RFC8259]), wherever it resolves one. Parsers interpret such names differently despite an identical digest.¶

The request is evaluated against the reviewed metadata as against any client's registered metadata ([RFC6749], [CIMD]): any requested grant type, response type, or scope MUST fall within it. A document that omits scope sets no ceiling on scope beyond the server's own policy. Omitted grant_types and response_types members take their [RFC7591] defaults.¶

5.3. Retrieval

Every retrieval this specification causes inherits the server-side request forgery protections in Section 10.7 of [CIMD], whether of the CIMD, a jwks_uri it names, the statements its software_statements_uri names, or a statement key set or the issuer metadata that locates one (Section 4). A trusted signature does not make a URL safe: the authorization server MUST apply its URL, redirect, address-range, transport, and content-type policy independently to every referenced location.¶

If a retrieval fails, the authorization server MUST reject the request and MUST NOT fall back to a weaker proof. The exception is a failed pull of statements, or a failed retrieval of a statement key set (Section 4) needed to verify a pulled statement, for a request opening a new grant: that failure does not by itself reject the request, which proceeds as Section 5.5.1 describes.¶

A retrieval does not complete if it times out, its connection fails, or the response has a 429 (Too Many Requests) status code (Section 4 of [RFC6585]) or a 5xx status code. Any other failure to obtain an acceptable representation is final, such as another 4xx status code, a body that is not a JSON object, or a response exceeding the server's configured size bound (Section 10.11 of [CIMD]), which the authorization server MUST treat as a failure rather than digesting what it read. After a final failure, a document is treated as failing validation, a key set as carrying no acceptable key, and a statements location as publishing no statement. For the document, a retrieval that does not complete is a transient failure and a final failure is a terminal failure (Section 6.1 of [CIMD]).¶

A trusting authorization server MAY reuse document octets it holds for digest comparison (Section 5.2), a key set retrieved from a document's jwks_uri, and a statement key set from either source (Section 4), only within ordinary HTTP caching bounds and a maximum reuse period of its own choosing. It MUST NOT let the publisher's cache directives alone (the client's for the document and its key set, the issuer's for a statement key set) determine how long held octets continue to match a statement or a removed key continues to verify (Section 13.2). Without this rule, a key the document carries inline would continue to verify after the publisher removes it.¶

5.4. Presentation Request

A client presents a software statement by including the following parameter in a token request or a pushed authorization request:¶

software_statement:

REQUIRED for a presentation made in a request. The software statement (Section 3). It is consumed as a runtime presentation or in a role defined by an extension the server implements. On refresh-token use under an establishment, a server ignores the parameter unless an extension it implements defines its role there. A request carrying the parameter in any other role is rejected.¶

A request making a runtime presentation MUST include the client_id parameter, even if the client authenticates, and its value, the client's CIMD URL, MUST exactly equal the statement's sub claim. The authorization server MUST reject a request that omits the parameter or carries another value. The effective client_id is the statement's sub, and the authorization server assigns none.¶

An authorization server that does not implement this specification ignores the parameter (Sections 3.1 and 3.2 of [RFC6749]).¶

5.5. Pulled Statements

A client can publish its statements at a URL its document names instead of presenting one. When a client opening a new grant presents no statement, at the token endpoint, the pushed authorization request endpoint, or the authorization endpoint, an authorization server that supports pulled statements MAY retrieve them. Admission then follows Section 5.1, except that:¶

• The server chooses the statement (Section 5.5.1).¶

• If the pull yields no usable statement, the request proceeds as if the client had presented none (Section 5.5.1).¶

• A pulled statement is review-only in the cases Section 5.5.2 identifies.¶

This specification defines the following client metadata member:¶

software_statements_uri:

OPTIONAL. URL, in a CIMD, at which the client publishes software statements about itself. The member has no meaning in a registration request. The URL MUST use the https scheme. A request to it returns, with a JSON media type such as application/json, a JSON object whose software_statements member is an array of statements (Section 3), each a string in JWS compact serialization. The metadata digest covers this member (Section 3.1).¶

An authorization server advertises support through software_statement_pull_supported (Section 8).¶

5.6. Sender Constraint

A runtime presentation that is not review-only (Section 5.6.3) MUST be sender-constrained under one of two models:¶

• Confidential client: by a key the reviewed document carries (Section 5.6.1).¶

• Public client: by an installation key the presenter binds (Section 5.6.2), while its reviewed redirection URIs, with PKCE S256, bind the presentation itself (Section 13.4).¶

The authorization server determines the model from the reviewed document's permitted methods that it supports and its policy allows, not from the request. It MUST apply the confidential-client model if those methods include one other than none, and otherwise applies the public-client model if they include none. If they include neither, Section 5 of [CIMD] applies. A document sets one model at a server. Components of one piece of software that differ in client type, such as a backend that holds a key and a desktop application that does not, therefore each use their own CIMD (Section 2.1 of [RFC6749]).¶

For a presentation that is not review-only, under either model:¶

• The presenter proves possession of the key its model requires through the applicable client authentication method or a DPoP proof [RFC9449]. A public client that binds its key through dpop_jkt proves possession at code redemption (Section 5.7). If a confidential client's request carries both client authentication and a DPoP proof, the key its client authentication proves is the proven key.¶

• The proof MUST be bound to the current request and validated with the replay protections of that mechanism.¶

• A confidential client's presenter MUST authenticate with a permitted method other than none that the server supports and its policy allows, and that method is the establishment's Selected Method. A public client's Selected Method is none.¶

• The authorization server MUST reject a presentation without such a proof or, for a confidential client, whose proven key the reviewed document does not carry.¶

5.7. Grant Binding

A successful presentation creates an establishment: the state against which the subsequent authorization request, code redemption, and refresh under the grant it opens are checked. It comprises the following:¶

• The validated sub.¶

• The statement identity (its iss and jti), its iat and effective expiry, and any claim an extension uses to locate the statement.¶

• The authorization server's own tenant the grant was opened for, if it hosts more than one.¶

• The reviewed metadata and the digest it matched (Section 5.2).¶

• The issuer trust decision.¶

• The Selected Method, the sender-constraint mechanism, and the proven key.¶

The authorization server MUST bind the resulting request_uri, authorization code, refresh token, and other grant continuation state to the establishment, as applicable. An establishment ends once no continuation state bound to it remains usable.¶

A token request that redeems an authorization code bound to an establishment:¶

• MUST have a client_id parameter exactly equal to the establishment's sub, even if the client authenticates.¶

• MUST be made in the tenant the establishment records, if the authorization server hosts more than one tenant (Section 3.2).¶

• MUST demonstrate possession of the establishment's proven key under the same sender-constraint mechanism or, for a confidential client whose statement was pulled at the authorization endpoint (Section 5.5.2), authenticate with the key that becomes the proven key.¶

• MUST NOT carry the software_statement parameter.¶

A redemption that carries a statement, has a wrong client identifier, is made in another tenant, or fails the key binding is rejected.¶

6.1. Statement Required Error

This specification defines the following error code:¶

statement_required:

A current software statement is required and none was presented or pulled, or the one presented or pulled is expired and otherwise valid. An extension can assign it to further cases. The client recovers by obtaining a current statement, from the required issuer if the tenant has one (Section 4).¶

6.2. Presentation Requests

A presentation at the token or pushed authorization request endpoint is rejected with the following error codes:¶

invalid_client:

Any of the following:¶

• The statement is malformed or fails validation (Section 3.2) for a reason other than expiry.¶

• The request's client_id differs from the statement's sub (Section 5.4).¶

• The request fails the sender constraint (Section 5.6), including a presentation opening a new grant at the token endpoint for a public client (Section 5.6.2).¶

• The reviewed document cannot be obtained, including over the size bound, fails validation as [CIMD] requires, contains duplicate member names (Section 5.2), or does not match and the server does not proceed without the statement (Section 5.2).¶

• The bound on establishments is reached (Section 11.3).¶

statement_required:

Expiry is the statement's only validation failure (Section 6.1), or a required statement is absent, including one from an issuer required for the tenant (Section 4).¶

unauthorized_client:

Any of the following, in place of statement_required if both apply at the step of Section 5.1 where the server rejects the request:¶

• The request exceeds the reviewed document's grant types or response types (Section 5.2).¶

• The document carries metadata this server's policy refuses.¶

• The client's statement is review-only where policy or a required issuer requires reviewed software (Section 5.6.3).¶

• The request is for software a required issuer excludes from the tenant (Section 4).¶

invalid_scope:

The request exceeds the reviewed document's scope (Section 5.2), or the document carries a scope this server's policy refuses.¶

invalid_request:

The request omits client_id (Section 5.4).¶

6.3. Code Redemption and Refresh

Under an establishment, code redemption (Section 5.7) is rejected with the following error codes:¶

invalid_grant:

The request has a wrong client identifier, is made in another tenant, or fails the key binding.¶

invalid_client:

The bound on establishments is reached (Section 11.3).¶

Under an establishment, a refresh-token request is rejected with the following error codes:¶

invalid_client:

The document currently served at the establishment's sub cannot be obtained or fails validation (Section 5.3), as Section 6.1 of [CIMD] requires.¶

invalid_grant:

Any other check of Section 5.7.1 fails.¶

unauthorized_client or invalid_scope:

The refreshed access exceeds the reviewed metadata or this server's policy, as for a presentation.¶

None of these rejections indicates refresh-token replay ([RFC9700]), whose detection this specification does not change.¶

6.4. Authorization Requests

If the authorization server's policy or a required issuer (Section 4) requires reviewed software, an authorization request from a client the server has not admitted on a statement is rejected in the authorization error response (Section 4.1.2.1 of [RFC6749]) with the following error codes:¶

unauthorized_client:

The client's statement is review-only (Section 5.6.3), or a required issuer excludes the software from the tenant (Section 4).¶

statement_required:

In any other case, subject to the order of Section 6, the authorization server MUST return this code.¶

When an authorization request is evaluated against a statement pulled at the authorization endpoint (step 6 of Section 5.1), one that exceeds the reviewed document's response types or scope is rejected with unauthorized_client or invalid_scope, as for a presentation (Section 6.2).¶

Before redirecting with an error, the authorization server validates the redirect_uri against the client's CIMD, which it resolves first, or, for a registered client, against its registered redirection URIs (Section 4.1.2.1 of [RFC6749]). If it cannot obtain a CIMD client's document, or the document fails validation, it MUST NOT redirect (Section 6.1 of [CIMD]).¶

6.5. Proof Mechanism Errors

If the proof mechanism defines an error of its own for a proof it does not accept, such as invalid_dpop_proof for a DPoP proof that fails the checks of Section 4.3 of [RFC9449] or use_dpop_nonce for a nonce challenge (Section 8 of [RFC9449]), the request is rejected with that error in place of the code this specification assigns to a failed sender constraint.¶

A proof that its mechanism accepts but that proves a key other than the one this specification requires, such as a key the reviewed document does not carry or one other than the establishment's proven key, is not an invalid proof but a failed sender constraint.¶

6.6. Error Descriptions

The authorization server can return non-sensitive diagnostics in the error_description parameter to a client it has authenticated, but MUST NOT reveal details of its issuer trust configuration (Section 4), such as the client identifier namespaces an issuer can attest, to an unauthenticated requester.¶

7.1. Presenting at the Token Endpoint

The following is an example of a client presenting a statement at the token endpoint of a server holding no record for the client (line breaks for display purposes only). The reviewed document, which is not shown, names a jwks_uri, the private_key_jwt authentication method, the client_credentials grant type, and a scope that includes tools.read, so the client authenticates with a key that document carries. The client_id is the statement's sub.¶

POST /token HTTP/1.1
Host: as.example
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&scope=tools.read
&client_id=https%3A%2F%2Fclient.example%2Fapp
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjIwMjYtMDgifQ...
&software_statement=eyJ0eXAiOiJzb2Z0d2FyZS1zdGF0ZW1l...

The authorization server validates the statement, retrieves the document at the statement's sub, checks its digest, verifies the client assertion against a key from that document's jwks_uri, and checks that the requested scope falls within the document's scope. It keeps no registration.¶

7.2. Publishing a Statement for Servers to Pull

The following is an example of a CIMD that names where its statements are published:¶

{
  "client_id": "https://client.example/app",
  "redirect_uris": ["https://client.example/cb"],
  "token_endpoint_auth_methods_supported": ["private_key_jwt"],
  "jwks_uri": "https://client.example/jwks.json",
  "software_statements_uri":
    "https://client.example/statements.json"
}

A request to that URL returns the statements, here one:¶

{
  "software_statements": [
    "eyJ0eXAiOiJzb2Z0d2FyZS1zdGF0ZW1lbnQrand0Iiwi..."
  ]
}

An authorization server receiving an ordinary authorization request with this client_id resolves the document, retrieves the statements, and selects the one from a trusted issuer whose cimd_digest matches the document it retrieved. It completes the binding when the client authenticates with private_key_jwt at code redemption (Section 5.5.2).¶

7.3. Statement Header and Payload

The following is an example of the JOSE header and payload of a statement over the document in the previous example, served exactly as shown there, with two-space indentation, LF line endings, and a single final newline, and without any indentation added for display (287 octets):¶

{
  "typ": "software-statement+jwt",
  "alg": "ES256",
  "kid": "2026-10"
}

{
  "iss": "https://issuer.example",
  "sub": "https://client.example/app",
  "aud": ["https://as.example"],
  "statement_uses": ["presentation"],
  "iat": 1790812800,
  "exp": 1793404800,
  "jti": "c2a907b34d28",
  "cimd_digest": "DHPektjuDKWb2ZSp3nQs-hSrZ_tJE5nOv5-H_J83zn0"
}

The statement names one audience and permits only runtime presentation, as omitting statement_uses would. It carries no client metadata: the reviewed document supplies it.¶

10.1. Client Attestation

A software statement and a client attestation [ABCA] are both signed third-party assertions. A statement records a review of client configuration. A client attestation attests a running instance and the key it holds, and is presented with a proof bound to the request.¶

Neither assertion grants access nor substitutes for the other.¶

10.2. Identity Assertions

A statement records that a named party reviewed software, not that a particular customer currently permits that software to act in its tenant. A tenant-scoped decision (aud_tenant) authorizes no particular user or transaction. When a customer's identity provider mediates a grant, as with a cross-domain identity assertion [IDJAG], it issues assertions per grant only for clients the customer permits. A statement serves when the issuer is not in the request path, or when a customer wants a portable record of what its review covered.¶

10.3. OpenID Federation

A trust mark [OPENID-FED] is also a signed third-party assertion about an entity. Section 17.5 of [OPENID-FED] permits trust marks whose accreditation authority is established out of band. This specification binds a review to exact CIMD octets and defines its use at admission, with directly configured issuers (Section 4) and no dependency on federation metadata resolution.¶

11.1. Caching and Reuse of Retrieved Content

A response from a software_statements_uri ought to be cached no longer than the document is. Because [CIMD] forbids caching an error response (Section 6.2 of [CIMD]), a failed retrieval (Section 5.3) is followed by back-off.¶

11.2. Retrieval and Processing Bounds

An authorization server can bound the retrieval and processing work of Section 13.6 as follows:¶

• Rate-limit presentations per statement identity, per subject, and per source, and pulls (Section 5.5) per client identifier and per source, before spending retrieval or storage on a new presentation.¶

• Refuse a presentation that would create a new establishment, before spending retrieval or storage on it, once a bound on establishments (Section 11.3) is reached.¶

• Bound JWT size and parsing work, concurrent retrievals, response size, and response time.¶

• Bound the size of a software_statements_uri response and the number of statements examined separately from the document's. Several issuers' statements outgrow a document-sized bound, and a host can pad the array.¶

• Discard pulled statements from unconfigured issuers before verifying any signature.¶

A response size bound also decides which reviewed documents a server can admit. Section 10.11 of [CIMD] recommends that a server read at most 5 kilobytes, so an issuer ought not to issue a statement over a larger document.¶

11.3. Bounding Establishments

A statement attests client software, identified by sub, not its runtime instances, and this specification defines no instance identifier. One unexpired statement can therefore open establishments at each trusting authorization server in its audience, and more than one at each.¶

A trusting authorization server can bound the number of establishments derived from one issuer's statements about one piece of software, identified by iss and sub claims. How it counts toward a bound is local policy, and a multi-tenant server keeps any bound per tenant. A bound stays effective only if what anyone holding a copy of a statement can create does not count toward it: a pushed authorization request and its unredeemed code, which a holder of a copy of a public client's statement can approve with its own account. Otherwise a holder of a copy could exhaust the bound for the software's other instances.¶

For software admitted under Section 5.6.2, a server can also bound establishments per resource owner, so that one user cannot exhaust a bound the software's other users share.¶

When a request is refused at a bound (Section 6.2, Section 6.3), the authorization server ought to state that reason in error_description, and the client can retry once earlier establishments end (Section 5.7).¶

11.4. User Interface, Audit, and Logging

An authorization server ought not to present the review in a review-only presentation to the user as an assurance about the presenter (Section 5.6.3). It can record the statement's issuer for audit and inventory.¶

Authorization servers ought to avoid logging software statements, which are sensitive in transit and at rest. A statement names reviewed software and, if it carries an audience, that software's intended relationships.¶

12.1. Configuring Issuer Trust

Trust configuration ought to constrain each issuer to the client identifier namespaces it is expected to attest (Section 4), for example URLs under the domains of the software publishers it serves. Without such a scope, a compromised or over-broad issuer can mint acceptable statements about any client software.¶

When a trusting authorization server configures an issuer whose decisions are confined to one of its tenants, as a customer's own issuer is, it ought to record with that configuration the client identifier namespaces for which the issuer's decision is required in that tenant (Section 4).¶

12.2. Audience and Tenant Claims

An issuer ought to name an audience.¶

An issuer ought to omit the aud_tenant claim from a statement whose review applies wherever its aud reaches, such as a marketplace listing. The claim is also unnecessary if the authorization server has one tenant, or if the issuer and the server have agreed that the server's trust configuration confines the issuer to a tenant, as they can for an issuer that does not know the tenant's identifier.¶

12.3. Statement Lifetime and Renewal

Short lifetimes tighten an issuer's control and increase renewal traffic. A fleet of statements issued together expires together, so issuers ought to stagger expiries or renew ahead of the boundary.¶

A changed document is always served before a statement over it exists, so presentations under an earlier statement fail the digest comparison (Section 5.2), and the client cannot be admitted on a statement until one over the changed document is issued. A statement's lifetime bounds how long a review stands without being renewed.¶

Instances need the most recently issued statement from a shared source rather than a copy fixed at build or install time, because the document can change (Section 5.2).¶

13.1. Assurance Provided by a Statement

A statement binds an issuer's review to the octets of a CIMD, which describes an OAuth client configuration. It does not bind the software's code, dependencies, or behavior. Software can change while its document stays the same, and the statement remains acceptable until it expires (Section 13.7) or is withdrawn under an extension. Assurance about the software itself rests on the issuer's review process. Any change to the document's octets, including one that changes no metadata value, makes statements over the earlier octets fail the digest comparison (Section 5.2). The digest covers a URL the document carries, such as logo_uri, but not the content served at it, which can change after review.¶

The following table states what admission on a statement does and does not establish:¶

13.2. Statement Theft and Replay

A copied statement admits nothing without the sender constraint (Section 5.6), which for a public client does not hold against a party that controls the user agent (Section 13.4). Except under Section 5.6.2 (Section 13.4), admitting only keys the reviewed document carries also prevents a downgrade to a key the issuer did not review. An extension admitting attested keys (Section 9) has to address downgrade itself.¶

Attesting a jwks_uri attests the location, not its contents: a compromised key host can add keys that satisfy the proof without a digest change. If that matters, an issuer attests jwks inline and accepts that rotation changes the digest. A server reusing a cached key set (Section 5.3) also accepts that a just-removed key can briefly continue to verify.¶

13.3. Servers That Do Not Implement This Specification

A statement carries no client metadata, so an [RFC7591] server that verified one without implementing this specification would take every metadata value from the registration request, attaching the issuer's approval to an attacker's redirection URIs and keys. Keeping statement signing keys in a dedicated statement key set, out of any jwks_uri, and away from statements of other profiles (Section 4, Section 8) means such a server finds no key that verifies a statement through the jwks_uri in an issuer's [RFC8414] metadata. It is exposed only if its operator configures the statement key set in it. For an issuer that is not an authorization server, that configuration is the only route to its keys, so the protection rests on operators recording the statement key set URL only in servers that implement this specification.¶

13.4. Copied Statements and Public Clients

A statement for a document that permits none can be presented under the public-client model by anyone holding a copy, at any server that supports none of the document's other methods or whose policy refuses them (Section 5.6). An issuer that intends software to be admitted only as a confidential client reviews only documents that do not permit none.¶

A party holding a copied statement for a public client can open a pushed authorization request in the reviewed software's name. It cannot receive an authorization code that another resource owner approves in a user agent the party does not control (Section 5.6.2), so other users are exposed only to a consent prompt carrying the reviewed software's name and branding. Rate limits (Section 11.2) and the issuer's choice of audience and lifetime bound that exposure.¶

A party that controls the user agent receives the code: an application embedding a user agent (Section 8.12 of [RFC8252]), or a holder authorizing with its own account. It redeems the code with a PKCE verifier and key of its own choosing. An admission under Section 5.6.2 therefore shows where codes are delivered, not which software holds the grant, and a tenant's required issuer (Section 4) cannot keep unreviewed software out for a user who chooses to run it. This is the client impersonation that Section 8.6 of [RFC8252] describes for public clients. An attested-key extension (Section 9) would strengthen the binding by giving the instance a key a third party vouches for.¶

13.5. Tenant Confusion at a Multi-Tenant Authorization Server

A multi-tenant server that derives the tenant one way to check a decision and another way to scope a token lets a client reach one tenant's resources on another tenant's decision. Section 3.2 requires one tenant for both, which the client cannot select through a request parameter, statement claim, or document member.¶

This specification defines no tenant parameter, and a CIMD URL is the same client_id in every tenant, so neither a client nor an issuer can verify that a server honored the tenant rule of Section 3.2.¶

The aud_tenant claim names a tenant at the trusting authorization server, not which of the client's own customers is asking. Software that acts for many customers under one client identifier and key presents the same statement and key for each, so a statement naming a tenant admits the software there on behalf of every customer it serves, and any of those customers can direct the software at another customer's tenant. A statement attests software and cannot prevent this. A deployment that needs a customer-to-tenant binding records it at the trusting authorization server.¶

13.6. External Retrieval and Resource Exhaustion

The retrievals of Section 5.3 happen before any client is registered or any user has interacted, so an unauthenticated requester can cause them with one acceptable statement or, at a server that pulls statements, with none. The bounds of Section 11.2 limit this work but do not prevent it.¶

13.7. Expiry and Open Grants

Under this specification, expiry limits new admissions and ends nothing already opened: a grant lasts for the life of its refresh tokens, whatever the statement's lifetime, unless the server finds the proven key gone from the client's document (Section 5.7.1). An older statement that has not expired remains admissible after a newer one narrows the review. A deployment that needs withdrawal, supersession, or grants that follow later reviews implements an extension providing them (Section 9). Removing an issuer from trust configuration, or narrowing what it can attest, does not by itself end a grant already admitted on one of its statements. Nor does configuring a required issuer (Section 4) end a grant already admitted. A server ends such grants by its own means, such as revoking refresh tokens.¶

13.8. Observable State

A statement_required refusal at the authorization endpoint (Section 6.4) travels through the user agent, so anyone who can see the redirection learns that this client has no established standing at this server. The disclosure is accepted because a client that cannot learn why it was refused cannot act. Outcomes still reveal some policy. By probing with public client identifier URLs, anyone can learn whether a request is admitted and, from statement_required versus unauthorized_client, whether a required issuer covers a client identifier in a tenant. Section 6.6 keeps further detail of the issuer trust configuration out of error_description for unauthenticated requesters.¶

15.1. OAuth Parameters Registry

This specification requests registration of the software_statement parameter in the IANA "OAuth Parameters" registry established by [RFC6749]:¶

Parameter Name:

software_statement¶

Parameter Usage Location:

authorization request, token request¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 5.4 and Section 5.4.2¶

The "OAuth Dynamic Client Registration Metadata" registry established by [RFC7591] already contains a software_statement member, which this registration does not affect. The parameter reuses the name because it carries the same [RFC7591] artifact.¶

15.2. Media Type Registration

This specification requests registration of the application/software-statement+jwt media type in the IANA "Media Types" registry [RFC6838]. [RFC7591] defines no media type for software statements. This registration covers only statements under this specification, as its "Applications that use this media type" entry states, and a statement of another profile carries a typ value of its own.¶

Type name:

application¶

Subtype name:

software-statement+jwt¶

Required parameters:

n/a¶

Optional parameters:

n/a¶

Encoding considerations:

8bit. A software statement is a JWT. JWT values are encoded as a series of base64url-encoded values separated by period ('.') characters, as registered for application/jwt in Section 10.3.1 of [RFC7519].¶

Security considerations:

See Section 13 of this specification and Section 11 of [RFC7519].¶

Interoperability considerations:

n/a¶

Published specification:

This specification¶

Applications that use this media type:

Issuers, authorization servers, and clients that issue, request, or accept software statements under this specification; other profiles are distinguished by their own typ values¶

Fragment identifier considerations:

n/a¶

Additional information:

Magic number(s): n/a. File extension(s): n/a. Macintosh file type code(s): n/a.¶

Person & email address to contact for further information:

Karl McGuinness, public@karlmcguinness.com¶

Intended usage:

COMMON¶

Restrictions on usage:

none¶

Author:

Karl McGuinness, public@karlmcguinness.com¶

Change controller:

IETF¶

15.3. JSON Web Token Claims Registry

This specification requests registration of the following values in the IANA "JSON Web Token Claims" registry established by [RFC7519]:¶

Claim Name:

cimd_digest¶

Claim Description:

Unpadded base64url-encoded SHA-256 digest of the retrieved octets of the Client ID Metadata Document evaluated during software statement issuance¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 3¶

Claim Name:

statement_uses¶

Claim Description:

Permitted uses of a software statement¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 3¶

15.4. OAuth Extensions Error Registry

This specification requests registration of the following error code in the IANA "OAuth Extensions Error Registry" established by [RFC6749]:¶

Error Name:

statement_required¶

Error Usage Location:

authorization error response, token error response, pushed authorization request error response¶

Related Protocol Extension:

Client ID Metadata Document Software Statement¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 6¶

This specification also requests that IANA update the existing temporarily_unavailable entry, adding the token error response and the pushed authorization request error response to its usage locations and this specification as a reference:¶

Error Name:

temporarily_unavailable¶

Error Usage Location:

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

Related Protocol Extension:

OAuth 2.0 Authorization Framework¶

Change Controller:

IETF¶

Specification Document(s):

[RFC6749], this specification (Section 6)¶

15.5. OAuth Dynamic Client Registration Metadata Registry

This specification requests registration of the following value in the IANA "OAuth Dynamic Client Registration Metadata" registry established by [RFC7591]. A client publishes this member in its CIMD:¶

Client Metadata Name:

software_statements_uri¶

Client Metadata Description:

URL, in a Client ID Metadata Document, at which the client publishes software statements about itself for an authorization server to retrieve. It is not meaningful in a registration request.¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 5.5¶

15.6. OAuth Authorization Server Metadata Registry

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

Metadata Name:

software_statement_jwks_uri¶

Metadata Description:

URL of the JWK Set containing only the keys with which the authorization server signs software statements.¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 8¶

Metadata Name:

software_statement_signing_alg_values_supported¶

Metadata Description:

JSON array containing the asymmetric JWS algorithms supported by the authorization server for signing software statements.¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 8¶

Metadata Name:

software_statement_pull_supported¶

Metadata Description:

Boolean value indicating whether the authorization server retrieves software statements from a client's software_statements_uri.¶

Change Controller:

IETF¶

Specification Document(s):

This specification, Section 8¶

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

[IDJAG]

Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz-grant-06, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-06>.

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

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC6585]

Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, <https://www.rfc-editor.org/rfc/rfc6585>.

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

[RFC6761]

Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/rfc/rfc6761>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

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

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

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

[RFC8252]

Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, <https://www.rfc-editor.org/rfc/rfc8252>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

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

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

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

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

16.2. Informative References

[ABCA]

Looker, T., Bastian, P., and C. Bormann, "OAuth 2.0 Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-attestation-based-client-auth-12, 12 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-12>.

[OPENID-FED]

Hedberg, R., Ed., Jones, M. B., Solberg, A. Å., Bradley, J., De Marco, G., and V. Dzhuvinov, "OpenID Federation 1.0", 17 February 2026, <https://openid.net/specs/openid-federation-1_0.html>.

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

[RFC7522]

Campbell, B., Mortimore, C., and M. Jones, "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7522, DOI 10.17487/RFC7522, May 2015, <https://www.rfc-editor.org/rfc/rfc7522>.

[RFC7523]

Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <https://www.rfc-editor.org/rfc/rfc7523>.

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

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/rfc/rfc8705>.

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