]> Independent

public@karlmcguinness.com

Security Web Authorization Protocol OAuth Software Statement Dynamic Client Registration Client ID Metadata Document Registration Validity 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.

Introduction defines a software statement binding an issuer's review to the exact octets of a Client ID Metadata Document (CIMD) , and admission on that review without registration. This specification serves deployments retaining registration, for example to assign their own client identifiers or manage registrations under . already supports software statements whose metadata takes precedence over the registration request (Sections 2.3 and 3.1.1 of ). A statement under , however, carries a document digest instead of metadata. Verifying it under alone would leave the request's unreviewed redirection URIs and keys as the registered metadata. also defines no registration expiry or renewal tied to the statement. This specification defines how servers derive registrations from the reviewed document (), bound their validity by the statement (), and renew them with later statements that also update their metadata (). The same review can therefore govern both registered clients and runtime admission. It extends , which does not depend on it.

Protocol Overview The following non-normative sequence summarizes a statement-governed registration:

1. The client sends an registration request that carries a statement in the software_statement member.
2. The authorization server validates the statement, obtains the document at the statement's sub, and compares its digest with the statement's cimd_digest claim. It registers the client under a client identifier it assigns, with metadata taken from that document, records the statement as the registration's governing statement, and returns the registration's expiry in the registration_expires_at member (, ).
3. The registration is valid until the governing statement ceases to be current, at the latest at its effective expiry ().
4. To renew the registration, the client delivers a later statement from the same issuer in a token or pushed authorization request under the registration or, if supported, in an update request. If that statement is a valid replacement, the authorization server takes the registration's metadata from the document the statement reviews, and the statement becomes the governing statement ().
5. If the governing statement ceases to be current without a replacement, the registration ceases to be valid. The authorization server rejects authorization, token, and pushed authorization requests and update requests under it, unless the request delivers a replacement that restores it ().

A public-client registration can also be renewed by a repeated registration request ().

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), and the terms defined in Section 2 of . This specification defines the following terms.

Delivery:

Carrying a statement in a request under a statement-governed registration, in one of the locations lists, so that it can renew the registration. A delivery is not a runtime presentation.

Governing Statement:

The statement that bounds a statement-governed registration: the one consumed at registration or, after a renewal, the replacement that renewed it most recently (). The authorization server identifies it by its iss and jti claims.

Replacement:

A statement with the governing statement's iss and sub claims and a later iat, delivered under the registration () or carried in a repeated public-client registration request ().

Statement-Governed Registration:

An client registration created from a statement under this specification ().

Consumption at Registration The statement is consumed in the software_statement member of an registration request. The authorization server validates it under Section 3.2 of and registers the client under its ordinary registration policy. If a required issuer covers the statement's sub in the request's tenant (Section 4 of ), the authorization server MUST NOT create a registration on a statement from another issuer. A required issuer constrains only registrations made on statements, because a registration made without a statement names no client identifier URL for a required issuer to cover. A deployment that needs every registration in a tenant reviewed requires a statement for every registration there and rejects a request that carries none with unapproved_software_statement (). The retrieval requirements of Sections 3.1 and 5.3 of apply to retrieving the document as they apply to a runtime presentation, and a server can apply the bounds of Section 11.2 of . Following the order of Section 5.1 of , the authorization server completes every check that needs no client-controlled retrieval before resolving the document. The reviewed document takes the role that gives a statement's own values. In deriving a registration's metadata, at registration or for a replacement (), the authorization server:

• MUST obtain the CIMD at the statement's sub claim and compare its digest with the cimd_digest claim as Section 5.2 of requires, rejecting the request if the digests differ, and MUST derive the registered metadata from the octets whose digest matched.
• MUST validate the document as requires, including that its client_id member matches the statement's sub claim.
• MUST take every client metadata value from that document, except the values the authorization server issues (such as client_id and client_id_issued_at), the token_endpoint_auth_method member, which the next item determines, and the document's software_statements_uri member, which is not meaningful in a registration (Section 5.5 of ).
• At registration, MUST register as token_endpoint_auth_method a method that the document permits (Section 2 of ) and that the server supports and its policy allows, and MUST NOT register none if the document permits another such method. A replacement keeps the registered method ().
• MUST NOT take any client metadata value from the request, or from any update request for the registration, whether or not the document carries the corresponding member.

