Skip to content

Commit

Permalink
Script updating gh-pages from 32b695d. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Dec 13, 2023
1 parent 4c0b589 commit 0cfa4d0
Show file tree
Hide file tree
Showing 2 changed files with 39 additions and 29 deletions.
42 changes: 24 additions & 18 deletions draft-vesco-vcauthtls.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1223,8 +1223,10 @@ <h2 id="name-introduction">
An entity's DID is a pointer to the distributed ledger where other entities can retrieve its <em>pk</em>. A DID is a Uniform Resource Identifier (URI) in the form <code>did:did-method-name:method-specific-id</code> where <code>method-name</code> is the name of the <span>[<a href="#DID" class="cite xref">DID</a>]</span> Method used to interact with the distributed ledger and <code>method-specific-id</code> is the pointer to the <span>[<a href="#DID" class="cite xref">DID</a>]</span> Document that contains <em>pk</em>, stored in the distributed ledger.
After that, the entity can request a VC from one of the Issuers available in the system. The VC contains the metadata to describe properties of the credential, the DID and the claims about the identity of the entity and the signature of the Issuer.
The combination of the key pair (<em>sk</em>, <em>pk</em>), the DID and at least one VC forms the identity compliant with the SSI model.
An entity requests access to services by presenting a Verifiable Presentation <span>[<a href="#VP" class="cite xref">VP</a>]</span>. The VP is an envelop of the VC signed by the entity holding the VC with its <em>sk</em>. The verifier authenticates the entity checking the validity and authenticity of the VP and the inner VC before granting or denying access to the requesting entity.<a href="#section-1-1" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-1-2">
An entity requests access to services by presenting a Verifiable Presentation <span>[<a href="#VP" class="cite xref">VP</a>]</span>. The VP is an envelop of the VC signed by the entity holding the VC with its <em>sk</em>. The verifier authenticates the entity checking the validity and authenticity of the VP and the inner VC before granting or denying access to the requesting entity. <a href="#fig-ssi-steps" class="auto internal xref">Figure 1</a> shows step by step the generation of the identity and the authentication with VP.<a href="#section-1-1" class="pilcrow"></a></p>
<span id="name-generation-of-the-identity-"></span><div id="fig-ssi-steps">
<figure id="figure-1">
<div class="alignCenter art-text artwork" id="section-1-2.1">
<pre>
--------
| Entity |
Expand All @@ -1248,7 +1250,11 @@ <h2 id="name-introduction">
| Entity | ----------------&gt; | Verifier | ----------------&gt; | DLT |
| | &lt;---------------- | | &lt;---------------- | |
-------- ok/ko ---------- pk -----
</pre><a href="#section-1-2" class="pilcrow"></a>
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-generation-of-the-identity-" class="selfRef">Generation of the identity compliant with the SSI model and authentication with VP</a>
</figcaption></figure>
</div>
<p id="section-1-3">The current implementations of the authentication process run at the application layer. A client estabhlishes a TLS channel authenticating the server with the server's X.509 certificate. Then the server authenticates the client that sends its VP at application layer (i.e. over the TLS channel already established). The mutual authentication with VPs occurs when also the server exchanges its VP with the client again at application layer.<a href="#section-1-3" class="pilcrow"></a></p>
<p id="section-1-4">SSI is emerging as an identity option for Internet of Thing and Edge devices in computing continuum environments. In these scenarios, (mutual) authentication with VP can take place directly at the TLS protocol layer, enabling the peer-to-peer interaction model envisaged by the SSI model.
Expand Down Expand Up @@ -1347,9 +1353,9 @@ <h2 id="name-did_methods-extension">
<h2 id="name-tls-client-and-server-hands">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-tls-client-and-server-hands" class="section-name selfRef">TLS Client and Server Handshake</a>
</h2>
<p id="section-5-1"><a href="#fig-full-handshake" class="auto internal xref">Figure 1</a> shows the message flow for full TLS handshake.<a href="#section-5-1" class="pilcrow"></a></p>
<p id="section-5-1"><a href="#fig-full-handshake" class="auto internal xref">Figure 2</a> shows the message flow for full TLS handshake.<a href="#section-5-1" class="pilcrow"></a></p>
<span id="name-message-flow-for-full-tls-h"></span><div id="fig-full-handshake">
<figure id="figure-1">
<figure id="figure-2">
<div class="alignCenter art-text artwork" id="section-5-2.1">
<pre>
DLT Client Server DLT
Expand Down Expand Up @@ -1391,7 +1397,7 @@ <h2 id="name-tls-client-and-server-hands">
derived from [sender]_application_traffic_secret_N.
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-message-flow-for-full-tls-h" class="selfRef">Message Flow for full TLS Handshake</a>
</figcaption></figure>
</div>
Expand Down Expand Up @@ -1466,12 +1472,12 @@ <h2 id="name-tls-handshake-examples">
<h3 id="name-server-authentication-with-">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-server-authentication-with-" class="section-name selfRef">Server authentication with Verifiable Credential</a>
</h3>
<p id="section-6.1-1">The example in <a href="#fig-server-vc" class="auto internal xref">Figure 2</a> shows a TLS 1.3 handshake with server authentication. The client sends the <code>server_certificate_type</code> extension indicating both <code>VC</code> and <code>X.509</code> certificate types. In addition, the client sends the <code>did_methods</code> extension with the list of supported DID Methods. The client does not own an identity at the TLS level, therefore omits the <code>client_certificate_type</code> extension.
<p id="section-6.1-1">The example in <a href="#fig-server-vc" class="auto internal xref">Figure 3</a> shows a TLS 1.3 handshake with server authentication. The client sends the <code>server_certificate_type</code> extension indicating both <code>VC</code> and <code>X.509</code> certificate types. In addition, the client sends the <code>did_methods</code> extension with the list of supported DID Methods. The client does not own an identity at the TLS level, therefore omits the <code>client_certificate_type</code> extension.
The server selects <code>VC</code> certificate type, sends the EncryptedExtensions message with
the <code>server_certificate_type</code> extension set to VC, and sends its Verifiable Credential into the Certificate message.
After receiving the <code>CertificateVerify</code> and <code>Finished</code> messages, the client resolves the server's DID to retrieve the server <em>pk</em> and authenticate it.<a href="#section-6.1-1" class="pilcrow"></a></p>
<span id="name-tls-server-uses-verifiable-"></span><div id="fig-server-vc">
<figure id="figure-2">
<figure id="figure-3">
<div class="alignCenter art-text artwork" id="section-6.1-2.1">
<pre>
DLT Client Server
Expand All @@ -1492,7 +1498,7 @@ <h3 id="name-server-authentication-with-">
[Application Data] &lt;-------&gt; [Application Data]
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-tls-server-uses-verifiable-" class="selfRef">TLS Server Uses Verifiable Credential</a>
</figcaption></figure>
</div>
Expand All @@ -1503,12 +1509,12 @@ <h3 id="name-server-authentication-with-">
<h3 id="name-mutual-authentication-with-">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-mutual-authentication-with-" class="section-name selfRef">Mutual authentication with Verifiable Credentials</a>
</h3>
<p id="section-6.2-1">The example in <a href="#fig-mutual-vc" class="auto internal xref">Figure 3</a> shows a TLS 1.3 handshake with mutual authentication where both client and server authenticate the peer using Verifiable Credentials.
<p id="section-6.2-1">The example in <a href="#fig-mutual-vc" class="auto internal xref">Figure 4</a> shows a TLS 1.3 handshake with mutual authentication where both client and server authenticate the peer using Verifiable Credentials.
The client sends the <code>server_certificate_type</code> extension indicating both <code>VC</code> and <code>X.509</code> certificate types along with the <code>did_methods</code> extension containing the list of supported DID Methods. The client also sends the <code>client_certificate_type</code> extension indicating its capability to provide both a Verifiable Credential and an X.509 certificate.
The server sends the <code>server_certificate_type</code> set to <code>VC</code>, the <code>client_certificate_type</code> set to <code>VC</code> and the <code>CertificateRequest</code> message with the <code>did_methods</code> extension containig a set of DID Methods in common with the client. Client and server send their Verifiable Credential into their respective <code>Certificate</code> messages.
After receiving the <code>CertificateVerify</code> and <code>Finished</code> messages, the client and then the server resolve the peer's DID to retrieve the associated <em>pk</em> and authenticate each other.<a href="#section-6.2-1" class="pilcrow"></a></p>
<span id="name-tls-client-and-tls-server-u"></span><div id="fig-mutual-vc">
<figure id="figure-3">
<figure id="figure-4">
<div class="alignCenter art-text artwork" id="section-6.2-2.1">
<pre>
DLT Client Server DLT
Expand Down Expand Up @@ -1538,7 +1544,7 @@ <h3 id="name-mutual-authentication-with-">
[Application Data] &lt;-------&gt; [Application Data]
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-tls-client-and-tls-server-u" class="selfRef">TLS Client and TLS Server Use Verifiable Credentials</a>
</figcaption></figure>
</div>
Expand All @@ -1549,12 +1555,12 @@ <h3 id="name-mutual-authentication-with-">
<h3 id="name-mutual-authentication-with-c">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-mutual-authentication-with-c" class="section-name selfRef">Mutual authentication with Client using Verifiable Credential and Server using X.509 Certificate</a>
</h3>
<p id="section-6.3-1">The example in <a href="#fig-mutual-vc-x509" class="auto internal xref">Figure 4</a> shows a TLS 1.3 handshake with mutual authentication that combines the use of Verifiable Credential and X.509 certificate. The client uses a Verifiable Credential, and the server uses an X.509 certificate.
<p id="section-6.3-1">The example in <a href="#fig-mutual-vc-x509" class="auto internal xref">Figure 5</a> shows a TLS 1.3 handshake with mutual authentication that combines the use of Verifiable Credential and X.509 certificate. The client uses a Verifiable Credential, and the server uses an X.509 certificate.
The client sends the <code>server_certificate_type</code> extension indicating <code>X.509</code> certificate types. The client also sends the <code>client_certificate_type</code> extension indicating its capability to provide both a Verifiable Credential and an X.509 certificate.
The server sends the <code>server_certificate_type</code> set to <code>X.509</code>, the <code>client_certificate_type</code> set to <code>VC</code> and the <code>CertificateRequest</code> message with the <code>did_methods</code> extension containig the set of suported DID Methods. The server sends its X.509 certificate and the client its Verifiable Credential into their respective <code>Certificate</code> messages.
After receiving the <code>CertificateVerify</code> and <code>Finished</code> messages, the server resolves the client DID to retrieve the client <em>pk</em> and authenticate it.<a href="#section-6.3-1" class="pilcrow"></a></p>
<span id="name-tls-client-uses-a-verifiabl"></span><div id="fig-mutual-vc-x509">
<figure id="figure-4">
<figure id="figure-5">
<div class="alignCenter art-text artwork" id="section-6.3-2.1">
<pre>
Client Server DLT
Expand All @@ -1581,7 +1587,7 @@ <h3 id="name-mutual-authentication-with-c">
[Application Data] &lt;-------&gt; [Application Data]
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-tls-client-uses-a-verifiabl" class="selfRef">TLS Client Uses a Verifiable Credential and TLS Server Uses an X.509 Certificate</a>
</figcaption></figure>
</div>
Expand All @@ -1592,12 +1598,12 @@ <h3 id="name-mutual-authentication-with-c">
<h3 id="name-mutual-authentication-with-cl">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-mutual-authentication-with-cl" class="section-name selfRef">Mutual authentication with Client using X.509 Certificate and Server using Verifiable Credential</a>
</h3>
<p id="section-6.4-1">The example in <a href="#fig-mutual-x509-vc" class="auto internal xref">Figure 5</a> complements the previous one showing a TLS 1.3 handshake with mutual authentication where the client uses X.509 certificate and the server a Verifiable Credential.
<p id="section-6.4-1">The example in <a href="#fig-mutual-x509-vc" class="auto internal xref">Figure 6</a> complements the previous one showing a TLS 1.3 handshake with mutual authentication where the client uses X.509 certificate and the server a Verifiable Credential.
The client sends the <code>server_certificate_type</code> extension indicating both <code>VC</code> and <code>X.509</code> certificate types along with the <code>did_methods</code> extension containing the list of supported DID Methods. The client also sends the <code>client_certificate_type</code> extension indicating its capability to provide only an X.509 certificate.
The server sends the <code>server_certificate_type</code> set to <code>VC</code>, the <code>client_certificate_type</code> set to <code>X.509</code> and the <code>CertificateRequest</code> message. The server sends its Verifiable Credential, and the client its X.509 certificate into their respective <code>Certificate</code> messages.
After receiving the <code>CertificateVerify</code> and <code>Finished</code> messages, the client resolves the server's DID to retrieve the server <em>pk</em> and authenticate the client.<a href="#section-6.4-1" class="pilcrow"></a></p>
<span id="name-tls-client-uses-an-x509-cer"></span><div id="fig-mutual-x509-vc">
<figure id="figure-5">
<figure id="figure-6">
<div class="alignCenter art-text artwork" id="section-6.4-2.1">
<pre>
DLT Client Server
Expand All @@ -1624,7 +1630,7 @@ <h3 id="name-mutual-authentication-with-cl">
[Application Data] &lt;-------&gt; [Application Data]
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-tls-client-uses-an-x509-cer" class="selfRef">TLS Client Uses an X.509 Certificate and TLS Server Uses a Verifiable Credential</a>
</figcaption></figure>
</div>
Expand Down
26 changes: 15 additions & 11 deletions draft-vesco-vcauthtls.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -124,7 +124,8 @@ Table of Contents
of the VC signed by the entity holding the VC with its _sk_. The
verifier authenticates the entity checking the validity and
authenticity of the VP and the inner VC before granting or denying
access to the requesting entity.
access to the requesting entity. Figure 1 shows step by step the
generation of the identity and the authentication with VP.

