Skip to content

Commit

Permalink
Script updating gh-pages from 183db7a. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Nov 22, 2023
1 parent 8c9ffe8 commit b65ecba
Show file tree
Hide file tree
Showing 2 changed files with 44 additions and 27 deletions.
26 changes: 15 additions & 11 deletions draft-vesco-vcauthtls.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1033,7 +1033,7 @@
</tr></thead>
<tfoot><tr>
<td class="left">Vesco, et al.</td>
<td class="center">Expires 24 May 2024</td>
<td class="center">Expires 25 May 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1046,12 +1046,12 @@
<dd class="internet-draft">draft-vesco-vcauthtls-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2023-11-21" class="published">21 November 2023</time>
<time datetime="2023-11-22" class="published">22 November 2023</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2024-05-24">24 May 2024</time></dd>
<dd class="expires"><time datetime="2024-05-25">25 May 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1108,7 +1108,7 @@ <h2 id="name-status-of-this-memo">
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 24 May 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 25 May 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1215,11 +1215,11 @@ <h2 id="name-copyright-notice">
<h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
</h2>
<p id="section-1-1">The Self-Sovereign Identity (SSI) is a decentralised identity model that gives a node control over the data it uses to generate and prove its identity. SSI model relies on three fundamental elements: a distributed ledger as the Root of Trust (RoT) for public keys, Decentralized IDentifier <a href="https://www.w3.org/TR/did-core/">DID</a>, and Verifiable Credential <a href="https://www.w3.org/TR/vc-data-model-2.0/">VC</a>. An SSI aware node builds his identity starting from generating the identity key pair ($sk, pk$). Then the node stores $pk$ in the distributed ledger of choice for other nodes to authenticate it.
A node's DID is a pointer to the distributed ledger where other nodes can retrieve its $pk$. A DID is a Uniform Resource Identifier (URI) in the form <em>did:did-method-name:method-specific-id</em> where <em>method-name</em> is the name of the <a href="https://www.w3.org/TR/did-core/">DID Method</a> used to interact with the distributed ledger and <em>method-specific-id</em> is the pointer to the <a href="https://www.w3.org/TR/did-core/">DID Document</a> that contains $pk$, stored in the distributed ledger.
<p id="section-1-1">The Self-Sovereign Identity (SSI) is a decentralised identity model that gives a node control over the data it uses to generate and prove its identity. SSI model relies on three fundamental elements: a distributed ledger as the Root of Trust (RoT) for public keys, Decentralized IDentifier <a href="https://www.w3.org/TR/did-core/">DID</a>, and Verifiable Credential <a href="https://www.w3.org/TR/vc-data-model-2.0/">VC</a>. An SSI aware node builds his identity starting from generating the identity key pair (<em>sk</em>, <em>pk</em>). Then the node stores <em>pk</em> in the distributed ledger of choice for other nodes to authenticate it.
A node's DID is a pointer to the distributed ledger where other nodes can retrieve its <em>pk</em>. A DID is a Uniform Resource Identifier (URI) in the form <em>did:did-method-name:method-specific-id</em> where <em>method-name</em> is the name of the <a href="https://www.w3.org/TR/did-core/">DID Method</a> used to interact with the distributed ledger and <em>method-specific-id</em> is the pointer to the <a href="https://www.w3.org/TR/did-core/">DID Document</a> that contains <em>pk</em>, stored in the distributed ledger.
After that, the node 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 node and the signature of the Issuer.
The combination of the key pair ($sk, pk$), the DID and at least one VC forms the identity compliant with the SSI model.
A node requests access to services by presenting a Verfiable Presentation <a href="https://www.w3.org/TR/vc-data-model-2.0/">VP</a>. The VP is an envelop of the VC signed by the node holding the VC with its $sk$. The verifier authenticates the node checking the authenticity of the VP and the validity and authenticity of the inner VC before granting or denying access to the requesting node.
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.
A node requests access to services by presenting a Verfiable Presentation <a href="https://www.w3.org/TR/vc-data-model-2.0/">VP</a>. The VP is an envelop of the VC signed by the node holding the VC with its <em>sk</em>. The verifier authenticates the node checking the authenticity of the VP and the validity and authenticity of the inner VC before granting or denying access to the requesting node.