Client metadata in a registration or update request does not contribute to the registration. The registration's software_statement is its governing statement (). The registered client_id is assigned as provides, and the document's own client_id member is the URL recorded as the governing statement's sub. The authorization server MUST NOT assign that URL as the registered client_id, which would make a request carrying it ambiguous between the registration and the CIMD client the URL identifies (). A member the document omits takes its default, except token_endpoint_auth_method, which is registered as above. The registration's metadata changes only when a replacement is applied (). The authorization server MUST reject the registration, or a replacement (), if any of the following holds:

• The document permits a method based on a shared symmetric secret, such as client_secret_basic, which Section 4.1 of forbids.
• The document permits no method that the server supports and its policy allows.
• The method the server would register is none, unless the authorization server registers the client under .
• Any of the document's redirection URIs could be claimed by another application on the same device (Section 5.6.3 of ), whatever methods the document permits.

Unlike runtime presentation (Section 5 of ), registration has no review-only form: the rejections above cover the document conditions that make a presentation review-only. Software that the server would register with none but does not register under can instead use runtime presentation if it meets the public-client binding requirements of Section 5.6.2 of .

Tenant Restriction If the statement's decision is confined to one of the authorization server's tenants, by its aud_tenant claim or by the server's trust configuration for its issuer (Section 4 of ), the registration is restricted to that tenant. Otherwise it carries no tenant restriction under this specification. A replacement () determines the restriction as follows:

Registration before	Replacement's decision	After
Restricted to a tenant	Confined to that tenant, or not confined and valid in that tenant (Section 3.2 of )	Restricted to that tenant
Restricted to a tenant	Confined to another tenant	Fails validation (Section 3.2 of )
No restriction, confidential client	Confined to a tenant	Restricted to that tenant
No restriction, public client	Confined to a tenant	Not a valid replacement
No restriction	Not confined to a tenant	No restriction

The tenant rules of steps 1 and 4 of also apply to any other request under the registration, including read and delete requests. To an read, update, or delete request that these rules treat as from a client it has not registered, the authorization server MUST respond with HTTP 403 Forbidden (Sections 2.1 through 2.3 of ) and MUST NOT revoke the registration access token, since the registration remains valid where these rules do not apply.

Public Clients An authorization server MAY register a client with token_endpoint_auth_method of none (), creating a public-client registration. Such a registration has no client credential and is shared among installations of the software. A server that registers such a client:

• MUST reject the registration if the document lists no redirection URI.
• MUST issue tokens under the registration only through the authorization code grant and the refresh of grants it opens.
• MUST apply Section 5.6.2 of to every authorization request under the registration, and MUST require code redemption and every refresh of the resulting grant to prove the key bound there.
• MUST NOT issue a registration access token for the registration.

Repeated Registration A registration request is repeated if its statement has the iss and sub claims of the governing statement of an existing statement-governed registration, valid or not, that:

• is not restricted to another tenant (), and
• is restricted to the request's tenant, if that tenant requires a tenant-scoped decision (Section 3.2 of ).

One current statement can be consumed more than once, subject to the bounds of Sections 11.2 and 11.3 of and the server's registration policy. A server can count registrations toward the bound on establishments of Section 11.3 of , but the bound stays effective only if a registration under which no access token has been issued does not count toward it, since a holder of a copy of the statement can create one. If the registration a request repeats is a confidential-client registration, local policy can reject the request, treat it as idempotent, or create another registration. An idempotent response MUST NOT return the existing registration's credentials, such as its registration_access_token member. A common default is one registration per iss and sub, per tenant on a multi-tenant server, at the cost describes. If the registration a request repeats is a public-client registration (), the authorization server MUST NOT create another registration and handles the request by its statement, once the statement validates:

Statement in the repeated request	Outcome
The governing statement, identified by its iss and jti	The existing registration is returned
A statement with a later iat than the governing statement's	Evaluated as a replacement (); the renewed registration is returned or the request is rejected ()
Any other statement with an iat no later than the governing statement's	The request is rejected

Registration Validity The following validity model applies to every statement-governed registration:

• The registration's effective expiry (Section 2 of ) is that of its governing statement.
• The registration is valid until its governing statement ceases to be current (Section 2 of ), and so at most until that effective expiry.
• Once the registration has ceased to be valid, the authorization server MUST reject, at step 4 of , authorization, token, and pushed authorization requests and update requests under it, unless a replacement the request delivers has restored it at step 3.
• The authorization server SHOULD retain a registration that has ceased to be valid, so that a replacement can restore it.
• Ceasing to be valid does not expire the registration's credentials, including its registration access token, and does not by itself revoke access tokens already issued under the registration.
• Removing the governing statement's issuer from trust configuration, or narrowing what it can attest, does not by itself end the registration. A server ends it by its own means, such as deleting it.

If a request that carries no replacement is rejected because the registration has ceased to be valid, the rejection MUST NOT by itself cause the authorization server to revoke refresh tokens as it does on detecting refresh-token replay (Section 4.14.2 of ). If the authorization server records a required issuer for a tenant (Section 4 of ), it MUST reject an authorization, token, or pushed authorization request, or an update request, in that tenant under any statement-governed registration whose governing statement's sub falls within a covered namespace, unless a current statement from the required issuer governs the registration as step 3 of leaves it. This rule applies whatever tenant the registration was created in and whenever the requirement was configured. Without this rule, withholding the required issuer's statement would keep such a registration in use after the issuer withdrew or stopped renewing its decision. A registration whose governing statement is from another issuer cannot meet this rule, since a replacement keeps the governing statement's iss (). Its client registers again with a statement from the required issuer. Neither the validity model nor the required-issuer rule rejects read and delete requests. The registration_expires_at member is a NumericDate (Section 2 of ) giving the latest time the registration remains valid or, for a registration that has ceased to be valid, the time it ceased. The authorization server:

• MUST return registration_expires_at in the registration response and in the successful response to any request that renews the registration or carries its governing statement ().
• SHOULD return it in any other read or update response it supports.

Requests Under a Registration The authorization server MUST process an authorization, token, or pushed authorization request, or an update request, under a statement-governed registration in the following order, stopping at the first step that rejects the request or treats it as from a client the server has not registered:

1. If the registration is restricted to a tenant () and the request, including one that delivers a statement, is made in another tenant, it MUST treat the request as from a client it has not registered.
2. It authenticates a token or pushed authorization request under the registration's own client authentication method, and an update request as requires, against the retained registration even if the registration has ceased to be valid. A token or pushed authorization request under a public-client registration has no client credential to authenticate ().
3. It classifies any statement the request delivers by its claims, before validating it, and evaluates a replacement (). A replacement applied at this step stands even if a later step, or the request's grant, rejects the request.
4. It applies the rejections of to the registration as step 3 leaves it. If the request is made in a tenant where the authorization server requires a tenant-scoped decision (Section 3.2 of ) and the registration, as step 3 leaves it, carries no tenant restriction, it MUST treat the request as from a client it has not registered.
5. It evaluates the request against the registration's metadata.

Renewal A client renews a statement-governed registration by delivering a replacement statement in one of the following, authenticated as step 2 of provides:

• The software_statement parameter of a token request under the registration.
• The software_statement parameter of a pushed authorization request under the registration.
• The software_statement member of an update request, if the deployment offers registration management.

A delivery is a registration use of the statement (Section 3 of ). A registration request is not a delivery, and renews an existing registration only as provides for a public-client registration. A statement neither renews nor alters a registration that is not statement-governed, and runtime presentation (Section 5 of ) alters no registration's metadata. The authorization server treats a delivered statement as the first matching row of the following table provides:

Statement delivered	Treatment
The governing statement itself, identified by its iss and jti	No replacement
In an update request, any statement with the governing statement's iss and sub and an iat no later than the governing statement's	No replacement
At the token or pushed authorization request endpoint, any other statement with the governing statement's iss and sub and an earlier iat	Earlier than the governing statement. The request is rejected
A statement with the governing statement's iss and sub and a later iat	A replacement, evaluated below
Any other statement, such as one with another iss or sub	Fails the replacement rules below

An update request repeats the statement a previous response returned (Section 3.2.1 of ; Section 2.2 of ), which can be older than the governing statement. An read or update response returns the governing statement as its software_statement member. The replacement MUST satisfy the following:

• It validates under Section 3.2 of .
• The iss and sub claims equal those of the governing statement.
• The iat claim is later than that of the governing statement.
• Its document permits the registration's token_endpoint_auth_method (Section 2 of ).
• For a public-client registration that carries no tenant restriction, its decision is not confined to a tenant ().
• Its document, from which the registration's metadata is derived, satisfies the rules of .

Renewing on the statement alone would leave in the registration a key, redirection URI, or scope that the new review removed. A request whose replacement fails the rules above is rejected () whether or not the registration has ceased to be valid. A rejected delivery leaves the governing statement unchanged. When a replacement satisfies these rules, the authorization server MUST, in a single atomic update, make it the governing statement and give the registration the replacement's effective expiry, the metadata derived from its document (), and any tenant restriction it adds (). Concurrent deliveries resolve to the most recently issued statement. A valid replacement restores a registration that has ceased to be valid. Access issued under the registration after that update, including on refresh of a grant issued before it, MUST fall within the re-derived metadata. If every grant a confidential-client registration permits needs an authorization request or a refresh token, and the authorization server does not support update requests for the registration, the server MUST support pushed authorization requests for the registration. Otherwise such a client, if it holds no refresh token, could not restore a registration that has ceased to be valid. A public-client registration also renews through a repeated registration request ().

Error Responses A rejection this specification defines, at a client registration endpoint or at the client configuration endpoint of , uses the error response of Section 3.2.2 of , with the HTTP status code that section specifies, except that an authorization server SHOULD respond with HTTP status code 503 to a request it rejects with the temporarily_unavailable error code. Such a rejection uses the following error codes:

invalid_software_statement:

Any of the following:

• The statement is malformed, fails signature or claim validation for a reason unapproved_software_statement does not cover, is expired or otherwise not current (Section 2 of ), or is superseded under an extension the server implements.
• The document's digest does not equal the statement's cimd_digest claim ().
• An update request is rejected under .
• A statement delivered at the client configuration endpoint, or the statement of a repeated public-client registration request evaluated as a replacement (), fails the replacement rules of where this section assigns no other code, such as a document that does not permit the registration's token_endpoint_auth_method.
• The statement of a repeated public-client registration request is not the governing statement and has an iat no later than the governing statement's ().

unapproved_software_statement:

The statement is well formed but not acceptable here: its issuer is not configured, its aud excludes this server, its sub is outside the client identifier namespaces the issuer can attest, its aud_tenant is not this request's tenant or is absent when required, its issuer is confined to another tenant, or its statement_uses excludes this use. This code is also used if a statement this server requires is absent from a registration request, if forbids creating the registration because a required issuer covers the statement's sub and the statement is from another issuer, or if the server's policy refuses a repeated registration request ().

invalid_client_metadata:

Any of the following holds for the reviewed document:

• It contains duplicate member names (Section 5.2 of ).
• It fails validation as requires ().
• It carries metadata this server's policy refuses.
• It cannot be obtained, including over the server's size bound, for a reason other than a retrieval that did not complete (Section 5.3 of ).
• It permits a method based on a shared symmetric secret ().
• It permits no method that the server supports and its policy allows ().
• The server would register the client with none () and does not register it under .

invalid_redirect_uri:

The reviewed document carries a redirection URI another application could claim (), or the server would register the client with none and the document lists no redirection URI ().

temporarily_unavailable:

A retrieval the request needs did not complete (Section 5.3 of ).

Rejections at other endpoints use the error responses of Section 6 of . At the token and pushed authorization request endpoints, a request that fails the authentication of step 2 of is rejected with invalid_client. Subject to the order of Section 6 of , a token, pushed authorization, or authorization request is rejected with statement_required (Section 6.1 of ) if:

• its registration has ceased to be valid, or the required-issuer rule rejects it (), or
• its delivered statement is earlier than the governing statement or fails the replacement rules ().

At the authorization endpoint, the redirect_uri is validated against the registration's redirection URIs before an error is redirected (Section 4.1.2.1 of ). Rejections of a registration management request for other reasons use the responses specifies, such as the HTTP 403 Forbidden response that requires.

Example The following is a non-normative example of a registered client, whose client_id is s6BhdRkqt3, renewing its registration by delivering a replacement statement on an ordinary refresh, authenticated under its registered private_key_jwt method (line breaks for display purposes only): The authorization server validates the replacement and re-derives the registration's metadata (), returning the registration's new expiry in the registration_expires_at member of the token response. Once the registration has ceased to be valid, the same request without a replacement is rejected with statement_required ().

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

software_statement_registration_supported:

OPTIONAL. Boolean value indicating whether the authorization server supports this specification. If omitted, the default value is false. A value of true means every registration the server creates from a statement of the profile in Section 3 of is statement-governed, and does not imply support for runtime presentation.

Deployment Considerations This section gives guidance to operators. It adds no requirement. An issuer outage longer than a statement-governed registration's remaining lifetime makes the registration cease to be valid () until the client delivers a replacement (). The lifetimes an issuer chooses set the renewal cadence (Section 12.3 of ). A deployment ought to have clients renew well before effective expiry, and ought to weigh that cadence against how quickly a narrowed or withdrawn review needs to take effect. A client that delivers a replacement at the token or pushed authorization request endpoint authenticates against the retained registration (step 2 of ). If it rotates a key carried inline in its document's jwks, it authenticates such a request with the outgoing key until a replacement over the new document has been applied, and with the new key afterward. It retires the outgoing key only after that renewal succeeds. An update request authenticates with the registration access token instead (Section 2 of ).

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

Statements at Registration A statement consumed at registration is a reusable bearer artifact until it expires. Its audience, lifetime, and statement_uses claim (Section 3 of ) and the registration policy of limit what a copied statement can create. A statement a client publishes at its software_statements_uri (Section 5.5 of ) can be read by anyone, so an issuer ought not to permit registration in such a statement. Taking every value from the document prevents metadata substitution. A request-supplied value for a member the document omits, such as a jwks member beside a document naming only jwks_uri, would give any holder of a copy a registration with reviewed branding and the holder's own key. A document that declares no authentication method permits only none (Section 5 of ). Registering it under the default would register a shared-secret method, which forbids (Section 4.1 of ) and the issuer never reviewed. An issuer that omits aud from a statement permitting registration accepts that any server trusting the issuer can register the software on the strength of a copy. Under the one-registration default (), whoever first registers with a copy of a statement holds that registration and its registration access token, and can keep the software's publisher from registering there. Such a holder cannot authenticate as the client if the registered token_endpoint_auth_method requires a key the document carries. If the publisher's statement permits presentation and the server supports it, the publisher's software can still be admitted through runtime presentation (Section 5 of ). Otherwise, recovery requires intervention by the server's operator or a registration policy other than the one-registration default. This specification defines no way to displace such a registration. A public-client registration () has no credential to take, and a repeated request is answered with it (), so its first registrant gains nothing over later ones. Any holder of a copy can use it. Authorization codes under it reach only the reviewed redirection URIs, and its grants are bound to keys that installations hold. A holder of a copy therefore gains what it would gain at runtime, including the exposure Section 13.4 of describes for a holder that controls the user agent.

