Code change:
Backend origin servers may then use the "Client-Cert" header field of the request to determine if the connection from the client to the TTRP was mutually-authenticated and, if so, the certificate thereby <del> presented by the client. Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </del> <ins> presented by the client.  Access control decisions based on the client certificate (or lack thereof) can be conveyed by selecting response content as appropriate or with an HTTP 403 response, if the certificate is deemed unacceptable for the given context.  Note that TLS clients that rely on error indications at the TLS layer for an unacceptable certificate will not receive those signals. </ins> When the value of the "Client-Cert" request header field is used to select a response (e.g., the response content is access-controlled),

Related discussion:
text: The problem is TLS alerts tear down the connection, so this would be very disruptive in HTTP/2, where we may have other requests multiplexed. (The TLS-level mechanism does not have this problem because it happens in connection setup.) Modify clients to interpret HTTP error as TLS error The other option is to define an HTTP error and pass it through to the client. However, that means this draft is not only a proxy server protocol, but also changes HTTP clients. We would need to discuss the compatibility implications. Additionally, by introducing a brand new way to do client cert errors, we introduce some awkward quirks. Suppose the server sends a resource with subresources on the same origin. Unlike HTTP auth, client cert auth applies to the whole connection. There would be no way to fetch those subresources without re-triggering the auth prompt. Perhaps we include lots of warnings that the server need to keep all its error page resources inline or on a different origin? Perhaps we say the client should ignore the response and map the HTTP error to some network-level error page?
The use of post-handshake authentication is similarly fraught. I assume that you are looking to have a connection torn down if any certificate is not fit for purpose. Isn't that a bit of a blunt instrument? It makes the use of multiple certificates an interesting game: get one wrong and you lose. More so because the TLS-terminating proxy is the one that plays the game with the client the one that pays the price. My assumption was a far more narrowly scope scenario: The proxy asks for a certificate based on some condition it arranges with the origin server (this is proprietary and not our problem). The client provides a certificate with a signature. The proxy validates the signature and passes certificate information to the origin server with any requests (again, deciding which requests to annotate thus is proprietary). The origin server takes this information and authorizes requests, or not. That's it. The scope of the draft starts and ends at step 3 here. The holistic problem is that clients tend to stick to their choice of client certificate in the face of these HTTP errors, only changing their mind if TLS fails (with a specific subset of possible alerts). That seems like a poor design choice; a legacy of how HTTP/1.1 works and not suited to modern uses.