Original text:
3.  To perform client authentication using this scheme, the client instance uses the following parameter values and encodings. The value of the "client_assertion_type" is <del> "urn:ietf:params:oauth:client-assertion-type:jwt-key-attestation". </del>  The value of the "client_assertion" parameter contains two JWTs, separated by a '~' character.  It MUST NOT contain more or less than <del> precisely two JWTs seperated by the '~` character.  The first JWT MUST be the client key attestation JWT defined in client-key- attestation-jwt, the second JWT MUST the client key attestation PoP defined in client-key-attestation-pop-jwt. </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> 3.1. </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. It is RECOMMENDED that the authorization server validate the Client <del> Key Attestation prior to validating the Client Key Attestation PoP. </del>  <del> 3.1.1. </del>  <del> The following rules apply to validating the client key attestation JWT.  Application of additional restrictions and policy are at the </del>  discretion of the authorization server. The JWT MUST contain an "iss" (issuer) claim that contains a

Reviewer comments:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Revised text:
3. <ins> Client Attestation JWT A JSON Web Token (JWT) generated by the client backend that authenticates the client instance. Client Attestation Proof of Possession (PoP) A Proof of Possession generated by the client instance for the key that is used in the Client Attestation JWT. Client Instance Key A cryptographic, asymmetric key generated by the client instance and proven to the client backend.  The public key is contained in the Client Attestation JWT and is used to sign the Client Attestation Proof of Possession 4. </ins> To perform client authentication using this scheme, the client instance uses the following parameter values and encodings. The value of the "client_assertion_type" is  <ins> "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation". </ins> The value of the "client_assertion" parameter contains two JWTs, separated by a '~' character.  It MUST NOT contain more or less than  <ins> precisely two JWTs seperated by the '~' character.  The first JWT MUST be the client attestation JWT defined in client-attestation-jwt, the second JWT MUST the client attestation PoP defined in client- attestation-pop-jwt. </ins> 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):  <ins> 4.1. </ins> 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. It is RECOMMENDED that the authorization server validate the Client  <ins> Attestation JWT prior to validating the Client Attestation PoP. </ins>  <ins> 4.1.1. </ins>  <ins> The following rules apply to validating the client attestation JWT. Application of additional restrictions and policy are at the </ins> discretion of the authorization server. The JWT MUST contain an "iss" (issuer) claim that contains a