Re: Questions regarding VC 2.0 document

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> 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
>