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

Hi Andrea,

 >  to avoid the only option available today:

That wonders me. I think, what is more in question is the comparison
of the new certficate type with the two currently used ones (x509 and
Raw Public Key). Reading your link, my first impression is, that this
is pretty similar to x509 but in json. So talking about "only option"
seems to be a little over done.

best regards
Achim

Am 05.04.24 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
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls