OAuth 2.0 Software Statement Consumption and Runtime Presentation

1.1. Protocol Overview

The following non-normative sequences summarize the two models.¶

Registration governed by a statement (DCR profile):¶

1. The client registers through [RFC7591], carrying a DCR-profile statement in the software_statement member; the statement binds to the registration by software_id and, when attested, software_version ([ISSUANCE]).¶

2. The authorization server records the statement's identity and exp with the registration; the registration is valid until that expiry.¶

3. The client delivers a replacement statement in an authenticated token request or, where supported, an [RFC7592] update request; the registration's validity extends to the replacement's exp.¶

4. If no replacement arrives, the registration expires and requests under it fail. This does not revoke tokens already issued or determine the disposition of outstanding grants.¶

Runtime presentation (CIMD profile):¶

1. The client includes the software_statement parameter in a token request, or in a pushed authorization request for a redirect flow, with its Client ID Metadata Document URL as client_id.¶

2. The authorization server validates the statement (Section 3.3), verifies the sender-constraint chain (Section 5.3), and derives the client's effective metadata for the request (Section 5.4).¶

3. The request proceeds under the effective metadata. No persistent registration is created.¶

4. The state the rest of the grant depends on persists as an establishment (Section 5.5).¶

1.2. Relationship to Client Attestation

This section is non-normative.¶

A software statement is an attestation. It is a signed assertion by a third party about a client, accepted by an authorization server that has configured trust in the signer, and it is no more than that: an attributable claim bounded by the signer's process, not proof that what it says is true ([ISSUANCE]). It differs from the client attestation of [ABCA] and the client instance assertion of [CLIENT-INSTANCE] in subject, authority, lifetime, and effect, not in kind.¶

Subject:

A software statement attests client software and the metadata a reviewer evaluated. A client attestation attests a running instance and the key it holds.¶

Authority:

A software statement is signed by a review authority whose scope is a set of client identifiers. A client attestation is signed by a client attester whose scope is a deployment of the software; the two are configured independently by the authorization server.¶

Lifetime and audience:

A software statement carries an audience and an expiry the reviewer chose, and the same statement is consumed at every server in that audience. A client attestation is short-lived and bound to the request it accompanies.¶

Effect:

A software statement supplies establishment: which client this is, and what metadata a named reviewer stands behind. A client attestation supplies presenter proof: that the party sending this request holds a key someone vouches for. Neither grants access, and neither substitutes for the other.¶

The two therefore compose. A deployment holding only a client attestation knows what is running but not whether anyone approved it; a deployment holding only a software statement knows the software was reviewed but not that this sender is running it. Runtime presentation always requires both halves: the statement carries the review, and a proof carries the presenter, supplied either by a key the statement itself attests or, where it attests none, by a client attestation or instance assertion (Section 5.3).¶

This specification defines no new attestation format and no new attester role. It defines how a review attestation is consumed, and how a presenter attestation defined elsewhere is bound to it.¶

3.1. Common Elements

Both profiles require the following, in addition to the typ header value software-statement+jwt, whose explicit typing prevents confusion with other JWTs from the same issuer:¶

iss:

REQUIRED. Identifies the issuer for trust, claim-authority, and scope decisions, and forms part of the statement identity recorded with a registration or establishment.¶

aud:

REQUIRED. Scopes which authorization servers may accept the statement; without it a statement would be usable at every server that trusts the issuer.¶

iat:

REQUIRED. The issuance time.¶

exp:

REQUIRED. The expiry the issuer chose. Under the DCR profile it bounds registration validity (Section 4.1); under the CIMD profile it is checked at every presentation and at the validity points of Section 5.5. The effect on registrations, establishments, grants, and tokens is bounded as Section 11.6 describes.¶

jti:

REQUIRED. Identifies the statement within the issuer's namespace; inventory and concurrency bounds can key on the iss and jti pair. A replacement statement has its own jti, so replacement matching does not key on this value.¶

3.2. DCR Profile

For client software registered through [RFC7591] and identified by software_id:¶

sub:

