]> Independent

public@karlmcguinness.com

Security Web Authorization Protocol OAuth Software Statement Dynamic Client Registration Client ID Metadata Document Runtime Presentation Sender Constraint This specification defines a software statement in which a trusted party records its review of the exact octets of a client's Client ID Metadata Document (CIMD), and how an authorization server enforces that review when it admits the client at request time, without a registration. A CIMD carries the client's own metadata, which can change at any time, and a statement binds the review to one version of the document by its digest. The client presents the statement in a token or pushed authorization request, or publishes it where its document points. The authorization server accepts a statement only from an issuer it trusts, and also binds the presenter to the reviewed document, although for a public client that binding does not hold against a party that controls the user agent. Independently operated authorization servers can consume the same review, each under its own trust configuration and admission policy.

Introduction A Client ID Metadata Document (CIMD) lets a client publish its metadata and identify itself by the document's URL without prior registration. Section 4.3 of permits software statements as an independent signal, but defines no profile binding a review to a particular document version or specifying how that review governs admission. This specification supplies that profile using the software statement of Section 2.3 of . A statement names the client by its document URL and binds the review to the document's exact octets by a digest (). Independently operated authorization servers can enforce the same review at request time without creating registrations (). Each server chooses which issuers to trust and for which clients and tenants (). A portable review does not imply universal acceptance. This specification serves deployments in which a party other than the client decides which software can connect. For example, a marketplace or registry can vouch for software at authorization servers it does not operate, and an enterprise can approve a hosted client for use at services run by other operators. Allowlisting its CIMD URL identifies the client but does not record which metadata was reviewed. The document can change while the URL stays the same. The statement carries that review across operators. This specification also serves server-hosted software, such as an agent using client_credentials. Admission grants no access to resources: the authorization server's policy, and the resource owner's authorization where a grant involves one, still govern what it issues. A statement records approval of a client configuration, not of the software's code or behavior (). Possession of a statement admits nothing by itself. The authorization server binds the presenter to the reviewed document (), although for a public client that binding does not hold against a party that controls the user agent (). A statement for a native application with a redirection URI another application on the same device could claim is review-only: it counts for nothing in admission (). Under this specification, an authorization server checks a statement only when a grant is opened. A statement's expiry ends no grant already opened, and an earlier statement that has not expired remains acceptable after a later one is issued (). Withdrawal and supersession of statements, and refresh rules that follow later reviews, are left to extensions (). This specification does not define how a client obtains a statement, or how an authorization server consumes one in an registration request. relates this specification to other work.

Protocol Overview The following non-normative sequence summarizes runtime admission ():

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 ().
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 (). 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 ().
3. The authorization server verifies the statement's signature and claims against its trust configuration for the issuer (, ), retrieves the document, and compares the document's digest with the statement's ().
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 (). A request whose presenter cannot be bound is rejected, except in the cases 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 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 ().

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This specification uses terminology from (OAuth), (client metadata and software statements), and (Client ID Metadata Documents). This specification defines the following terms.

Trusting Authorization Server:

An authorization server that consumes a software statement of this profile.

Runtime Presentation:

The consumption of a validated software statement presented in a token request or pushed authorization request, or pulled from where the client's document points (), without creating a client registration.

Admission:

A trusting authorization server's acceptance of a client for a request, either on a valid statement (), after which the reviewed metadata governs its requests, or under the server's policy for CIMD clients it has not reviewed.

Establishment:

The state a successful runtime presentation creates for the grant it opens, enumerated in .

Proven Key:

The key an establishment is bound to: the key whose possession the presenter proves during runtime presentation (), the key it binds under , or, for a statement pulled at the authorization endpoint, the key proved at code redemption ().

Permitted Method:

A token endpoint authentication method that a CIMD lists in its token_endpoint_auth_methods_supported member or, if the document has no such member, declares in its token_endpoint_auth_method member. A document with neither member permits only none (Section 5 of ).

Selected Method:

The permitted method an establishment records (): the method with which a confidential client's presenter authenticates, at code redemption for a statement pulled at the authorization endpoint (), or none for a public client.

Effective Expiry:

