Original text:
2.1. <del> OAuth 2.1 defines three client types based on their ability to authenticate securely with the authorization server as well as the authorization server's assurance of the client's identity. Clients that have credentials and have a prior relationship with the AS are designated as "confidential clients" </del>  <del> Clients that have credentials but no prior relationship with the AS are designated as "credentialed clients" </del>  Clients without credentials are called "public clients" Any clients with credentials MUST take precautions to prevent leakage and abuse of their credentials.  Authorization servers SHOULD consider the level of confidence in a <del> client's identity when deciding whether they allow such a client access to more critical functions, such as the Client Credentials grant type. </del>  A single "client_id" MUST NOT be treated as more than one type of client. <del> For example, a client that has been registered at the authorization server by a registered application developer, where the client is expected to be run as server-side code, would be considered a confidential client.  A client that runs on an end-user's device, and uses Dynamic Client Registration (RFC7591) to establish credentials the first time the app runs, would be considered a credentialed client.  An application deployed as a single-page app on a static web host would be considered a public client. </del> This specification has been designed around the following client profiles: <del> A web application is a confidential client running on a web server.  Resource owners access the client via an HTML user interface rendered in a user agent on the device used by the resource owner.  The client credentials as well as any access tokens issued to the client are stored on the web server and are not exposed to or accessible by the resource owner. A browser-based application is a public client in which the client code is downloaded from a web server and executes within a user agent (e.g., web browser) on the device used by the resource owner.  Protocol data and credentials are easily accessible (and often visible) to the resource owner.  Since such applications reside within the user agent, they can make seamless use of the user agent capabilities when requesting authorization. A native application is a public client installed and executed on the device used by the resource owner.  Protocol data and credentials are accessible to the resource owner.  It is assumed that any client authentication credentials included in the application can be extracted.  On the other hand, dynamically issued credentials such as access tokens or refresh tokens can receive an acceptable level of protection.  At a minimum, these credentials are protected from hostile servers with which the application may interact.  On some platforms, these credentials might be protected from other applications residing on the same device. </del>  2.2. <del> The authorization server issues the registered client a client identifier - a unique string representing the registration information provided by the client.  The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication.  The client identifier is unique to the authorization server. </del>  The client identifier string size is left undefined by this specification.  The client should avoid making assumptions about the

Reviewer comments:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Revised text:
2.1.  <ins> OAuth 2.1 defines two client types based on their ability to authenticate securely with the authorization server. </ins>  <ins> Clients that have credentials with the AS are designated as "confidential clients" </ins> Clients without credentials are called "public clients" Any clients with credentials MUST take precautions to prevent leakage and abuse of their credentials. <ins> Client authentication allows an Authorization Server to ensure it interacts with a certain client (identified by its "client_id") in an OAuth flow.  This might by the pre-requisite to use client policy and metadata in the course of processing this flow.  For example, the Authorization Server may show the trustworthy client name in user consent or allow access to certain functions as defined in the respective's client policy. Whether and how an Authorization server validates the identity of a client or the party providing/operating this client is out of scope of this specification. </ins> Authorization servers SHOULD consider the level of confidence in a  <ins> client's identity when deciding whether they allow a client access to certain resource servers or critical functions, such as the Client Credentials grant type. </ins> A single "client_id" MUST NOT be treated as more than one type of client.  This specification has been designed around the following client profiles:  <ins> A web application is a client running on a web server.  Resource owners access the client via an HTML user interface rendered in a user agent on the device used by the resource owner.  The client credentials as well as any access tokens issued to the client are stored on the web server and are not exposed to or accessible by the resource owner. A browser-based application is a client in which the client code is downloaded from a web server and executes within a user agent (e.g., web browser) on the device used by the resource owner. Protocol data and credentials are easily accessible (and often visible) to the resource owner.  If such applications shall use client credentials, it is recommended to utilize the backend for frontend pattern.  Since such applications reside within the user agent, they can make seamless use of the user agent capabilities when requesting authorization. A native application is a client installed and executed on the device used by the resource owner.  Protocol data and credentials are accessible to the resource owner.  It is assumed that any client authentication credentials included in the application can be extracted.  If such applications shall use client credentials, it is recommended to utilize the backend for frontend pattern. Dynamically issued credentials such as access tokens or refresh tokens can receive an acceptable level of protection.  At a minimum, these credentials are protected from hostile servers with which the application may interact.  On some platforms, these credentials might be protected from other applications residing on the same device. </ins> 2.2.  <ins> Every client is identified in the context of an authorization server by a client identifier - a unique string representing the registration information provided by the client.  The Authorization Server may itself issue the client identifier, it may also serve clients whose client identifier was issued by a trusted third party. The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication.  The client identifier is unique in the context of an authorization server. </ins> The client identifier string size is left undefined by this specification.  The client should avoid making assumptions about the