Change:
support for this mechanism. The server provides both the certificate chain terminating in its <del> certificate as well as the credential. </del> <ins> certificate as well as the delegated credential. </ins> The client uses information in the server's certificate to verify <del> the signature on the credential and verify that the server is asserting an expected identity. </del> <ins> the delegated credential and that the server is asserting an expected identity. </ins> The client uses the public key in the credential as the server's working key for the TLS handshake. <del> 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> <ins> As detailed in delegated-credentials, the delegated credential is 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. Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there is no mechanism for revoking it without revoking the certificate itself.  To limit exposure in case a delegated credential is compromised, servers may not issue credentials with a validity period longer than 7 days.  This mechanism is described in detail in client- and-server-behavior. </ins> It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage (RFC5280 section 4.2.1.3) In order to prevent this type of cross- protocol attack, we define a new DelegationUsage extension to X.509 <del> that permits use of delegated credentials.  Clients MUST NOT accept delegated credentials associated with certificates without this extension. Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there is no mechanism for revoking it without revoking the certificate itself.  To limit the exposure of a delegation credential compromise, servers MUST NOT issue credentials with a validity period longer than 7 days.  Clients MUST NOT accept credentials with longer validity periods. </del> <ins> that permits use of delegated credentials.  (See certificate- requirements.) </ins> 2.1.

Discussion:
Based on This adds a change log with changes from draft-01. It drops the proposed "must-use-DC" semantics from the X.509 extension. There doesn't seem to be a clean way to do this, and the complexity it adds seems to outweigh any potential benefit. The changes are as follows: Change DelegationUsage extension type to NULL. Drop support for TLS 1.2. Add the protocol version and credential signature algorithm to the Credential structure. () Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate.
Not sure why CI failed ... It's building fine on my end.
Back to you NAME :)
looks great to me