Original text:
When resuming via a PSK with an appropriate ticket (i.e., one with the "allow_early_data" flag), clients can also send data on their first flight ("early data").  This data is encrypted solely under <del> keys derived using the PSK as the static secret.  As shown in tls- 0-rtt, the Zero-RTT data is just added to the 1-RTT handshake in the first flight, the rest of the handshake uses the same messages. </del>  [[OPEN ISSUE: Should it be possible to combine 0-RTT with the server authenticating via a signature https://github.com/tlswg/tls13-spec/ A list of the identities (labels for keys) that the client is <del> willing to negotiate with the server. </del>  The server's chosen identity expressed as a (0-based) index into If the server selects a PSK cipher suite, it MUST send a "pre_shared_key" extension with the identity that it selected.  The client MUST verify that the server's selected_identity is within the <del> range supplied by the client.  If any other value is returned, the client MUST generate a fatal "unknown_psk_identity" alert and close the connection. </del>  6.3.2.6. [[OPEN ISSUE: are the rules below correct? https://github.com/tlswg/ tls13-spec/issues/451]] Prior to accepting the "early_data" <del> extension, the server MUST validate that the session ticket parameters are consistent with its current configuration.  It MUST also validate that the extensions negotiated in the previous </del>  connection are identical to those being negotiated in the ServerHello, with the exception of the following extensions:

Reviewer comments:
I would actually much rather we only offer one PSK identity since TLS 1.2 was perfectly fine offering just one and resumption has no use for offering multiple, but I suspect I will lose that fight. Absent that, at least make the protocol well-defined. Unlike both TLS 1.2 resumption and TLS 1.2 PSK, TLS 1.3 increases the state space and allows clients to offer multiple PSK identities. This mostly works, but 0-RTT presumes that only one is offered. Define 0-RTT to presume the first identity is selected and clarify that other shapes are possible due to the increased state space.

Revised text:
When resuming via a PSK with an appropriate ticket (i.e., one with the "allow_early_data" flag), clients can also send data on their first flight ("early data").  This data is encrypted solely under  <ins> keys derived using the first offered PSK as the static secret.  As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT handshake in the first flight, the rest of the handshake uses the same messages. </ins> [[OPEN ISSUE: Should it be possible to combine 0-RTT with the server authenticating via a signature https://github.com/tlswg/tls13-spec/ A list of the identities (labels for keys) that the client is  <ins> willing to negotiate with the server.  If sent alongside the "early_data" extension (see early-data-indication), the first identity is the one used for 0-RTT data. </ins> The server's chosen identity expressed as a (0-based) index into If the server selects a PSK cipher suite, it MUST send a "pre_shared_key" extension with the identity that it selected.  The client MUST verify that the server's selected_identity is within the  <ins> range supplied by the client.  If the server supplies an "early_data" extension, the client MUST verify that the server selected the first offered identity.  If any other value is returned, the client MUST generate a fatal "unknown_psk_identity" alert and close the connection. Note that, although 0-RTT data is encrypted with the first PSK identity, the server may fall back to 1-RTT and select a different PSK identity if multiple are offered. </ins> 6.3.2.6. [[OPEN ISSUE: are the rules below correct? https://github.com/tlswg/ tls13-spec/issues/451]] Prior to accepting the "early_data"  <ins> extension, the server MUST check the first PSK identity (see pre- shared-key-extension) corresponds to a valid ticket and validate that the session parameters are consistent with its current configuration. It MUST also validate that the extensions negotiated in the previous </ins> connection are identical to those being negotiated in the ServerHello, with the exception of the following extensions: