Hi Andrea

thanks for the extra background.


How do you plan to deal with the large number of DID methods?
Standardization of many of the DID methods has not been finished and
they appear to have vastly different security properties, even for the
most basic DID methods like did:web and did:key. It sounds difficult to
accomplish interoperability in such a flexible system.


Ciao
Hannes


Am 05.04.2024 um 12:12 schrieb Andrea Vesco:
Hi Hannes, thanks for your question.

We are referring to a (well-resourced) IoT system with edge computing nodes. In 
the IoT/edge segment, the VC can be used for mutual authentication directly in 
TLS to avoid the only option available today: first establish a TLS channel 
with X.509 based server-only authentication and, second, authenticate the 
client with its VC on top of the TLS channel. The Client authentication at the 
application layer works well, but in our opinion, only in web scenarios.
In addition, using the client_certificate_type and server_certificate_type 
extensions would also enable the option of hybrid (VC - X.509) mutual 
authentication in the edge/cloud segment at the TLS layer.
In our opinion, this is an incremental approach to support the adoption of VC 
and DID technologies in IoT systems.

Best, Andrea


On 4 Apr 2024, at 12:29, hannes.tschofe...@gmx.net wrote:

Hi Andrea,

Thanks for sharing the info.

Could you say a bit more about your IoT use case?

Ciao
Hannes

-----Original Message-----
From: TLS <tls-boun...@ietf.org> On Behalf Of Andrea Vesco
Sent: Donnerstag, 4. April 2024 10:53
To: tls@ietf.org
Subject: [TLS] I-D on TLS authentication with VC

L. Perugini and I have written an I-D on the use of Verifiable Credentials 
[1][2] as an additional authentication mode in TLS.  We presented the I-D to 
the ALLDISPATCH WG during IETF119 and the outcome was to explore the potential 
interest of the TLS WG. The I-D proposes to add (i) a new Certificate Type 
called VC in addition to X509 and RawPublicKey to the existing 
client_certificate_type and server_certificate_type extensions and (ii) a new 
extension called did_methods to carry the list of DID Methods supported by the 
endpoint to resolve the peer's DID during the validation of the Verifiable 
Credential. The I-D focuses on the IoT use case.

We are aware of the current discussion in the working group about new code 
points and would like to know your opinion in the case of this I-D and to 
explore the possible interest. Thank you in advance for your feedback.

I-D: https://datatracker.ietf.org/doc/draft-vesco-vcauthtls/
Code:
- Provider https://github.com/Cybersecurity-LINKS/openssl-ssi-provider
- OpenSSL https://github.com/Cybersecurity-LINKS/openssl

[1] https://www.w3.org/TR/vc-data-model-2.0/
[2] https://www.w3.org/TR/did-core/

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to