The earlier of a statement's exp and its iat plus the maximum statement lifetime the trusting authorization server honors for its issuer (). A statement is expired once its effective expiry has passed.

Required Issuer:

An issuer whose current statement a trusting authorization server requires in one of its tenants for software in configured client identifier namespaces ().

Current Statement:

A statement whose effective expiry has not passed and that no extension the server implements has ended. A current statement need not be the most recently issued one: an earlier statement for the same software remains current after a later one is issued ().

Review-Only:

Describes a presentation, or a pulled statement, that the authorization server evaluates but whose statement counts for nothing in admission ().

Tenant:

A partition of an authorization server's configuration and issued tokens, such as one customer's. says how the authorization server determines a request's tenant.

The Software Statement The software statement is a compact JWT protected by JWS . Although permits a MAC, a statement issued under this specification MUST use an asymmetric digital signature, and the none algorithm and symmetric algorithms MUST NOT be used. Issuers and trusting authorization servers follow . The JOSE header MUST include the kid header parameter, identifying the signing key in the issuer's statement key set (), and the typ header parameter with the value software-statement+jwt (Section 3.11 of ). An incompatible revision would use a new typ value. A statement asserts that its issuer evaluated the CIMD whose content the digest identifies, and vouches for that document. The JWT payload contains the following claims.

iss:

REQUIRED. The issuer's identifier, a URL using the https scheme with no query or fragment component. For an issuer that is an authorization server, it is its issuer identifier as defined by .

sub:

REQUIRED. The exact client identifier URL of the CIMD the issuer reviewed.

aud:

OPTIONAL. One or more authorization server issuer identifiers () restricting which authorization servers can accept the statement. If the claim is absent, any authorization server that trusts the issuer for the subject can accept it ().

aud_tenant:

OPTIONAL. A tenant identifier at a trusting authorization server, as defines the claim, naming the tenant in which the statement's decision applies. A statement whose decision is confined to one of a server's tenants MUST carry an aud claim naming exactly one authorization server. It MUST also carry an aud_tenant claim naming the tenant, unless the issuer and that server have agreed that the server's trust configuration confines the issuer to the tenant (). The absence of aud_tenant does not mean that the statement applies in every tenant ().

statement_uses:

OPTIONAL. A JSON array identifying the permitted uses of the statement: registration () and presentation (). If the claim is absent, only presentation is permitted. A server ignores a value it does not recognize, and an empty array permits no use. A pulled statement () is a presentation use.

iat:

REQUIRED. A NumericDate value, which MUST be an integer, giving the time the statement was issued. An issuer MUST ensure that the iat claim values of its statements for a given iss and sub increase strictly, which the selection of a pulled statement () and extensions rely on.

exp:

REQUIRED. A NumericDate value, which MUST be an integer, giving the expiration time.

jti:

REQUIRED. A unique identifier for the statement within the issuer's namespace.

cimd_digest:

REQUIRED. The metadata digest () of the CIMD the issuer evaluated.

Profiles and extensions can define further claims. A statement issued under this specification MUST NOT contain a claim named in the IANA "OAuth Dynamic Client Registration Metadata" registry, and a trusting authorization server MUST NOT take client metadata from a statement's claims. A CIMD can carry a software_statement member (Section 4.3 of ). A trusting authorization server MUST NOT consume a statement of this profile from that member, and MUST NOT treat that member as satisfying any requirement of this specification. A statement inside the document could not name the document's digest, because it would be part of the octets it digests, so this specification carries statements in requests () or at a separate location (). Statements of other kinds in the member are out of scope for this specification. An authorization server implementing this specification MUST reject a statement of this profile in an registration request with the unapproved_software_statement error code (Section 3.2.2 of ), unless an extension it implements defines consumption of the statement at registration (). explains why.