The current implementations of the authentication process run at the Application layer. A client node estabhlishes a TLS channel authenticating the server node with the server's X.509 certificate. Then the server node authenticate the client node that sends its VP at application layer (i.e. over the TLS channel already established). The mutual authentication with VPs occours when also the server node exchange its VP with the client node again at application layer.<a href="#section-1-1" class="pilcrow"></a></p>
<p id="section-1-2">SSI is emerging as an identity option for Internet of Thing and Edge nodes in computing continuum environments. In these scenarios, (mutual) authentication with VP can take place directly at the TLS protocol layer, enabling the the peer-to-peer interaction model envisaged by the SSI model.
Expand Down Expand Up @@ -1371,7 +1371,7 @@ <h3 id="name-certificate">
<h3 id="name-certificate-verify">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-certificate-verify" class="section-name selfRef">Certificate Verify</a>
</h3>
<p id="section-5.5-1">As discussed in <span><a href="#introduction" class="internal xref">Section I</a> (<a href="#introduction" class="auto internal xref">Section 1</a>)</span>, a Holder wraps its own Verifiable Credential into a Verifiable Presentation and signs it before presenting it to a Verifier for authentication purposes in accordance with SSI model. When the selected certificate type is VC, the subsequent CertificateVerify message acts also as the Holder signature on the Verifiable Presentation. In fact, the signature is computed over the transcript hash that contains also the Verifiable Credential of the sender inside the Certificate message.<a href="#section-5.5-1" class="pilcrow"></a></p>
<p id="section-5.5-1">As discussed in <a href="#introduction" class="auto internal xref">Section 1</a>, a Holder wraps its own Verifiable Credential into a Verifiable Presentation and signs it before presenting it to a Verifier for authentication purposes in accordance with SSI model. When the selected certificate type is VC, the subsequent CertificateVerify message acts also as the Holder signature on the Verifiable Presentation. In fact, the signature is computed over the transcript hash that contains also the Verifiable Credential of the sender inside the Certificate message.<a href="#section-5.5-1" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand Down Expand Up @@ -1417,6 +1417,10 @@ <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">This example 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 expresses its capability to process a Verifiable Credential or an X.509 certificate from the server. In addition, it expresses the capability to be authenticated with an X.509 certificate by the server and sends the <code>did_methods</code> extension with the list of DID Methods of its choice.
The server selects the Verifiable Credential to authenticate with the client and X.509 certificate for client authentication. Then, the server sends the CertificateRequest message.
The server sends its Verifiable Credential and the client its X.509 certificate into their respective Certificate messages.<a href="#section-6.4-1" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand All @@ -1433,7 +1437,7 @@ <h2 id="name-security-considerations">
<h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
</h2>
<p id="section-8-1">This document has no IANA actions..<a href="#section-8-1" class="pilcrow"></a></p>
<p id="section-8-1">To be addressed<a href="#section-8-1" class="pilcrow"></a></p>
</section>
</div>
<div id="sec-normative-references">
Expand All @@ -1458,7 +1462,7 @@ <h2 id="name-normative-references">
<h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
</h2>
<p id="appendix-A-1">TODO acknowledge.<a href="#appendix-A-1" class="pilcrow"></a></p>
<p id="appendix-A-1">To be done.<a href="#appendix-A-1" class="pilcrow"></a></p>
</section>
</div>
<div id="authors-addresses">
Expand Down
45 changes: 29 additions & 16 deletions draft-vesco-vcauthtls.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,9 @@
WG Working Group A. Vesco
Internet-Draft L. Perugini
Intended status: Informational LINKS Foundation
Expires: 24 May 2024 N. Tuveri
Expires: 25 May 2024 N. Tuveri
Tampere University
21 November 2023
22 November 2023