REQUIRED. The software's [RFC7591] software_id. The statement binds to a registration request by the identifier rules of [ISSUANCE]: a request whose software_id differs from sub is rejected.¶

software_version:

OPTIONAL. The version the review covered; when attested, a request whose software_version differs is rejected ([ISSUANCE]), and a new version requires re-issuance (Section 4.3).¶

cimd_digest:

MUST be absent; its absence is what marks this profile. Attested metadata is inline only, and the statement's own claims carry the entire reviewed content.¶

A DCR-profile statement is consumed at registration and renewal (Section 4). It cannot be presented at runtime because the runtime rules depend on the Client ID Metadata Document named by a CIMD-profile subject.¶

3.3. CIMD Profile

For a client identified by a Client ID Metadata Document URL, each element is consumed by a specific runtime mechanism, and a statement lacking any of them cannot be presented:¶

sub:

REQUIRED. The client's Client ID Metadata Document URL; the request's client_id equals it, by the rule of Section 5.1.¶

cimd_digest:

REQUIRED. Binds the issuer's review to the exact document bytes evaluated and feeds the post-issuance change policy of [ISSUANCE].¶

A CIMD-profile statement is presented at runtime (Section 5.1), and also serves a registered client whose client_id is its CIMD URL (Section 5.6). A statement failing this profile is rejected as Section 7 defines for an invalid statement.¶

4.1. Registration Validity

An authorization server that advertises software_statement_registration_validity_supported as true MUST apply this model to every registration it creates from a validated software statement. It MUST record the governing statement's iss, jti, sub, iat, and exp with the registration. The registration is valid until that exp. After it passes without a replacement (Section 4.2), the authorization server MUST reject requests under the registration, using invalid_client at the token endpoint and, at the authorization or pushed authorization request endpoint, the error [RFC6749] defines for an unauthorized client, except for the revalidation requests Section 4.2 permits. The server SHOULD retain the expired record so that it can process a later authenticated revalidation, and MAY allow a grace period during which it accepts a replacement without treating the registration as expired. An expired registration is not an unknown client: the difference is observable to a client that authenticates, which is what makes recovery possible (Section 11.8). Registration expiry does not revoke tokens already issued; the disposition of outstanding grants is local policy.¶

The metadata signal in Section 9 lets a client determine before registration whether this model applies. The client already holds the statement and therefore learns the initial validity boundary from its exp. A server that omits the signal or advertises false can still consume a statement as ordinary [RFC7591] registration input, but it MUST NOT claim conformance to this registration-validity model.¶

4.2. Revalidation

The client renews a statement-governed registration by delivering a replacement statement, in any of these ways:¶

• in the software_statement parameter of a token request under the registration, authenticated as the registered client under the registration's own method;¶

• in the software_statement parameter of an authenticated pushed authorization request [RFC9126] under the registration, which is the renewal path available to a client that holds no refresh token and whose only grant type is the authorization code; or¶

• in the software_statement member of an authenticated [RFC7592] update request, where the deployment offers registration management. Such a request replaces the registration's metadata in full, as [RFC7592] requires, so the client sends its complete current metadata alongside the statement; a renewal-only request omitting other members would reset them.¶

The replacement MUST validate under [ISSUANCE] with this server in its audience, MUST have the governing statement's iss and sub, MUST be unexpired, and MUST have an iat no earlier than the recorded statement's iat. Recency rather than a longer lifetime is the ordering rule, so an issuer downgrading a review can deliver a deliberately short-lived narrowed replacement, while a client cannot roll back to an older, broader statement it still holds. On success the authorization server MUST replace the recorded statement identity, iat, and exp in a single atomic update; concurrent deliveries resolve to the most recently issued statement. Whether attested changes in the replacement update the registration record is local registration policy, and a server that relies on narrowing to take effect applies them.¶

When an expired registration sends a request containing a replacement, the authorization server MUST authenticate the retained registration and evaluate the replacement before applying the expiry rejection. A valid replacement therefore restores the registration; an omitted or invalid replacement does not.¶