Metadata Digest The metadata digest is the SHA-256 hash of the retrieved representation body after removal of content coding, base64url-encoded without padding (Section 2 of ). The body is not transcoded, normalized, or re-serialized. Any byte order mark or trailing newline is included. Retrieval for digest purposes follows and MUST NOT use content negotiation: the retrieving party sends Accept: application/json (Section 6 of ) 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 ). Otherwise, the server retrieves the body again.

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 requires.
• Every required claim of 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 ).
• 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 ().
• 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 ().
• 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 ().
• The sub claim is a client identifier URL conforming to and falls within the client identifier namespaces for which this server accepts the issuer ().
• Any claim the server does not recognize, and any client metadata claim (), is ignored.
• The JWT validation guidance in 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 (), 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 .

Issuer Trust A trusting authorization server MUST derive issuer trust from its trust configuration, which is established out of band, and MUST NOT derive it from an iss, jku, x5u, or other key-location value carried in a statement. This specification defines no in-band issuer discovery or trust decision. For each trusted issuer, the configuration records at least the following:

• The exact iss value the server accepts.
• The signing algorithms it accepts from the issuer.
• The client identifier namespaces the issuer can attest through sub.
• The authorization server issuer identifiers the issuer can name in aud.
• Any tenant to which the server confines the issuer's decisions.
• The maximum statement lifetime the server honors, which sets each statement's effective expiry.

A client identifier namespace is an https URL with no query or fragment whose path ends in /, such as https://client.example/ or https://client.example/apps/. A client identifier URL falls within a namespace if the namespace is a prefix of it under simple string comparison (Section 6.2.1 of ). The issuer's statement key set is the JWK Set at the software_statement_jwks_uri in its authorization server metadata (), discovered from the configured iss (). For an issuer that is not an authorization server, it is the JWK Set at a statement key set URL in the configuration. It is never the JWK Set at a jwks_uri metadata value. Its URL MUST use the https scheme, and a trusting authorization server MUST validate the certificate of the host serving it. The issuer MUST NOT publish a key of its statement key set in any other JWK Set, or sign anything other than statements under this specification with those keys. A trusting authorization server reuses a retrieved statement key set only as permits. The configuration can also make an issuer a required issuer for client identifier namespaces in one of the server's tenants (). The server then MUST NOT admit software in a covered namespace in that tenant without a current statement from the required issuer, whatever its policy for CIMD clients it has not reviewed. Without this rule, a holder could evade the required issuer's decision by withholding that issuer's statement or by presenting or publishing only a broader one, such as a marketplace listing. A required issuer configured for software whose document makes every presentation review-only (item 1 of ) excludes that software from the tenant, and the server rejects a request for such software there.

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.

Runtime Presentation An authorization server that admits clients at request time under this specification MUST support statements presented in requests (). Support for pulled statements () is optional, and a server advertises it with the software_statement_pull_supported metadata value (). A server that consumes statements only to create or renew registrations () need not support runtime presentation.

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

1. Obtain the statement, presented in the request () or pulled ().
2. Validate the statement (), completing every check that needs no client-controlled retrieval before any such retrieval ().
3. Verify the client_id rule of .
4. Resolve the reviewed document and compare its digest (). A server that proceeds without the statement on a mismatch ends admission on the statement here.
5. Apply to that document, verifying the sender constraint unless the statement is review-only (). If or defers the proof to code redemption, the server verifies it there.
6. Evaluate the request against the reviewed metadata ().
7. Create the establishment (), unless the statement is review-only ().

Reviewed Metadata Having validated the statement, and before verifying the proof (), 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 (), 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 ), 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 (, ): 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 defaults.

Retrieval Every retrieval this specification causes inherits the server-side request forgery protections in Section 10.7 of , 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 (). 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 () 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 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 ) 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 ), 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 ). A trusting authorization server MAY reuse document octets it holds for digest comparison (), a key set retrieved from a document's jwks_uri, and a statement key set from either source (), 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 (). Without this rule, a key the document carries inline would continue to verify after the publisher removes it.

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 (). 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 ).

Token Endpoint At the token endpoint, a runtime presentation is valid on a request that opens a new grant in that request, such as one using the client_credentials grant, the JWT or SAML 2.0 assertion grant (Section 2.1 of and Section 2.1 of ), or token exchange . It is not valid on a request that continues or completes a grant an earlier request began, such as authorization-code redemption, refresh-token use (, ), or redemption of a device code . Admission belongs to the request that begins the grant, before the resource owner approves the client.

