Change:
computed with the extended master secret RFC7627 to avoid key synchronization attacks. <del> The certificate to be used for authentication and any supporting certificates in the chain.  This structure is defined in TLS13, Section 4.4.2. </del> <ins> 4.2. An authenticator is formed from the concatenation of TLS 1.3 TLS13 Certificate, CertificateVerify, and Finished messages. If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator request.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  That is, the extensions received in a ClientHello (for servers), ServerHello (for clients in TLS 1.2), or EncryptedExtensions (for clients in TLS 1.3). 4.2.1. The certificate to be used for authentication and any supporting certificates in the chain.  This structure is defined in TLS13, Section 4.4.2. </ins> The certificate message contains an opaque string called certificate_request_context, which is extracted from the authenticator request if present.  If no authenticator request is provided, it is zero-length. <del> This message is used to provide explicit proof that an endpoint possesses the private key corresponding to its certificate. </del> <ins> The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version of TLS.  In particular, the certificate MUST be valid for the a signature algorithm indicated by the peer in a "signature_algorithms" extension, as described in Section 4.2.3 of TLS13 and Sections 7.4.2 and 7.4.6 of RFC5246. In addition to "signature_algorithms", the "server_name" RFC6066, "certificate_authorities" (Section 4.2.4. of TLS13), or "oid_filters" (Section 4.2.5. of TLS13) extensions are used to guide certificate selection.  These extensions are taken from the authenticator request if present, or the TLS handshake if not. Alternative certificate formats such as RFC7250 Raw Public Keys are not supported in this version of the specification. If an authenticator request was provided, the Certificate message MUST contain only extensions present in the authenticator request. Otherwise, the Certificate message MUST contain only extensions present in the TLS handshake. 4.2.2. This message is used to provide explicit proof that an endpoint possesses the private key corresponding to its certificate.  The definition for TLS 1.3 is: </ins> The algorithm field specifies the signature algorithm used (see Section 4.2.3 of TLS13 for the definition of this field).  The <del> signature is a digital signature using that algorithm.  The signature scheme MUST be a valid signature scheme for TLS 1.3.  This excludes all RSASSA-PKCS1-v1_5 algorithms and ECDSA algorithms that are not supported in TLS 1.3.  If an authenticator request is present, the signature algorithm MUST be chosen from one of the signature schemes in the authenticator request.  Otherwise, the signature algorithm used should be chosen from the "signature_algorithms" extension of the ClientHello used in the connection handshake. </del> <ins> signature is a digital signature using that algorithm. The signature scheme MUST be a valid signature scheme for TLS 1.3. This excludes all RSASSA-PKCS1-v1_5 algorithms and combinations of ECDSA and hash algorithms that are not supported in TLS 1.3. If an authenticator request is present, the signature algorithm MUST be chosen from one of the signature schemes in the authenticator request.  Otherwise, the signature algorithm used should be chosen from the "signature_algorithms" extension sent by the peer in the TLS handshake. </ins> The signature is computed using the over the concatenation of:

Discussion:
There are lots of changes here. I did stage this as separate commits to some extent, so feel free to cherry-pick. There is one maybe-technical change here. It wasn't clear about the precedence between handshake and authenticator request for extensions. I've chosen to be clear about this and say that if the authenticator request exists, then it is the only thing that matters. That's 8c0b166. I can drop that from the CL and do that separately if you prefer.
Thanks for the comments. The technical clarification you made is the correct one, the request supersedes the handshake for extension choices if present.