A request under an expired registration that does not restore it is rejected with invalid_client, at every endpoint, including the refresh-token grant. The rejection reports the registration's state, not a defect in the grant, so it does not indicate refresh-token replay and MUST NOT by itself trigger the refresh-token family revocation of [RFC9700]; a client recovers by delivering a valid replacement.¶

A delivery that fails the rules above under a still-valid registration leaves the recorded statement unchanged and does not fail the request it accompanies; the authorization server SHOULD signal the declined renewal in error_description on a subsequent rejection or through its registration management interface, and the client can distinguish success by the registration's continued validity past the recorded exp. A registration request without an [RFC7592] registration access token creates a new registration and never renews an existing one.¶

4.3. Version Changes

A review covers the software the issuer evaluated, and software_version is the DCR profile's change signal: its value changes on any update to the software. When the statement attests it, the binding rules of [ISSUANCE] reject a registration request whose software_version differs. A replacement delivered outside a registration request carries no such member, so the authorization server MUST instead compare the replacement's attested software_version with the value recorded for the registration: a replacement attesting a different version is a version change, not a renewal, and the authorization server rejects it unless its registration policy accepts the new version and updates the record. A new version therefore requires a new review and a statement covering it. A version string is a vendor-asserted label, not a byte binding; the guarantee is review-of-what-the-vendor-calls-that-version.¶

The CIMD profile's change signal is cimd_digest, which is byte-exact: a mismatch against the currently published document is a policy input under [ISSUANCE], and re-issuance against the new document is the remedy. In both profiles the statement's bounded lifetime caps how stale a review can get: drift the change signal misses still expires with the statement.¶

5.1. 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 presentation. The software statement (Section 3.3).¶

The request's client_id is the client's Client ID Metadata Document URL. It MUST exactly equal the statement's sub; the authorization server MUST reject a presentation where they differ. The effective client_id is the statement's sub, and the authorization server assigns none.¶

The request MUST also carry the proof inputs required by the accepted sender-constraint mode: client authentication parameters, a DPoP proof, the fields defined by [ABCA], or a Client Instance Assertion as permitted by [CLIENT-INSTANCE]. A successful presentation establishes the client for the request and for the grant state derived from it (Section 5.5).¶

At the token endpoint, a runtime presentation is valid only on a request that can open a new grant or directly issue access under a grant not already bound to an establishment. Authorization-code redemption and refresh-token use continue an existing grant and follow Section 5.5 and Section 5.5.1 instead. A request that initiates issuance under [ISSUANCE] MUST NOT carry the software_statement parameter; the authorization server rejects the combination with invalid_request. Such a request is recognized before validation by its issuance signals: response_type=software_statement_code at the authorization endpoint, and the software statement requested_token_type at the token endpoint ([ISSUANCE]). A request that carries the parameter and is none of a runtime presentation, a refresh replacement (Section 5.5.1), a revalidation delivery (Section 4.2), or a registered-client delivery (Section 5.6) is rejected with invalid_request.¶

An authorization server advertises support through software_statement_presentation_supported (Section 9).¶

5.2. Presentation Processing

On receiving a presentation, the authorization server proceeds as follows, rejecting as Section 7 defines at the first failure:¶

1. Validate the statement under [ISSUANCE]: format, issuer trust, audience, lifetime, and namespace, with digest comparison as the policy input defined there. Complete all validation that does not require a client-controlled network retrieval before performing such a retrieval.¶

2. Verify the profile of Section 3.3 and the client_id rule of Section 5.1.¶

3. Verify the sender-constraint chain (Section 5.3).¶

4. Derive the effective metadata and evaluate the request against it (Section 5.4).¶

5. On success, create the establishment (Section 5.5).¶

5.3. Sender Constraint

A runtime presentation MUST be sender-constrained, and the constraint MUST chain to the statement. The presenter proves possession of the Proven Key through the applicable client authentication method, a DPoP proof [RFC9449], or a proof-of-possession mechanism defined by [ABCA] or [CLIENT-INSTANCE]. The proof MUST be bound to the current request and validated with the replay protections of that mechanism. The authorization server accepts exactly one of the following modes:¶