Authorization Endpoint Presentation in an authorization request MUST use a pushed authorization request . The subsequent authorization request MUST use a client_id parameter exactly equal to the establishment's sub and MUST NOT include the software_statement parameter. A pulled statement needs no pushed authorization request ().

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 , except that:

• The server chooses the statement ().
• If the pull yields no usable statement, the request proceeds as if the client had presented none ().
• A pulled statement is review-only in the cases 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 (), each a string in JWS compact serialization. The metadata digest covers this member ().

An authorization server advertises support through software_statement_pull_supported ().

Retrieval and Selection In retrieving the software_statements_uri, the authorization server:

• MUST send a GET request with Accept: application/json.
• MUST NOT automatically follow redirects.
• MUST accept a new representation only from a 200 response with a JSON media type, and can instead reuse a stored representation that a 304 Not Modified response revalidates (Section 15.4.5 of ).

The document and this URL are necessarily retrieved before any statement is validated, so the ordering of step 2 of applies only to the retrievals that follow. The server considers only statements that meet all of the following conditions, and ignores the rest:

• The sub claim equals the document's client identifier.
• The statement validates under .
• The cimd_digest claim equals the digest of the document the server resolved.

If the server's trust configuration requires an issuer for this client (), the server also ignores statements from any other issuer. If more than one statement remains, it applies the most recently issued statement from an issuer of its choice. Having selected a statement, the server continues from step 5 of , with the document already resolved. The selection satisfies the client_id rule of step 3. If retrieving the statements does not complete or no statement remains, the server applies its policy for CIMD clients it has not reviewed, subject to any required issuer (), and rejects the request if that policy or a required issuer requires reviewed software.

Binding Unless the reviewed document's redirection URIs make it review-only (), a pulled statement is bound to the presenter as a presented statement is (), at the point the following table shows:

Where the statement is pulled	Confidential client	Public client
Token endpoint, opening a new grant	The request's client authentication	Review-only
Pushed authorization request endpoint	The request's client authentication	PKCE with S256 and a key bound through a DPoP proof or dpop_jkt, as requires. Otherwise review-only
Authorization endpoint	Client authentication at code redemption, before any token is issued	PKCE with S256 and a key bound through dpop_jkt, as requires, which redemption then proves. Otherwise review-only

At code redemption, a confidential client whose statement was pulled at the authorization endpoint authenticates with a key the reviewed document carries, in its jwks or at its jwks_uri within the reuse bounds of , not one that only a later retrieval of the document carries, and that key becomes the establishment's proven key. The method with which the client authenticates becomes the establishment's Selected Method.

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

• Confidential client: by a key the reviewed document carries ().
• Public client: by an installation key the presenter binds (), while its reviewed redirection URIs, with PKCE S256, bind the presentation itself ().

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 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 ). 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 . A public client that binds its key through dpop_jkt proves possession at code redemption (). 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.

Confidential Clients For a confidential client's presentation that is not review-only, the proven key MUST appear in the jwks or at the jwks_uri of the reviewed document (). A key appears there if the document's jwks, or the JWK Set at its jwks_uri, contains a key with the same JWK Thumbprint (), computed with SHA-256. The comparison covers key material only: the key's algorithm and intended use are checked as the client authentication method requires. The same comparison applies wherever this specification asks whether a document carries a key. Methods that prove possession of a key the document carries, such as private_key_jwt (Section 5 of ) and self_signed_tls_client_auth (Section 2.2 of ), satisfy this directly.

Public Clients Software distributed to end users cannot hold a key its reviewed document carries: a key shipped in every copy identifies the software, not the installation. Such a document permits none and carries no key material. An authorization server MUST reject a presentation made in a request, even a review-only one, that opens a new grant at the token endpoint () from a public client. Such a presentation opens no redirect and has nothing to bind it. covers a pulled statement. For a public client's presentation that is not review-only, made or pulled at the pushed authorization request endpoint, or pulled at the authorization endpoint (), the authorization server:

• MUST require PKCE with the S256 method.
• MUST require the presenter to bind a key it holds, through the dpop_jkt parameter or, at the pushed authorization request endpoint, a DPoP proof (Section 10.1 of ), and records that key as the proven key of the establishment ().
• MUST NOT require that key to appear in the reviewed document.

Review-Only Presentations The following are review-only:

1. Every presentation and pulled statement for a reviewed document that carries any redirection URI another application on the same device could claim, whatever methods the document permits. Such a URI is a non-https URI, such as a private-use scheme or an http loopback redirection URI (Sections 7.1 and 7.3 of ), or an https URI whose host is a loopback address, localhost, or a name ending in .localhost (Section 6.3 of ), ignoring case and a trailing dot. The application that claims such a URI receives the code, so neither the reviewed redirection URIs nor a key shipped in every copy of the software can bind the presenter.
2. A pulled statement that makes review-only.

A review-only presentation or pulled statement creates no establishment, and its statement MUST NOT satisfy a policy requiring reviewed software: the authorization server proceeds as it would for the same CIMD client presenting no statement, though it can record the statement's issuer for audit ().

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 ().
• 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 ().
• 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 (), 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.

Refresh On refresh-token use under an establishment, the authorization server:

• MUST verify that the request is made in the tenant the establishment records, if it hosts more than one tenant.
• MUST verify possession of the establishment's proven key under the same sender-constraint mechanism.
• MUST, except for an establishment created under , verify that the document currently served at the establishment's sub still carries that key, in its jwks or at its jwks_uri, within the reuse bounds of .

If any of these checks fails, the server rejects the refresh. The refreshed access MUST fall within the establishment's reviewed metadata. Under this specification, refresh evaluates no statement () and never changes the establishment's proven key or reviewed metadata. A client that needs a different key or review opens a new grant by presentation. An extension can instead provide for replacing the review on refresh.

Error Responses A rejection uses the error response and HTTP status codes of its endpoint: Section 5.2 of at the token endpoint, Section 2.3 of at the pushed authorization request endpoint, and Section 4.1.2.1 of at the authorization endpoint. A rejection for a reason this specification defines uses the first of the following error codes that applies:

1. invalid_request, if the request carries the software_statement parameter in a role does not permit.
2. temporarily_unavailable, if a retrieval the request needs did not complete (), including a pull of statements () or the retrieval of a statement key set needed to verify a pulled statement.
3. The code that , , or assigns.

At the token and pushed authorization request endpoints, an authorization server MUST respond with HTTP status code 503 to a request it rejects with the temporarily_unavailable error code, as Section 6.1 of requires for a transient failure to retrieve the document. A rejection for another reason, such as an assertion grant whose assertion is invalid (Section 3.1 of ) or an expired or revoked refresh token, uses the error code its grant or endpoint assigns. An extension assigns codes to the rejections it defines.

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 ().

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 () for a reason other than expiry.
• The request's client_id differs from the statement's sub ().
• The request fails the sender constraint (), including a presentation opening a new grant at the token endpoint for a public client ().
• The reviewed document cannot be obtained, including over the size bound, fails validation as requires, contains duplicate member names (), or does not match and the server does not proceed without the statement ().
• The bound on establishments is reached ().

statement_required:

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

unauthorized_client:

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

• The request exceeds the reviewed document's grant types or response types ().
• 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 ().
• The request is for software a required issuer excludes from the tenant ().

invalid_scope:

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

invalid_request:

The request omits client_id ().

Code Redemption and Refresh Under an establishment, code redemption () 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 ().

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 (), as Section 6.1 of requires.

invalid_grant:

Any other check of 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 (), whose detection this specification does not change.

Authorization Requests If the authorization server's policy or a required issuer () 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 ) with the following error codes:

unauthorized_client:

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

statement_required:

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

When an authorization request is evaluated against a statement pulled at the authorization endpoint (step 6 of ), one that exceeds the reviewed document's response types or scope is rejected with unauthorized_client or invalid_scope, as for a presentation (). 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 ). If it cannot obtain a CIMD client's document, or the document fails validation, it MUST NOT redirect (Section 6.1 of ).

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 or use_dpop_nonce for a nonce challenge (Section 8 of ), 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.

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 (), such as the client identifier namespaces an issuer can attest, to an unauthenticated requester.

