Code change:
additional information.  The format of the encoded identity is defined by the application. <del> For an X.509 credential, each entry in the chain represents a single DER-encoded X.509 certificate.  The chain is ordered such that the first entry (chain[0]) is the end-entity certificate and each subsequent certificate in the chain MUST be the issuer of the previous certificate.  The public key encoded in the "subjectPublicKeyInfo" of the end-entity certificate MUST be identical to the "signature_key" in the LeafNode containing this credential. </del> <ins> For an X.509 credential, each entry in the "certificates" field represents a single DER-encoded X.509 certificate.  The chain is ordered such that the first entry (chain[0]) is the end-entity certificate.  The public key encoded in the "subjectPublicKeyInfo" of the end-entity certificate MUST be identical to the "signature_key" in the LeafNode containing this credential.  A chain MAY omit any non-leaf certificates that supported peers are known to already possess. </ins> 5.3.1.

Related discussion:
text: For example, if you use OpenSSL to validate the chain it does not take a chain as input. It takes a collection of certificates, a set of trusted root certs, and the leaf you want to validate. I believe not making this change has a higher complexity.
I'm sorry I missed this previously, but this requirement was a source of trouble in TLS and was removed in RFC 8446, which allows extra certificates in the middle. Was there a conscious decision to be more strict here.
I don't recall this ever being discussed. I think it was just added and nobody ever objected.
NAME can you elaborate a little bit? The way I read it the requirement is just that there is a valid signature chain, i.e. that one certificate signs the next and so on.
NAME - I deliberately reverted to the original TLS level of strictness here, in hopes that in starting over with a new ecosystem we could reset things to a cleaner state. Do you think there are legitimate reasons for violating the strict rule, or is it just a common misconfiguration in TLS servers? I would not really be inclined to accommodate the latter. NAME - I believe what NAME is envisioning are cases where there are multiple valid chains, say via old and new versions of an intermediate certificate. So you might do something like provide a "chain" of the form (leaf, oldintermediate, newintermediate), with the idea that the client could verify using whichever one makes it happy.
NAME take a look at the comment I left on the PR. I can see your point about starting over as being valid, but one thing that also caught my eye in the TLS RFC was language around allowing a root CA to be left out of the chain since those could potentially already exist in a local trust store.
I see. Thanks NAME for the clarification. Maybe we can phrase it in such a way that whatever the credential includes (added intermediary certificates or left-out root certificates) in the end the local client MUST be able to create a continuous certificate chain from the leaf to the root. Do we need to define how the client does that? Since we're already pushing everything else related to authentication into the AS, I'm inclined to say no.