Mode selection is determined by what the statement contains, not by local authority configuration. When the statement attests jwks or jwks_uri, only the Directly Attested Key mode is available at every server in the statement's audience. A server that does not treat the issuer as authoritative for that member MUST reject the presentation rather than allow an endorsement mode; attested key material never demotes to client-asserted for the purpose of this section, because demotion would let a presenter select a weaker proof at the weakest server in the audience.¶

Directly Attested Key:

The Proven Key MUST appear in the key set the statement attests through jwks or jwks_uri. When effective metadata specifies a client authentication method, the presenter MUST use that method, and where the grant type requires client authentication, a DPoP proof does not satisfy that requirement ([RFC9449]). A DPoP proof by itself is sufficient only when its key is directly attested, the effective metadata requires no other authentication method, and the grant type does not require client authentication.¶

Locally Trusted Client Attestation:

This mode is available only when the statement attests no key material. The authorization server MUST validate the client attestation and its proof according to [ABCA]. The attestation subject MUST exactly equal the statement's sub, its confirmation claim MUST identify the Proven Key, and the client attester MUST be trusted for that exact subject or its configured namespace.¶

Attested Instance Issuer:

This mode is available only when the statement attests no key material and attests instance_issuers, and only where the server treats the issuer as authoritative for that member. At the token endpoint, the request MAY carry a Client Instance Assertion as specified by [CLIENT-INSTANCE]. The authorization server MUST validate it against an attested issuer descriptor, MUST verify that the assertion's subject identifies the software the statement describes, its sub, and the assertion's sender key is the Proven Key. An assertion from an attested issuer for a different subject, such as another workload in the same environment, MUST NOT satisfy this mode. This specification does not define this mode at the pushed authorization request endpoint because [CLIENT-INSTANCE] does not define its wire parameters there.¶

Each mode is gated by the authority behind it: the endorsement modes require the server to treat the issuer as authoritative for the member they rely on ([ISSUANCE]), and attester trust counts only within its configured sub scope. The authorization server MUST reject a presentation without such a proof, or whose Proven Key no accepted mode covers.¶

A statement that attests neither key material nor an instance-key delegation, presented at a server whose attester trust does not cover its sub, cannot satisfy this section and is consumable only through registration.¶

Verifying a key at the attested jwks_uri is a retrieval at presentation time. A fetch failure leaves the chain unverified, and the presentation is rejected as invalid_client; the server MUST NOT fall back to a weaker mode. A server MAY reuse a recently retrieved key set within ordinary HTTP caching bounds, subject to a maximum reuse period of its own choosing; it MUST NOT let the client's cache directives alone determine how long a removed key continues to verify (Section 11.5).¶

5.4. Effective Metadata

Having validated the statement and its proof, the authorization server derives the client's effective metadata for the request:¶

• An attested member for which the server treats the issuer as authoritative ([ISSUANCE]) has the value the statement gives it, with the precedence [RFC7591] defines.¶

• An attested member outside that set does not take attested precedence; per the policy rule of [ISSUANCE], the server ignores it or treats it as client-asserted.¶

• A member the statement does not attest takes its value from the client's current Client ID Metadata Document, the document at the statement's sub, or from a default defined by [RFC7591] where that default is compatible with [CIMD] and this runtime model. Such a member is client-asserted metadata, not part of the review. The authorization server MUST resolve that document when the request depends on an unattested member. In particular, a shared-secret authentication method cannot be inferred because no client secret is assigned by presentation and [CIMD] does not support shared-secret client authentication.¶

The effective metadata is therefore attested member by member, not wholesale. The authorization server MAY require specific members, notably the redirection URIs of a redirect flow, to be attested, rejecting a presentation whose statement omits them.¶

The request is evaluated against the effective metadata: a redirect_uri MUST match an effective redirection URI, and any requested grant type, response type, or scope MUST fall within the effective metadata. A grant or response type supported by the authorization server but not authorized by the effective metadata fails with unauthorized_client; a scope outside the effective metadata fails with invalid_scope.¶