Credential Theft and Renewal Renewal proves possession of the registration's credential and the currency of a statement sharing the governing statement's iss and sub, not that the renewing party is the reviewed software. An attacker holding a stolen client credential can renew indefinitely with the newer statements distributed to every deployment of the software. A public-client registration's renewal proves only that the replacement is current. No protection is lost, since any party can already use that registration. A narrower review takes effect at a registration when the client delivers it or when the governing statement ceases to be current. Withdrawal before then requires an extension (Section 9 of ). Deployments ought to pair statement-governed registrations with credential rotation, sender-constrained client authentication, and the bounds that Sections 11.2 and 11.3 of and describe, and ought to treat a credential compromise as requiring re-registration rather than renewal. At runtime, a confidential client's key must appear in the reviewed document and, on refresh, in the document currently served (Sections 5.6.1 and 5.7.1 of ). Once the server observes that the document no longer carries a compromised key, which can take up to the reuse bounds of Section 5.3 of , refresh requests made with that key fail.

Registration Fraud and Impersonation Open registration permits client_name, logo_uri, and client_uri values that imitate trusted software on consent screens (Section 5 of ). Requiring a statement replaces self-asserted branding with issuer-reviewed values, though content served at a URL the document carries, such as a logo, can change after review (Section 13.1 of ). Servers that render such values on consent screens ought to prefer those from a reviewed document and to apply heightened scrutiny to registrations that claim user-visible branding without a statement. Requiring a statement also means a removed client cannot register again under a new client identifier URL without another issuer decision.

Observable State A retained registration that has ceased to be valid is distinguishable from an unknown client (, ). At the token and pushed authorization request endpoints, only a requester that authenticates as the registration's client can observe this, except for a public-client registration. At the authorization endpoint, anyone who sends an authorization request naming the client and one of its registered redirection URIs learns from the statement_required redirection that the registration has ceased to be valid. If an observer knows the governing statement's exp, a lapse before that time shows that an extension ended the statement or that the server caps the lifetime it honors for the issuer. As at runtime (Section 13.8 of ), these disclosures are accepted, and they reveal nothing of the server's issuer trust configuration beyond the fact and time that the registration ceased to be valid (Section 6.6 of ). Publishing software_statement_registration_supported discloses that statement-governed registrations expire there, which a client needs to know before registering.

Privacy Considerations The privacy considerations of Section 14 of and Section 6 of apply. A registration request reveals to the authorization server the same information as a runtime presentation.

IANA Considerations

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 . An authorization server returns this member in a registration response:

Client Metadata Name:

registration_expires_at

Client Metadata Description:

Latest time at which a statement-governed registration remains valid, as a NumericDate.

Change Controller:

IETF

Specification Document(s):

This specification,

OAuth Parameters Registry This specification requests registration of the following parameter in the IANA "OAuth Parameters" registry established by , for the responses to requests that renew a statement-governed registration or carry its governing statement:

Parameter Name:

registration_expires_at

Parameter Usage Location:

token response, pushed authorization request response

Change Controller:

IETF

Specification Document(s):

This specification,

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

Metadata Name:

software_statement_registration_supported

Metadata Description:

Boolean value indicating whether the authorization server supports Client ID Metadata Document software statement registration.

Change Controller:

IETF

Specification Document(s):

This specification,

OAuth Extensions Error Registry This specification requests that IANA update the existing temporarily_unavailable entry, adding the registration endpoint and the client configuration endpoint to its usage locations and this specification as a reference:

Error Name:

temporarily_unavailable

Error Usage Location:

registration endpoint, client configuration endpoint, in addition to the locations already registered

Related Protocol Extension:

OAuth 2.0 Authorization Framework

Change Controller:

IETF

Specification Document(s):

, this specification ()

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] 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. 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. 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. Independent 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. 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. This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. 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.

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

• Aligned authentication methods with draft -03 of . The registered token_endpoint_auth_method is a method the reviewed document permits, and a replacement keeps it ().
• A document that declares no authentication method permits only none and is no longer rejected.

-00

• Initial version.