From 4c1765bce0867f3ea5da7579b64cacab16e74656 Mon Sep 17 00:00:00 2001 From: perubeanie Date: Wed, 15 Nov 2023 18:32:11 +0100 Subject: [PATCH] Fix --- draft-vesco-vcauthtls.md | 24 ++++++++++++------------ full-hs.svg | 6 +++--- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/draft-vesco-vcauthtls.md b/draft-vesco-vcauthtls.md index fa440d6..aee48c4 100644 --- a/draft-vesco-vcauthtls.md +++ b/draft-vesco-vcauthtls.md @@ -143,7 +143,7 @@ struct { {{tls-full}} below shows the basic full TLS handshake: - +--> ![](full-hs.svg) @@ -212,7 +212,7 @@ Figures [x], [x] and [x] show some message-exchanges examples. This section shows an example that the client is willing to receive and validate a VC from the server. The client does not own an identity at the TLS level and so omits the client_cert_type extension. The server indicates in the EncryptedExtensions message that it selected a VC to insert in the Certificate message as depicted in Figure [X]. - +--> ![](srvr-vc.svg) @@ -240,7 +240,7 @@ Client -> Server : { Finished } This section shows an example where the TLS client as well as the TLS server use VCs as presented in figure [X]. In fact the server selects VC type for both client_cert_types and server_cert_types extensions and in the CertificateRequest message selects a set of DID methods both endpoints have in common. - +--> ![](mutual-vc.svg) @@ -272,7 +272,7 @@ Server --> DLT_B : DID Resolve This section shows an example combining the use of a raw public key and an X.509 certificate. The client uses a VC for client authentication, and the server provides an X.509 certificate. The client expresses its ability to process an X.509 certificate or a raw public key from the server. In addtion it is willing to use either VC or X.509 certificate for client-side authentication. The server then selects X.509 certificate to authenticate with the client and VC for client authentication. The server sends a list of its choice of DID methods. -