A trusting authorization server SHOULD use the statement's sub, iss, and jti to inventory the establishments derived from one statement and MAY bound their concurrent number. A presentation refused because that bound is reached is rejected with invalid_client; the statement and its proof are sound, so the authorization server SHOULD say so in error_description, and the client can retry once earlier establishments are released.¶

5.5. Grant Lifecycle

A successful presentation creates an establishment comprising:¶

• the validated sub;¶

• the statement identity, its iss and jti, and its expiry;¶

• the effective metadata (Section 5.4);¶

• the issuer trust decision; and¶

• the sender-constraint mechanism and Proven Key.¶

The establishment persists for as long as the grant depends on it: it is created by the presentation, referenced by the grant continuation state bound to it, and MAY be discarded once no request_uri, authorization code, refresh token, or other continuation state references it. Discarding an establishment ends nothing the grant still holds; it is the removal of state no longer reachable. The authorization server MUST bind the resulting request_uri, authorization code, refresh token, and other grant continuation state to the establishment as applicable. A token request that redeems an authorization code MUST have a client_id exactly equal to the establishment's sub, MUST demonstrate possession of the same Proven Key under the same sender-constraint mechanism, and MUST NOT carry the software_statement parameter. A redemption carrying a statement is rejected with invalid_request; a wrong client identifier or failed key binding is rejected with invalid_grant. This prohibition covers redemption of a code bound to an establishment; a registered client redeeming its own code may deliver a replacement statement under Section 4.2, which is a delivery rather than a presentation.¶

A statement MUST be unexpired when presented. Expiry after presentation does not by itself invalidate an establishment already bound. The authorization server controls continued use through its grant and refresh-token policy; Section 5.5.1 defines how it can require a current replacement statement.¶

5.6. Registered CIMD Clients

A client can be registered at an authorization server under its Client ID Metadata Document URL as its client_id. Where such a registration exists, a statement-carrying request from that client is a delivery, never a runtime presentation: the registration record governs the request, and the delivered statement renews validity under Section 4.1 without supplying effective metadata for it. Runtime presentation establishes clients the server does not have; it does not reopen metadata for a client it does. A server that wishes attested changes to reach the registration applies them through its registration policy (Section 4.2) or through [RFC7592], where a narrower record survives until it does.¶

A registration created from a CIMD-profile statement is statement-governed when the server advertises software_statement_registration_validity_supported. The validity and revalidation model of Section 4.1 and Section 4.2 applies, with the delivered statement's sub equal to the registered client_id and validated under the CIMD profile. The request authenticates as the registered client under the registration's own method; the delivered statement renews validity and does not otherwise alter the registration. A refresh-token request that omits a statement this policy requires, or delivers one failing these rules, is rejected with invalid_grant; any other token request failing the currency requirement is rejected with invalid_client.¶

8.1. Revalidating a Statement-Governed Registration

A registered client, client_id s6BhdRkqt3, renews its registration's validity by delivering a replacement DCR-profile statement on an ordinary refresh, authenticated under its registered method:¶

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

grant_type=refresh_token
&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&software_statement=eyJ0eXAiOiJzb2Z0d2FyZS1zdGF0ZW1l...

The authorization server validates the replacement, matches its iss and sub to the registration's governing statement, and atomically extends the registration's validity to the replacement's exp. Had the request arrived after expiry without a replacement, it would have failed with invalid_client (Section 4.2).¶

8.2. Presenting at the Token Endpoint

The following presents an already-issued CIMD-profile statement at the token endpoint, sender-constrained by a client attestation [ABCA]. The OAuth-Client-Attestation header carries an attestation of the instance key from a client attester the server trusts for the statement's sub, with that sub as its subject; the OAuth-Client-Attestation-PoP header proves that key; the software_statement parameter carries the issuer's review; and client_id is the Client ID Metadata Document URL named by the statement's sub. No client record exists at this server.¶

POST /token HTTP/1.1
Host: as.example
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWNsaWVu...
OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWNs...

