Original text:
(*) indicates changes to the wire protocol.  draft-02 Change public key type. (*) working key for the TLS handshake. As detailed in delegated-credentials, the delegated credential is <del> cryptographically bound to the end-entity certificate and the protocol in which the credential may be used.  This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the protocol is explicitly disallowed. </del>  Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot. <del> Each delegated credential is bound to a specific version of TLS and signature algorithm.  This prevents them from being used for other protocols or with other signature algorithms than service owner allows. </del>  2.2. SignatureScheme is as defined in RFC8446.  This is expected to be the same as CertificateVerify.algorithm sent by the server. <del> The version of TLS in which the credential will be used, where the type ProtocolVersion is as defined in RFC8446.  This is expected to match the protocol version that is negotiated by the client and server. </del> The credential's public key, a DER-encoded X690 SubjectPublicKeyInfo as defined in RFC5280. The signature effectively binds the credential to the parameters of the handshake in which it is used.  In particular, it ensures that <del> credentials are only used with the certificate, protocol, and signature algorithm chosen by the delegator.  Minimizing their semantics in this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials. </del>  The code changes to create and verify delegated credentials would be localized to the TLS stack, which has the advantage of avoiding Verify that expected_cert_verify_algorithm matches the scheme indicated in the server's CertificateVerify message. <del> Verify that expected_version matches the protocol version indicated in the server's "supported_versions" extension. </del> Verify that the end-entity certificate satisfies the conditions specified in certificate-requirements.

Reviewer comments:
As discussed in URL and subsequent.
I have responded to the two comments. No idea why CI is busted.
looks like the CI segfaulted :) I'll manually test locally and merge
Please add yourself to acknowledgements as well. remove change in line 192 as well "Each delegated credential is bound to a specific version of TLS and signature". somehow i cant comment on changes that you haven't made. Dear TLS WG, While we were implementing delegated credentials we came up with the following two problems. I thank David Benjamin for communicating the first to me. The first is that a delegated credential is pinned to a particular version of TLS. Unfortunately this means that the rollout of a new version of TLS (which libraries consider that they can do on their own) makes an existing set of delegated credentials unusable, and the signer of delegated credentials needs to accept a new version of TLS as valid before the extension can be used with a new version. This is similar to the issues prompting draft-wood-tls-external-psk-importer-00 where PSKs depend on negotiated parameters, and thus are difficult to use in practice. The second is that the DelegatedCredential indicates the algorithm that was used to sign it. Someone who is a bit careless when implementing might take that literally with the result that they verify a DelegatedCredential with RSA algorithm and the certificate is really an ECDSA certificate. I'll submit a PR with text for security considerations/rewording the verification steps. Sincerely, Watson

Revised text:
(*) indicates changes to the wire protocol. <ins> draft-03 Remove protocol version from the Credential structure. (*) </ins> draft-02 Change public key type. (*) working key for the TLS handshake. As detailed in delegated-credentials, the delegated credential is  <ins> cryptographically bound to the end-entity certificate with which the credential may be used.  This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the protocol is explicitly disallowed. </ins> Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot.  <ins> Each delegated credential is bound to a specific signature algorithm.  This prevents them from being used with other, unintended, signature algorithms. </ins> 2.2. SignatureScheme is as defined in RFC8446.  This is expected to be the same as CertificateVerify.algorithm sent by the server.  The credential's public key, a DER-encoded X690 SubjectPublicKeyInfo as defined in RFC5280. The signature effectively binds the credential to the parameters of the handshake in which it is used.  In particular, it ensures that  <ins> credentials are only used with the certificate and signature algorithm chosen by the delegator.  Minimizing their semantics in this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials. </ins> The code changes to create and verify delegated credentials would be localized to the TLS stack, which has the advantage of avoiding Verify that expected_cert_verify_algorithm matches the scheme indicated in the server's CertificateVerify message.  Verify that the end-entity certificate satisfies the conditions specified in certificate-requirements.