Transport Layer Security (TLS) Authentication with Verifiable Credential
Expand Down Expand Up @@ -55,7 +55,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 May 2024.
This Internet-Draft will expire on 25 May 2024.

Copyright Notice

Expand Down Expand Up @@ -106,24 +106,24 @@ Table of Contents
Decentralized IDentifier DID (https://www.w3.org/TR/did-core/), and
Verifiable Credential VC (https://www.w3.org/TR/vc-data-model-2.0/).
An SSI aware node builds his identity starting from generating the
identity key pair ($sk, pk$). Then the node stores $pk$ in the
identity key pair (_sk_, _pk_). Then the node stores _pk_ in the
distributed ledger of choice for other nodes to authenticate it. A
node's DID is a pointer to the distributed ledger where other nodes
can retrieve its $pk$. A DID is a Uniform Resource Identifier (URI)
can retrieve its _pk_. A DID is a Uniform Resource Identifier (URI)
in the form _did:did-method-name:method-specific-id_ where _method-
name_ is the name of the DID Method (https://www.w3.org/TR/did-core/)
used to interact with the distributed ledger and _method-specific-id_
is the pointer to the DID Document (https://www.w3.org/TR/did-core/)
that contains $pk$, stored in the distributed ledger. After that,
that contains _pk_, stored in the distributed ledger. After that,
the node 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 node and
the signature of the Issuer. The combination of the key pair ($sk,
pk$), the DID and at least one VC forms the identity compliant with
the signature of the Issuer. The combination of the key pair (_sk_,
_pk_), the DID and at least one VC forms the identity compliant with
the SSI model. A node requests access to services by presenting a
Verfiable Presentation VP (https://www.w3.org/TR/vc-data-model-2.0/).
The VP is an envelop of the VC signed by the node holding the VC with
its $sk$. The verifier authenticates the node checking the
its _sk_. The verifier authenticates the node checking the
authenticity of the VP and the validity and authenticity of the inner
VC before granting or denying access to the requesting node. The
current implementations of the authentication process run at the
Expand Down Expand Up @@ -324,11 +324,11 @@ Table of Contents

5.5. Certificate Verify

As discussed in Section I (Section 1), a Holder wraps its own
Verifiable Credential into a Verifiable Presentation and signs it
before presenting it to a Verifier for authentication purposes in
accordance with SSI model. When the selected certificate type is VC,
the subsequent CertificateVerify message acts also as the Holder
As discussed in Section 1, a Holder wraps its own Verifiable
Credential into a Verifiable Presentation and signs it before
presenting it to a Verifier for authentication purposes in accordance
with SSI model. When the selected certificate type is VC, the
subsequent CertificateVerify message acts also as the Holder
signature on the Verifiable Presentation. In fact, the signature is
computed over the transcript hash that contains also the Verifiable
Credential of the sender inside the Certificate message.
Expand Down Expand Up @@ -379,11 +379,24 @@ Table of Contents
6.4. Mutual authentication with Client using X.509 Certificate and
Server using Verifiable Credential

This example 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 expresses its
capability to process a Verifiable Credential or an X.509 certificate
from the server. In addition, it expresses the capability to be
authenticated with an X.509 certificate by the server and sends the
did_methods extension with the list of DID Methods of its choice.
The server selects the Verifiable Credential to authenticate with the
client and X.509 certificate for client authentication. Then, the
server sends the CertificateRequest message. The server sends its
Verifiable Credential and the client its X.509 certificate into their
respective Certificate messages.

7. Security Considerations

8. IANA Considerations

This document has no IANA actions..
To be addressed

9. Normative References

Expand All @@ -398,7 +411,7 @@ Table of Contents

Acknowledgments

TODO acknowledge.
To be done.

Authors' Addresses

Expand Down

0 comments on commit b65ecba

Please sign in to comment.