Hi UTA list,
I rarely post here, but I would like to a very individual opinion for
once. Please feel free to ignore.
If you inherit JSON-LD (as part of VC) from W3C, then... why bother? Web
Token Claims in the IETF and JSON-LD fragments in the W3C are a clear
demarcation line between the work of the two SDO, currently.
Viele Grüße,
Henk
On 20.02.24 14:25, Orie Steele wrote:
Chair hat off,
I'm not sure if authors will agree with this characterization, but I
will give it anyway, and authors can correct me:
Why use VCs?
Because of the CBOR toolchain.
You should comment on if the payload is JSON-LD, if it is, then you lose
most of the value of CBOR in my view.
Why use DIDs?
Alternative PKI, similar to "let's encrypt" or a private pki...
More of the interesting part comes from "properties of different PKIs",
which translate to "properties of DID Methods" in this document.
It's worth being upfront about the energy cost / censorship trade offs
for the different possible solutions here.
There is also a phenomenon in "blockchain (aka verifiable data
registry)" where infrastructure can be single use or multi-use.
In the case that a specific ledger is used for payments, it can also be
used for key distribution, or routing, for example:
https://datatracker.ietf.org/doc/draft-mcbride-rtgwg-bgp-blockchain/
<https://datatracker.ietf.org/doc/draft-mcbride-rtgwg-bgp-blockchain/>
Of course this draft is not about payments or routing, but it is about
key distribution and TLS, and delivering those capabilities alongside
places that might already rely on a specific technology for routing or
payments... at least that is how I see it :)
Regards,
OS
On Tue, Feb 20, 2024 at 2:51 AM Andrea Vesco
<andrea.ve...@linksfoundation.com
<mailto:andrea.ve...@linksfoundation.com>> wrote:
Thanks for the comment. The I-D describes how to add VCs as a
certificate type in TLS while maintaining the interoperability with
other certificates. The aim is to move SSI-based authentication from
the application layer down to TLS without changing the way SSI and
TLS work. The SSI model (based on the use of VC [0] and DIDs [1])
specifies the use of DLT (or more generally Verifiable Data
Registry) to store and retrieve public keys. We will clarify this
point in the abstract and introduction of the next version.
Andrea Vesco
[0] https://www.w3.org/TR/vc-data-model-2.0/
<https://www.w3.org/TR/vc-data-model-2.0/>
[1] https://www.w3.org/TR/did-core/ <https://www.w3.org/TR/did-core/>
> On 19 Feb 2024, at 13:40, Yanlei(Ray) <ray.yan...@huawei.com
<mailto:ray.yan...@huawei.com>> wrote:
>
> The motivation for your design needs to be described in the draft.
> Why do you want to put the public key in the distributed ledger?
>
> Lei YAN
>
> -----Original Message-----
> From: Uta <uta-boun...@ietf.org <mailto:uta-boun...@ietf.org>> On
Behalf Of Andrea Vesco
> Sent: Monday, February 19, 2024 4:57 PM
> To: uta@ietf.org <mailto:uta@ietf.org>
> Subject: [Uta] New I-D on VC and TLS
>
> L.Perugini and I have written an I-D on the use of Verifiable
Credential (VC) as a new means of authentication in TLS. We think
it might be of interest and in the scope of the UTA WG.
>
> Could you please give us your opinion?
>
> Draft
> Datatracker
https://datatracker.ietf.org/doc/draft-vesco-vcauthtls/
<https://datatracker.ietf.org/doc/draft-vesco-vcauthtls/>
> Github
https://github.com/Cybersecurity-LINKS/draft-vesco-vcauthtls
<https://github.com/Cybersecurity-LINKS/draft-vesco-vcauthtls>
>
> Kind Regards,
> Andrea Vesco
> _______________________________________________
> Uta mailing list
> Uta@ietf.org <mailto:Uta@ietf.org>
> https://www.ietf.org/mailman/listinfo/uta
<https://www.ietf.org/mailman/listinfo/uta>
_______________________________________________
Uta mailing list
Uta@ietf.org <mailto:Uta@ietf.org>
https://www.ietf.org/mailman/listinfo/uta
<https://www.ietf.org/mailman/listinfo/uta>
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
