Re: VC formats

Hi,
Am 20. März 2024, 03:51 +0100 schrieb Kaliya Identity Woman <kaliya@identitywoman.net>:
> We didn't include  JSON-LD secured by SD-JWT which we knew of at least one vendor doing at the time we wrote the report.
>
> We covered the main formats that were "in market" and that were in some coherent spec.
>
> I will say about the report it covers The core components are all explained and the data model choices (JSON / JSON-LD / CBOR) and the "how we secure it" (JWT, SD-JWT, mDOC, Linked Data Signatures)
>
> If you really want to see all possible data format and signature combinations this chart was created out of IIW sessions. In the Credential Comparison Matrixhttps://docs.google.com/spreadsheets/d/1Z4cYfjbbE-rABcfC-xab8miocKLomivYMUFibOh9BVo/edit#gid=1590639334

FYI

The Credential Comparison Matrix has found a home at the OpenWallet Foundation. It is now maintained by the Credential Format Comparison Special Interest Group.

https://github.com/openwallet-foundation/credential-format-comparison-sig

https://openwallet-foundation.github.io/credential-format-comparison-sig/

best regards,
Torsten.
>
> - Kaliya
>
>
> On Tue, Mar 19, 2024 at 7:37 PM Kim Hamilton <kimdhamilton@gmail.com> wrote:
> > Thanks Kaliya, I don't see some of the flavors mentioned in the report, but they post-date the report. I'll link to things to be precise.
> >
> > Here's what I understand:
> > Secure Patterns for Internet Credentials (SPICE) is one group at IETF working on VCs: https://datatracker.ietf.org/group/spice/about/SD-JWT-VC is also at IETF: https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/I'm curious if/how those are related. And also if there are any other groups working on VC formats people are aware of.
> >
> > On Tue, Mar 19, 2024 at 6:19 PM Kaliya Identity Woman <kaliya@identitywoman.net> wrote:
> > > Lucy and I have written two reports explaining this landscape of formats and signatures.
> > >
> > > Here is the first one and infographic during the pandemic:
> > > https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdfhttps://www.lfph.io/wp-content/uploads/2021/04/Verifiable-Credentials-Flavors-Explained-Infographic.pdf
> > > This was written last year
> > > https://medium.com/@identitywoman-in-business/new-paper-and-infographic-on-flavors-of-digital-credentials-released-b9b6ec5b95afhttps://drive.google.com/file/d/1mZVcGlcxAqQaOr-pBUt6-Amh2NocuaNp/view
> > > - Kaliya
> > >
> > >
> > > On Tue, Mar 19, 2024 at 5:42 PM Kim Hamilton <kimdhamilton@gmail.com> wrote:
> > > > Right, in the base media type. But SD-JWT describes a mechanism for performing SD on JSON. It would be good to have a more transparent mechanism to allow anchoring statements in something reference-able. It seems a bit muddy now. Perhaps DIF, CCG, OIDF, and more can collaborate on some rubric here.
> > > >
> > > > On Tue, Mar 19, 2024 at 5:35 PM Orie Steele <orie@transmute.industries> wrote:
> > > > > The VCDM is JSON-LD, and both JSON and RDF do not support selective disclosure in their base media types.
> > > > >
> > > > > SD-JWT only supports selective disclosure on JSON.
> > > > >
> > > > > ECDSA-SD only supports selective disclosure in JSON-LD (I think).
> > > > >
> > > > > MDoc only supports selective disclosure of in CBOR.
> > > > >
> > > > > There are basically 2 ways to secure media types... You can secure them in a media type agnostic manner, like JWS or COSE Sign1. Or you can secure them in a media type aware manner, like JWT, SD-JWT, mDoc, SD-CWT etc.
> > > > >
> > > > > The W3C VCDM is a media type that is built on +ld+json meaning it's always JSON-LD that you are securing... Regardless of how you secure it.
> > > > >
> > > > > OS
> > > > >
> > > > > On Wed, Mar 20, 2024, 10:27 AM Kim Hamilton <kimdhamilton@gmail.com> wrote:
> > > > > > Thanks for stating it clearly. This is why the statement "VCDM lacks selective disclosure" trips the brain wires. It belongs at the signature/proof level. And of course, selective disclosure can be performed in different ways. Just wondering if I missed the boat on any considerations that make the credential data model itself more or less conducive to selective disclosure, which that statement appears to say.
> > > > > >
> > > > > > Or maybe it refers to a specific brand of selective disclosure, and not selective disclosure in the general sense.
> > > > > >
> > > > > > Does SD-JWT-VC imply a landscape in which there will be a different VC format for each signature suite? This is very different from my mental model of VC data model, with the possibility of using different signature suites. I'd be eager to learn more about the advantages of that.
> > > > > >
> > > > > > On Tue, Mar 19, 2024 at 5:10 PM Orie Steele <orie@transmute.industries> wrote:
> > > > > > > Selective disclosure is a property of the securing format, not the data model.
> > > > > > >
> > > > > > > Sd-jwt and ecdsa-sd both support selective disclosure, but with very different performance and security trade offs.
> > > > > > >
> > > > > > > It's not correct to say that CBOR, YAML, JSON, XML or JSON-LD support selective disclosure.
> > > > > > >
> > > > > > > It is correct to say SD-JWT, SD-CWT, mDoc, goridan envelopes or ecdsa-sd support selective disclosure.
> > > > > > >
> > > > > > > It seems jades as a requirement precludes the use of CBOR or Data Integrity Proofs, or even JWT, given JWTs are always compact (no JSON Serialization).
> > > > > > >
> > > > > > > OS
> > > > > > >
> > > > > > > On Wed, Mar 20, 2024, 9:53 AM Kim Hamilton <kimdhamilton@gmail.com> wrote:
> > > > > > > > Hi all,
> > > > > > > > I'm trying to get my head around the variety of VC formats. I ran across this deck and I'm curious why it would say VCDM lacks selective disclosure (included screenshot and deck). It does via signature suites, so in a sense the statement "does not compute".
> > > > > > > >
> > > > > > > > Eager to learn about the new VC formats, similarities and differences.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Kim
> > > > > > > > <Screenshot 2024-03-19 at 4.36.16 PM.png>

Received on Wednesday, 20 March 2024 08:23:53 UTC