Change:
URL you don't want to provide one. TLS allows Certificate to be empty, with a missing CertificateVerify and Finished as normal. That would be a nice change. Alternatively, we could insist on the using application managing this, but it seems like an authenticated refusal is nice.
Resolved in PR

Discussion:
5. <ins> If, given an authenticator request, the endpoint does have an appropriate certificate or does not want to return one, it constructs an authenticated refusal called an empty authenticator.  This is an HMAC over the hashed authenticator transcript with a Certificate message containing no CertificateEntries and the CertificateVerify message omitted: "Hash(Handshake Context || authenticator request || Certificate) " The HMAC is computed using the same hash function using the Finished MAC Key as a key. 6. </ins> The creation and validation of both authenticator requests and authenticators SHOULD be implemented inside the TLS library even if it is possible to implement it at the application layer.  TLS

The following sections describes APIs that are considered necessary to implement exported authenticators.  These are informative only. <del> 5.1. </del> <ins> 6.1. </ins> The "request" API takes as input:

It returns an authenticator request, which is a sequence of octets that includes a CertificateRequest message. <del> 5.2. </del> <ins> 6.2. </ins> The "get context" API takes as input:

It returns the certificate_request_context. <del> 5.3. </del> <ins> 6.3. </ins> The "authenticate" takes as input:

an optional authenticator request or certificate_request_context (from 0 to 255 bytes) <del> It returns the exported authenticator as a sequence of octets. Ideally, the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library. Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. </del> <ins> It returns either the exported authenticator or an empty authenticator as a sequence of octets.  It is RECOMMENDED that the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library.  Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. </ins> It is also possible to implement this API outside of the TLS library using TLS exporters.  This may be preferable in cases where the application does not have access to a TLS library with these APIs or when TLS is handled independently of the application layer protocol. <del> 5.4. </del> <ins> 6.4. </ins> The "validate" API takes as input:

an authenticator <del> It returns the certificate chain and extensions. </del> <ins> It returns the certificate chain and extensions and a status to indicate whether the authenticator is valid or not.  If the authenticator was empty - that is, it did not contain a certificate - the certificate chain will contain no certificates. </ins> <del> 6. </del> <ins> 7. </ins> This document has no IANA actions. <del> 7. </del> <ins> 8. </ins> The Certificate/Verify/Finished pattern intentionally looks like the TLS 1.3 pattern which now has been analyzed several times.  In the