Re: Questions regarding VC 2.0 document

Hi Dimitri and Patrick,

Thank you for your responses! We have a lot to think about, once again.

best,
Stefannie
________________________________
From: Patrick St-Louis <patrick.st-louis@idlab.org>
Sent: Wednesday, October 25, 2023 12:25 AM
To: dzagidulin@gmail.com <dzagidulin@gmail.com>
Cc: ステファニー　タン（SBIホールディングス） <tstefan@sbigroup.co.jp>; W3C Credentials CG <public-credentials@w3.org>
Subject: Re: Questions regarding VC 2.0 document

For multiple proof, another use case would be to have 2 signatures, each allowing different cryptographic features such as zkp/selective disclosure.

On Tue, Oct 24, 2023 at 11:21 AM Dmitri Zagidulin <dzagidulin@gmail.com<mailto:dzagidulin@gmail.com>> wrote:
Hi Stephanie, great questions.

1. (re JSON-LD) So, the main value proposition to JSON-LD is basically extensibility. What do I mean by that? It allows your JSON objects to have property names that are globally unique (because they're URLs). And also, in the best case, each property is self-documenting (a developer can go to that URL and see exactly what was meant by that field). (I talk about this in my blog post, Understanding Linked Data.<https://medium.com/@codenamedmitri/understanding-linked-data-91b31ba544ec>)
And why is extensibility important? Because VC 2.0 is just the data model for the credential /envelope/, most implementers will need to come up with their own VC payloads (define new credential types). And there's only two basic mechanisms to do that in an interoperable fashion -- you can register the types and claims in a central registry somewhere. Or you can create and publish a @context, which essentially serves as a decentralized namespace and registry.

You mentioned that one of the benefits might be preserving the data structure. That's more the domain of JSON Schemas (see the Data Schemas<https://w3c.github.io/vc-data-model/#data-schemas> section of the VC DM 2.0 spec), and it makes a lot of sense to use both JSON Schemas and JSON-LD @contexts together.
Incidentally.

The other main benefit to JSON-LD with regards to VCs specifically, is that it enables you to deterministically convert the VC between JSON, CBOR, YAML etc formats, while the signature remains the same. (This is not a very common requirement or use case -- usually done for compression reasons, but I thought I'd mention it).

2. (multiple proofs) There are a couple of reasons to include multiple proofs.
One is, multi-signature scenarios. (Meaning, multiple parties need to sign the VC, either using threshold signatures (N of M, etc), or just "everyone in the C-Suite has signed this important VC representing a company decision" kind of things).

And the other is - key formats. For example, if you're an issuer, and you know that one of your intended consumer audiences only supports Ed25519 type keys, but another consumer only supports RSA keys, then you can create two signatures -- one with your RSA key and one with your Ed25519 key, so that both parties can verify easily.

Dmitri


On Tue, Oct 24, 2023 at 6:04 AM ステファニー　タン（SBIホールディングス） <tstefan@sbigroup.co.jp<mailto:tstefan@sbigroup.co.jp>> wrote:
Hi, we have questions about some items in the VC 2.0 document (21 october 2023 version)

  1.  We assume that one good reason to use JSON-LD is the ability to be able to preserve data structure by using @context. Are there other reasons?
  2.
In Example 17（https://www.w3.org/TR/vc-data-model-2.0/#example-basic-structure-of-a-presentation）, it appears that we can include more than 1 proof. We would like to ask the reason for this decision?


Thank you for any advice!

Best regards,
Stefannie Tan