--------
| Entity |
Expand All @@ -149,6 +150,9 @@ Table of Contents
| | <---------------- | | <---------------- | |
-------- ok/ko ---------- pk -----

Figure 1: Generation of the identity compliant with the SSI model and
authentication with VP

The current implementations of the authentication process run at the
application layer. A client estabhlishes a TLS channel
authenticating the server with the server's X.509 certificate. Then
Expand Down Expand Up @@ -277,7 +281,7 @@ Table of Contents

5. TLS Client and Server Handshake

Figure 1 shows the message flow for full TLS handshake.
Figure 2 shows the message flow for full TLS handshake.

DLT Client Server DLT

Expand Down Expand Up @@ -317,7 +321,7 @@ Table of Contents
[] Indicates messages protected using keys
derived from [sender]_application_traffic_secret_N.

Figure 1: Message Flow for full TLS Handshake
Figure 2: Message Flow for full TLS Handshake

5.1. ClientHello message

Expand Down Expand Up @@ -413,7 +417,7 @@ Table of Contents

6.1. Server authentication with Verifiable Credential

The example in Figure 2 shows a TLS 1.3 handshake with server
The example in Figure 3 shows a TLS 1.3 handshake with server
authentication. The client sends the server_certificate_type
extension indicating both VC and X.509 certificate types. In
addition, the client sends the did_methods extension with the list of
Expand Down Expand Up @@ -443,11 +447,11 @@ Table of Contents
{Finished} -------->
[Application Data] <-------> [Application Data]

