Change:
3. <del> This document defines the following extension code point. A client which supports this document SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client MUST 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 delegated credential.  A delegated credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.3 or later is negotiated. 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 to any other certificate. The delegated credential contains a signature from the public key in 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 one of the supported signature algorithms.  A delegated credential MUST NOT be negotiated by the server if its signature is not compatible with any of the supported signature algorithms or the credential's public key is not usable with the supported signature algorithms of the client, even if the client advertises support for delegated credentials. The SignatureScheme the server selects in the "signature_algorithms" extension MUST be that of the credential public key.  On receiving a credential and a certificate chain, the client validates the certificate chain and matches the end-entity certificate to the server's expected identity following its normal procedures.  It then takes the following steps: Verify that the current time is within the validity interval of the credential and that the credential's time to live is no more than 7 days. Verify that the end-entity certificate satisfies the conditions specified in Section certificate-requirements. Use the public key in the server's end-entity certificate to verify the signature of the credential. If one or more of these checks fail, then the delegated credential is 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 verify the signature in the serer's CertificateVerify message. 4. </del> While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is perfectly fine to use them to issue other signed objects as long as the certificate contains the <del> digitalSignature key usage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </del> <ins> digitalSignature KeyUsage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </ins> structure: Relative time in seconds from the beginning of the delegation

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