Code change:
4. <del> To perform client authentication using this scheme, the client instance uses the following parameter values and encodings. </del> <ins> This draft introduces the concept of client attestations to the OAuth 2 protocol, using two JWTs: a Client Attestation and a Client Attestation Proof of Possession (PoP).  These JWTs are transmitted via HTTP headers in an HTTP request from a Client Instance to an Authorization Server or Resource Server.  The primary purpose of these headers is to authenticate the Client Instance. </ins> <del> The value of the "client_assertion_type" parameter (as defined in RFC7521) set to "urn:ietf:params:oauth:client-assertion-type:jwt- client-attestation". </del> <ins> 4.1. </ins> <del> The value of the "client_assertion" parameter (as defined in RFC7521) set to a value containing two JWTs, separated by a '~' character.  It MUST NOT contain more or less than precisely two JWTs separated by the '~' character.  The first JWT MUST be the client attestation JWT defined in client-attestation-jwt, the second JWT MUST be the client attestation PoP defined in client-attestation-pop-jwt. </del> <ins> A Client Attestation JWT and Client Attestation PoP JWT is included in an HTTP request using the following request header fields. </ins> <del> The following example demonstrates client authentication using this scheme during the presentation of an authorization code grant in an access token request (with extra line breaks for display purposes only): </del> <ins> The following is an example of the OAuth-Client-Attestation header. </ins> <del> 4.1. </del> <ins> The following is an example of the OAuth-Client-Attestation-PoP header. </ins> <del> In order to authenticate the client using this scheme, the authorization server MUST validate BOTH the JWTs present in the "client_assertion" parameter according to the criteria below. </del> <ins> Note that per RFC9110 header field names are case-insensitive; so OAUTH-CLIENT-ATTESTATION, oauth-client-attestation, etc., are all valid and equivalent header field names.  Case is significant in the header field value, however. The OAuth-Client-Attestation and OAuth-Client-Attestation-PoP HTTP header field values uses the token68 syntax defined in Section 11.2 of RFC9110 (repeated below for ease of reference). </ins> It is RECOMMENDED that the authorization server validate the Client Attestation JWT prior to validating the Client Attestation PoP. <del> 4.1.1. </del> <ins> 4.2. </ins> <del> The following rules apply to validating the client attestation JWT. </del> <ins> The following rules apply to validating the Client Attestation JWT. </ins> Application of additional restrictions and policy are at the <del> discretion of the authorization server. </del> <ins> discretion of the Authorization Server. </ins> The JWT MUST contain an "iss" (issuer) claim that contains a unique identifier for the entity that issued the JWT.  In the

Related discussion:
text: I do believe there should be a discussion about terminology (attestation vs assertion) as it seems to create quite a bit of confusion, but I do think a different issue/PR is better suited for that. Minor nit: Client Attestation seems to be used in lower and upper case somewhat inconsistently. Should every usage be upper case (e.g., also client attestation mechanism)?