Re: [TLS] I-D on TLS authentication with VC

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.tschofenig@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-bounces@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
>>