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: For starters, the provision of the certificate was successful, it's just that it was not the one that the server wanted. Tearing the connection down is too strong a response when you consider that HTTP/2 and HTTP/3 have multiple concurrent requests, some of which might be affected by a TLS alert that brings the whole session down. I really do think that client changes are the right choice here. Clients can treat 401 (Unauthorized) as a signal that the credentials offered (zero or more certificates) are not adequate. At that point, it's probably safe to treat the cached choice of certificate as not useful for the next certificate request that comes along. Post-handshake authentication allows them to add to the pile of certificates, not jeopardizing credentials that are working. For the proxy, if it decides that it needs to ask for more credentials from a client that doesn't do post-handshake auth'n, then a TLS alert is an option. It's probably the only realistic option as things stand today. I'd prefer GOAWAY with a code that indicates that a new connection with different credentials is appropriate. For NAME benefit, I don't see any of this as affecting the client-cert-field work as long as it makes its scope clear. That work can probably just note that a proxy probably has to tear down the connection to the client after a 401 response so that the client won't fixate on the wrong certificate. Pick an appropriate alert. I don't think we need to go into defining new signaling arrangements. I don't think that it is worth the effort of doing more to improve client certificate-based authentication, unless there is some general trend toward enabling post-handshake auth, at which point we can talk about choosing a better solution.
While acknowledging that and associated issues, the scope of the draft is only about conveying the client cert info and not any new error signaling or attempts at addressing the larger problems.
It might be nice to still have some text to still mention that server can send back 403 status codes, etc, if they don't like the client certs. Don't add any new mechanisms, but explain that errors can happen, and there are ways to express them today.
If the server sends back a 403 mechanism, would you expect clients to act on this? I'm not aware of any client today that uses HTTP error codes to inform client certificate selection.