Code change:
URL
IETF drafts are expected to not exceed 72 characters per line. The diagram in the Introduction currently takes 91

Related discussion:
text: The following diagram depicts the overall architecture and protocol flow. <del> The flow starts with the Authorization Server communicating its requirements for the client authentication to the client, made available in its metadata.  A Client instance that wants to request an access token from this Authorization Server needs to obtain a Client Attestation JWT, for example, from its client backend first. Therefore, the client generates a key (Client Instance Key) and (platform specific) attestations to prove its authenticity, integrity and security to the client backend (step 1).  The Client instance sends this data to the client backend in request for a Client Attestation JWT (step 2).  If the Client Backend successfully validates the Client Instance Key and further data, it generates a signed Client Attestation JWT (step 3).  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 responds to the client's request by sending the Client Attestation JWT (step 4). The client can proceed now and generate a Client Attestation Proof of Possession (PoP) for the Client Instance Key (step 5).  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 validates the client attestation and thus authenticates the client.  The Authorization Server may continue to issue sender-constrained access tokens using RFC9449. Note that the protocol for steps 2 and 4 and how the client instance authenticates with the client backend is out of scope of this </del> <ins> The following steps describe this OAuth flow: (1) The Client Instance generates a key (Client Instance Key) and optional further attestations (that are out of scope) to prove its authenticity to the Client Backend. (2) The Client Instance sends this data to the Client Backend in request for a Client Attestation JWT. (3) The Client Backend validates the Client Instance Key and optional further data.  It generates a signed Client Attestation JWT that is cryptographically bound to the Client Instance Key generated by the Client.  Therefore, the attestation is bound to this particular Client Instance. (4) The Client Backend responds to the Client Instance by sending the Client Attestation JWT. (5) The Client Instance generates a Proof of Possession (PoP) with the Client Instance Key. (6) The Client Instance sends both the Client Attestation JWT and the Client Attestation PoP JWT to the authorization server, e.g. within a token request.  The authorization server validates the Client Attestation and thus authenticates the Client Instance. Note that the protocol for steps (2) and (4) and how the Client Instance authenticates to the Client Backend is out of scope of this </ins> specification.  Note also that this specification can be utilized without the client having a backend server at all; in this case, each client instance will perform the functions described as being done by the backend for itself. This specification defines the format of the Client Attestation that <del> a client instance uses to authenticate in its interactions with an </del> <ins> a Client Instance uses to authenticate in its interactions with an </ins> authorization server, which is comprised of two key parts: A Client Attestation JWT - typically produced by the client