Code change:
Abstract This specification defines a new method of client authentication for <del> OAuth2 RFC6749 by extending the approach defined in RFC7521.  This </del> <ins> OAuth 2.0 RFC6749 by extending the approach defined in RFC7521.  This </ins> new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization <del> server through an attested key based authentication scheme. </del> <ins> server through an attestation based authentication scheme. </ins> 1. RFC7521 defines a way for a client to include an assertion in a token request to an authorization server for the purposes of client authentication.  This specification extends this mechanism to provide <del> a way for a client instance to authenticate it self with the authorization server through an attested key based authentication scheme. </del> <ins> a way for a client instance to authenticate itself with the authorization server through assertion that is bound to a public key (for proof of possession).  This assertion is designated as Client Attestation. The Authorization Server will communicate its requirements for the attestation scheme through its metadata.  A Client instance that wants to request an access token from this Authorization Server will need to obtain a Client Attestation JWT from its client backend first.  Therefore the client will generate an key (Client Instance Key) and (platform specific) attestations to proof its genuinity and security to the client backend.  The Client instance sends this data to the client backend in request for a Client Attestation JWT.  If the Client Backend successfully validates the Client Instance Key and further data, it will generate a signed Client Attestation JWT.  As the Client Attestation JWT is cryptographically bound to the Client Instance Key generated by the client, the attestation is bound to this particular client instance.  The client backend will respond to the client's request by sending the Client Attestation JWT.  The client can proceed and generate a Client Attestation Proof of Possession (PoP) for the Client Instance Key. Lastly, the client sends both the Client Attestation JWT and the Client Attestation PoP with the Token Request to the Authorization Server.  The Authorization Server will validate the client attestation and thus authenticates the client.  The Authorization Server may continue to issue sender-constrained access tokens using DPoP. </ins> The following diagram depicts the conceptual interactions. <del> Note defining the protocol for steps 2 and 4, including how the client instance authenticates with the client backend is out of scope of this specification. </del> <ins> Note that the data and protocols used for requesting and sending a Client Attestation JWT (steps 2 and 4) and how the client instance authenticates with the client backend is out of scope of this specification. </ins> <del> This specification only defines the format of the client assertion that a client instance uses to authenticate in its interactions with an authorization server (indicated in step 6), which is comprised of two key parts: </del> <ins> This specification only defines the format of the Client Assertion JWT that a client instance uses to authenticate in its interactions with an authorization server (indicated in step 6), which is comprised of two key parts: </ins> <del> A client key attestation - produced by the client backend. </del> <ins> A Client Attestation JWT- produced by the client backend. </ins> <del> A client key attestation proof of possession (PoP) - produced by the client instance. </del> <ins> A Client Attestation Proof of Possession (PoP) - produced by the client instance. </ins> 2.

Related discussion:
text: 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.