grant_type=client_credentials
&scope=tools.read
&client_id=https%3A%2F%2Fclient.example%2Fapp
&software_statement=eyJ0eXAiOiJzb2Z0d2FyZS1zdGF0ZW1l...

The authorization server validates the statement, verifies that its trust in the attester covers the statement's sub, that the attestation's subject is that sub, and that the proof-of-possession header proves the attested instance key, and applies the effective metadata to the request: the requested scope falls within it, and the request authenticates as the client the statement describes. It keeps no registration; the effective client_id is the statement's sub. Here [ABCA] supplies the sender constraint while the parameter carries the statement, distinct from a profile that carries the statement within the attestation itself (Section 10).¶

11.1. Statement Theft

A runtime presentation resists statement theft because the proof chains to the statement. Possession of an arbitrary key constrains only the request; the chain to the statement makes possession of a stolen statement insufficient unless the attacker also controls a key covered by a mode the authorization server accepts. The registration path cannot offer this property. A DCR-profile statement is a reusable bearer artifact until it expires, so [ISSUANCE] relies on narrow audience and lifetime plus local limits on registrations derived from one statement.¶

Selecting the mode by what the statement contains prevents downgrade across the audience: when key material is attested, every server in the audience either binds the presenter to that key or rejects the presentation, so a presenter cannot shop the statement to whichever server treats the member as non-authoritative and there obtain an endorsement mode. The authority gates of Section 5.3 serve the same end for the endorsement modes: an issuer trusted for other metadata, or an attester trusted for other subjects, does not authorize runtime keys, and an assertion for a different subject does not satisfy the instance-issuer mode.¶

11.2. Renewal Authenticates the Credential

Registration renewal proves possession of the registration's own credential and the currency of a statement sharing the governing iss and sub. It does not prove that the renewing party is the reviewed software: an attacker holding a stolen client credential can renew indefinitely with any current statement for that software, which circulates by design to every deployment of it. Renewal keeps the review current, not the credential honest. Deployments SHOULD pair statement-governed registrations with credential rotation, sender-constrained client authentication, and the registration limits [ISSUANCE] recommends, and SHOULD treat a credential compromise as requiring re-registration rather than renewal. The runtime profile does not share this gap, because the sender-constraint chain binds the presenter to the review at every presentation.¶

11.3. Validation Scope

A consumed statement is validated under the full ruleset of [ISSUANCE]: configured issuer trust with keys obtained from authorization server metadata and never from the statement, audience and lifetime checks, and identifier-scope authorization for the sub; digest comparison remains the policy input [ISSUANCE] defines. Nothing in this specification relaxes those rules; it adds the sender-constraint chain, the grant bindings of Section 5.5, and the registration-validity model on top of them.¶

11.4. Key Location versus Keys

The jwks_uri chain verifies keys at an attested location, not attested keys: cimd_digest binds the metadata document's bytes and never the key set served at the URI, so compromise of the client's key host adds keys that satisfy the chain with no digest signal. Deployments for which that exposure is unacceptable prefer statements that attest jwks inline, at the cost of digest-visible rotation, or pin observed keys and alert on change. A server reusing a cached key set under Section 5.3 additionally accepts that a just-removed key can briefly continue to verify.¶

11.5. External Retrieval and Resource Exhaustion

Runtime presentation can cause the authorization server to retrieve the Client ID Metadata Document, an attested jwks_uri, or keys and metadata associated with an attested instance issuer. Every such retrieval inherits the server-side request forgery protections of [CIMD]. 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.¶

Presentation reaches these retrievals before any client is registered or any user has interacted, so the work is available to an unauthenticated requester holding one acceptable statement. An authorization server SHOULD rate-limit presentations per statement identity, per subject, and per source, and SHOULD bound the establishments it will create from one statement (Section 5.4), before spending retrieval or storage on a new presentation. Before initiating a client-controlled retrieval, the authorization server MUST complete the statement checks that do not depend on that retrieval, including signature, issuer, audience, lifetime, subject, and claim-contract validation. It SHOULD bound JWT size and parsing work, concurrent retrievals, response size, and response time, and SHOULD cache successful and failed retrieval results for an appropriate period. A retrieval failure leaves the relevant metadata or proof chain unverified; the authorization server MUST reject the request and MUST NOT fall back to a weaker sender-constraint mode.¶

