Original text:
This document defines the following extension code point. A client which supports this document SHALL send an empty <del> "delegated_credential" extension in its ClientHello. If the extension is present, the server MAY send a DelegatedCredential extension.  If the extension is not present, the server MUST NOT send a credential.  A credential MUST NOT be provided unless a Certificate message is also sent. When negotiating TLS 1.3, and using Delegated credentials, the server MUST send the DelegatedCredential as an extension in the CertificateEntry of its end-entity certificate.  When negotiating TLS 1.2, the DelegatedCredential MUST be sent as an extension in the ServerHello. The DelegatedCredential contains a signature from the public key in </del>  the end-entity certificate using a signature algorithm advertised by the client in the "signature_algorithms" extension.  Additionally, the credential's public key MUST be of a type that enables at least than 7 days. Verify that the certificate has the DelegationUsage extension, <del> which permits the use of Delegated credentials. </del>  Use the public key in the server's end-entity certificate to verify the signature on the credential. deemed invalid.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.  If successful, the client uses the public key in the credential to <del> verify a signature provided in the handshake: in particular, the </del>  CertificateVerify message in TLS 1.3 and the ServerKeyExchange in 1.2.

Reviewer comments:
These came up when I implemented the extension in Go (URL) and I think would be useful to add to the standard.
looks good to me

Revised text:
This document defines the following extension code point. A client which supports this document SHALL send an empty  <ins> "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client SHOULD abort with an "unexpected_message" alert. If the extension is present, the server MAY send a delegated credential extension.  If the extension is not present, the server MUST NOT send a credential.  A credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, and using delegated credentials, the server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions with any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. The delegated credential contains a signature from the public key in </ins> the end-entity certificate using a signature algorithm advertised by the client in the "signature_algorithms" extension.  Additionally, the credential's public key MUST be of a type that enables at least than 7 days. Verify that the certificate has the DelegationUsage extension,  <ins> which permits the use of delegated credentials. </ins> Use the public key in the server's end-entity certificate to verify the signature on the credential. deemed invalid.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.  If successful, the client uses the public key in the credential to  <ins> verify the signature provided in the handshake: in particular, the </ins> CertificateVerify message in TLS 1.3 and the ServerKeyExchange in 1.2.