From b65ecba65d05c1dbc76f11b6c1190c8c4e64ee7c Mon Sep 17 00:00:00 2001 From: ID Bot Date: Wed, 22 Nov 2023 09:29:16 +0000 Subject: [PATCH] Script updating gh-pages from 183db7a. [ci skip] --- draft-vesco-vcauthtls.html | 26 ++++++++++++---------- draft-vesco-vcauthtls.txt | 45 ++++++++++++++++++++++++-------------- 2 files changed, 44 insertions(+), 27 deletions(-) diff --git a/draft-vesco-vcauthtls.html b/draft-vesco-vcauthtls.html index 86f5ca3..864dc88 100644 --- a/draft-vesco-vcauthtls.html +++ b/draft-vesco-vcauthtls.html @@ -1033,7 +1033,7 @@ Vesco, et al. -Expires 24 May 2024 +Expires 25 May 2024 [Page] @@ -1046,12 +1046,12 @@
draft-vesco-vcauthtls-latest
Published:
- +
Intended Status:
Informational
Expires:
-
+
Authors:
@@ -1108,7 +1108,7 @@

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.

@@ -1417,6 +1417,10 @@

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.

@@ -1433,7 +1437,7 @@

8. IANA Considerations

-

This document has no IANA actions..

+

To be addressed

@@ -1458,7 +1462,7 @@

Acknowledgments

-

TODO acknowledge.

+

To be done.

diff --git a/draft-vesco-vcauthtls.txt b/draft-vesco-vcauthtls.txt index fff8761..98b06de 100644 --- a/draft-vesco-vcauthtls.txt +++ b/draft-vesco-vcauthtls.txt @@ -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 @@ -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 @@ -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 @@ -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. @@ -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 @@ -398,7 +411,7 @@ Table of Contents Acknowledgments - TODO acknowledge. + To be done. Authors' Addresses