11.6. Enforcement Bounds

Expiry is enforced at every presentation and every statement-governed registration, so a lapsed statement stops new runtime establishment and causes registration-backed requests to fail at the recorded exp. It does not retroactively invalidate an establishment, revoke an access token, or terminate an outstanding grant. Requiring a current statement on refresh under Section 5.5.1 is the control that makes issuer non-renewal end runtime-established grants, and a deployment that does not adopt it retains grants for the life of their refresh tokens whatever the statement lifetime; registration-backed grants remain subject to the server's grant policy after the registration expires. A narrowed re-review takes effect through replacement effective metadata or an updated registration. Detection of post-issuance metadata change depends on the signal each profile carries: software_version is a vendor-asserted label, while cimd_digest covers exact bytes but requires retrieval for comparison. The bounded statement lifetime limits what either signal can miss for new establishment.¶

Renewal cadence is a deployment trade: short lifetimes tighten the issuer's control loop and increase issuance and delivery traffic, and a fleet of registrations issued together expires together, so issuers SHOULD stagger expiries or renew ahead of the boundary to avoid synchronized lapses.¶

11.7. Client-Asserted Metadata

Members the statement does not attest are client-asserted, and omission can mean the issuer declined to attest a value. The attested-members-required policy of Section 5.4 is the control for deployments that do not want client-asserted values, notably redirection URIs, entering effective metadata. Resolving a Client ID Metadata Document for unattested members inherits the resolution considerations of [CIMD], including server-side request forgery and availability; a server MAY cache resolution results within the document's caching directives, and the statement's digest binds the review to specific bytes regardless of cache state.¶

11.8. Observable State

A retained expired registration is distinguishable from an unknown client, because recovery requires the server to authenticate the registration and evaluate a replacement before rejecting. That disclosure is deliberate and bounded: it is available only to a requester that authenticates as the registration, so it reveals to the legitimate client the state it must act on. Servers publishing software_statement_registration_validity_supported additionally disclose that statement-derived registrations expire there, which is configuration a client needs before registering. Neither discloses issuer trust, subject scope, or attester policy, which Section 7 keeps from unauthenticated requesters.¶

11.9. Statement Handling

A software statement remains a sensitive artifact in transit and at rest: possession alone does not enable presentation, but statements reveal attested metadata and audience relationships, and servers SHOULD avoid logging them.¶

Error responses can also disclose trust configuration. The restrictions in Section 7 prevent unauthenticated probing of issuer, namespace, and attester policy.¶

13.1. OAuth Parameters Registry

This specification requests registration of the software_statement parameter in the IANA "OAuth Parameters" registry established by [RFC6749], for runtime presentation and statement delivery of the artifact defined by [RFC7591]:¶

The OAuth Dynamic Client Registration Metadata registry already contains a metadata member with the same name. That entry is in a different registry and is unaffected by this registration.¶

Parameter Name:

software_statement¶

Parameter Usage Location:

authorization request, token request¶

Note:

In an authorization request the parameter is conveyed only through the pushed authorization request endpoint [RFC9126], never in a front-channel URL (Section 5.1.1).¶

Change Controller:

IESG¶

Specification Document(s):

This specification, Section 5.1¶

13.2. 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_presentation_supported¶

Metadata Description:

Boolean value indicating whether the authorization server accepts a software statement presented at runtime in an authorization or token request.¶

Change Controller:

IESG¶

Specification Document(s):

This specification, Section 9¶

Metadata Name:

software_statement_registration_validity_supported¶

Metadata Description:

Boolean value indicating whether registrations created from validated software statements are governed by the statement validity and revalidation rules of this specification.¶

Change Controller:

IESG¶

Specification Document(s):

This specification, Section 9¶