Figure 2: TLS Server Uses Verifiable Credential
Figure 3: TLS Server Uses Verifiable Credential

6.2. Mutual authentication with Verifiable Credentials

The example in Figure 3 shows a TLS 1.3 handshake with mutual
The example in Figure 4 shows a TLS 1.3 handshake with mutual
authentication where both client and server authenticate the peer
using Verifiable Credentials. The client sends the
server_certificate_type extension indicating both VC and X.509
Expand Down Expand Up @@ -490,12 +494,12 @@ Table of Contents
==========>
[Application Data] <-------> [Application Data]

Figure 3: TLS Client and TLS Server Use Verifiable Credentials
Figure 4: TLS Client and TLS Server Use Verifiable Credentials

6.3. Mutual authentication with Client using Verifiable Credential and
Server using X.509 Certificate

The example in Figure 4 shows a TLS 1.3 handshake with mutual
The example in Figure 5 shows a TLS 1.3 handshake with mutual
authentication that combines the use of Verifiable Credential and
X.509 certificate. The client uses a Verifiable Credential, and the
server uses an X.509 certificate. The client sends the
Expand Down Expand Up @@ -534,13 +538,13 @@ Table of Contents
==========>
[Application Data] <-------> [Application Data]

Figure 4: TLS Client Uses a Verifiable Credential and TLS Server
Figure 5: TLS Client Uses a Verifiable Credential and TLS Server
Uses an X.509 Certificate

6.4. Mutual authentication with Client using X.509 Certificate and
Server using Verifiable Credential

The example in Figure 5 complements the previous one showing a TLS
The example in Figure 6 complements the previous one showing a TLS
1.3 handshake with mutual authentication where the client uses X.509
certificate and the server a Verifiable Credential. The client sends
the server_certificate_type extension indicating both VC and X.509
Expand Down Expand Up @@ -578,7 +582,7 @@ Table of Contents
{Finished} -------->
[Application Data] <-------> [Application Data]

Figure 5: TLS Client Uses an X.509 Certificate and TLS Server
Figure 6: TLS Client Uses an X.509 Certificate and TLS Server
Uses a Verifiable Credential

7. Security Considerations
Expand Down

0 comments on commit 0cfa4d0

Please sign in to comment.