Examples The examples in this section are non-normative.

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

Publishing a Statement for Servers to Pull The following is an example of a CIMD that names where its statements are published: A request to that URL returns the statements, here one: 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 ().

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): 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.

Authorization Server Metadata This specification defines the following authorization server metadata values:

software_statement_jwks_uri:

REQUIRED for an authorization server that issues statements under this specification. URL of its statement key set (), a JWK Set containing only the keys with which it signs them.

software_statement_signing_alg_values_supported:

REQUIRED for an authorization server that issues statements under this specification. A JSON array containing the asymmetric JWS alg values that the authorization server can use to sign them. The array MUST NOT contain none or a symmetric algorithm.

software_statement_pull_supported:

OPTIONAL. Boolean value indicating whether the authorization server retrieves statements from a client's software_statements_uri member when admitting a client that presented none (). If omitted, the default value is false.

Extension Points The following extensions are left to separate specifications:

• Consumption at registration (): a statement in an registration request, with the registered metadata taken from the reviewed document.
• Attested keys: a client attestation vouching for a key the reviewed document does not carry. Without one, software whose instances authenticate with keys of their own cannot prove those keys ().
• Statement conveyance within a client attestation, rather than as a request parameter.
• Runtime presentation in the request that begins a grant at an endpoint this specification does not cover, such as the device authorization endpoint of .
• Partial review, by which an issuer vouches for particular members rather than a whole document ().
• Statement lifecycle: withdrawal, supersession, requiring a current statement on refresh, and refresh replacement.

Relationship to Other Work This section is non-normative.

Client Attestation A software statement and a client attestation 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.

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

OpenID Federation A trust mark is also a signed third-party assertion about an entity. Section 17.5 of 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 () and no dependency on federation metadata resolution.

Implementation Considerations This section gives guidance to implementers. It adds no requirement.

Caching and Reuse of Retrieved Content A response from a software_statements_uri ought to be cached no longer than the document is. Because forbids caching an error response (Section 6.2 of ), a failed retrieval () is followed by back-off.

Retrieval and Processing Bounds An authorization server can bound the retrieval and processing work of as follows:

• Rate-limit presentations per statement identity, per subject, and per source, and pulls () 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 () 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 recommends that a server read at most 5 kilobytes, so an issuer ought not to issue a statement over a larger document.

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 , 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 (, ), the authorization server ought to state that reason in error_description, and the client can retry once earlier establishments end ().

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 (). 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.

Deployment Considerations This section gives guidance to operators and issuers. It adds no requirement.

Configuring Issuer Trust Trust configuration ought to constrain each issuer to the client identifier namespaces it is expected to attest (), 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 ().

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.

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 (), 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 ().

Security Considerations The security considerations of and Section 5 of apply.

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 () 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 (). 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:

Property	Established
A configured issuer signed the statement for this client identifier and, if the statement names an audience, one that includes this server	Yes
The served document is the one the issuer reviewed, octet for octet	Yes
The presenter controls a key the reviewed document carries	Yes, before any token is issued, except under . A jwks_uri attests only the keys' location ()
Authorization codes reach only a reviewed redirection URI	Yes, in a redirect flow. For a public client under it is the only binding, and it does not hold against a party that controls the user agent ()
The running software is the software the issuer reviewed	No; an attested-key extension can add evidence for it ()
The client may access a particular resource	No; the authorization server's policy, and the resource owner's authorization where a grant involves one, decide

Statement Theft and Replay A copied statement admits nothing without the sender constraint (), which for a public client does not hold against a party that controls the user agent (). Except under (), admitting only keys the reviewed document carries also prevents a downgrade to a key the issuer did not review. An extension admitting attested keys () 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 () also accepts that a just-removed key can briefly continue to verify.

Servers That Do Not Implement This Specification A statement carries no client metadata, so an 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 (, ) means such a server finds no key that verifies a statement through the jwks_uri in an issuer's 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.

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 (). 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 (), so other users are exposed only to a consent prompt carrying the reviewed software's name and branding. Rate limits () 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 ), 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 therefore shows where codes are delivered, not which software holds the grant, and a tenant's required issuer () cannot keep unreviewed software out for a user who chooses to run it. This is the client impersonation that Section 8.6 of describes for public clients. An attested-key extension () would strengthen the binding by giving the instance a key a third party vouches for.

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

External Retrieval and Resource Exhaustion The retrievals of 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 limit this work but do not prevent it.

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 (). 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 (). 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 () end a grant already admitted. A server ends such grants by its own means, such as revoking refresh tokens.

Observable State A statement_required refusal at the authorization endpoint () 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. keeps further detail of the issuer trust configuration out of error_description for unauthenticated requesters.

Privacy Considerations The privacy considerations of and Section 6 of apply. A presentation reveals to the authorization server the client's issuer relationship and, if the statement carries an aud claim, the other authorization servers the client intends to use. Omitting that claim discloses nothing beyond the review. Pushed authorization requests () keep statements out of browser history, referrers, and front-channel logs. Retrieving the document tells its host that the server is resolving the client. Pulling statements () tells the host of software_statements_uri the same. That host is an additional party only if the URL is on another origin. Published statements are readable by anyone, so their aud and aud_tenant claims disclose which servers and tenants a review names. A statement whose audience is sensitive is presented rather than published.

IANA Considerations

OAuth Parameters Registry This specification requests registration of the software_statement parameter in the IANA "OAuth Parameters" registry established by :

Parameter Name:

software_statement

Parameter Usage Location:

authorization request, token request

Change Controller:

IETF

Specification Document(s):

This specification, and

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

Media Type Registration This specification requests registration of the application/software-statement+jwt media type in the IANA "Media Types" registry . 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 .

Security considerations:

See of this specification and Section 11 of .

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

JSON Web Token Claims Registry This specification requests registration of the following values in the IANA "JSON Web Token Claims" registry established by :

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,

Claim Name:

statement_uses

Claim Description:

Permitted uses of a software statement

Change Controller:

IETF

Specification Document(s):

This specification,

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

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,

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):

, this specification ()

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

OAuth Authorization Server Metadata Registry This specification requests registration of the following values in the IANA "OAuth Authorization Server Metadata" registry established by :

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,

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,

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,

References Normative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Federal Information Processing Standard, FIPS This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice. This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. Okta independent This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. Okta Independent Ping Identity This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using OAuth 2.0 Token Exchange (RFC 8693) and the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523). This pattern is informally referred to as Cross-App Access (XAA). In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. Independent This specification defines how an authorization server registers a client through OAuth 2.0 Dynamic Client Registration (RFC 7591) on a Client ID Metadata Document (CIMD) software statement, as defined in a companion specification. Such a statement carries no client metadata of its own. It vouches for the exact octets of the client's document, and the authorization server takes every registered metadata value from that document rather than from the registration request. This specification also bounds the registration's validity by the statement's expiry, which RFC 7591 leaves unbounded, and defines how a client renews the registration by delivering a later statement, which also updates the registered metadata. MATTR Bundesdruckerei SPRIND This specification defines an extension to the OAuth 2.0 protocol (RFC 6749) that enables a client instance to include a key-bound attestation when interacting with an Authorization Server or Resource Server. This mechanism allows a client instance to prove its authenticity, as verified by a client attester, without revealing its target audience to that attester. It may also serve as a mechanism for client authentication as per OAuth 2.0.

Acknowledgments This mechanism began as the consumption part of a draft on software statement issuance and was split out so that consumption can evolve separately from issuance. It draws on working-group discussion of CIMDs and attestation-based client authentication.

Document History [[ To be removed from the final specification ]] -01

• Updated references for draft -03 of , including its section numbers and the Accept header field it specifies.
• Defined Permitted Method and Selected Method. The client model follows the methods the reviewed document permits, and components that differ in client type use separate documents ().
• A document that declares no authentication method permits only none and is no longer rejected.
• Aligned retrieval failures with Section 6.1 of , including HTTP status code 503 for temporarily_unavailable and invalid_client on refresh when the document cannot be used.
• Updated the pull example for token_endpoint_auth_methods_supported.

-00

• Initial version.