POST and Body are used in figures 12 and 13 but never specified in the text. Preferably add some text with a reference to the corresponding RFC.
The initial knowledge of the participants of the protocol in figures 12 and 13 needs to be explicitly specified. For example, which authentic public keys are already known at the beginning of the protocol.
The trust relationships between the participants of the protocol in figures 12 and 13 needs to be explicitly specified. For example, the Verifier is trusted by the Client and Server in figures 12 and 13, respectively.
Extensions such as evidence_request and evidence_request should be distinguished by the standard TLS notation+ from the TLS messages.
The meaning of TLS handshake covering all the entities should be clarified. For example, isn't there typically a separate TLS connection between the Client and Verifier in Figure 12?
The two cases discussed on 19.02 should be separately described.
Some issues about Figure 12 and Figure 13:
POSTandBodyare used in figures 12 and 13 but never specified in the text. Preferably add some text with a reference to the corresponding RFC.evidence_requestandevidence_requestshould be distinguished by the standard TLS notation+from the TLS messages.TLS handshakecovering all the entities should be clarified. For example, isn't there typically a separate TLS connection between the Client and Verifier in Figure 12?