#860: Verifiable Credentials Data Model v2.0

Visit on Github.

Opened Jun 16, 2023

こんにちは TAG-さん!

As an editor, I'm requesting a TAG review of Verifiable Credentials Data Model v2.0.

The VCDM 2.0 specification provides a JSON-LD data model that enables the issuance, sharing, and verification of Verifiable Credentials and Verifiable Presentations in a secure and interoperable manner. These credentials provide a way for individuals, organizations, and other entities to digitally represent and share their qualifications, attributes, and/or other relevant information. Verifiable Credentials are designed to enhance trust, privacy, and control in digital interactions by allowing the owner of the credentials to control how their information is shared and verified.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: The VCWG is planning to take this specification to Candidate Recommendation in September 2023 (at W3C TPAC), reviews before that time frame (ideally, by the end of July 2023) would be ideal.
  • The group where the work on this specification is currently being done: W3C Verifiable Credentials Working Group
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): n/a (same group as above)
  • Major unresolved issues with or opposition to this specification:
    • Ongoing discussions about which terms should be designated as reserved properties in the VCDM, such as confidenceMethod, and which terms should be included in the core VCDM, such as termsOfUse.
    • Ongoing discussions on media type registration, with the possibility of additional clarifications being made regarding security mechanisms for verifiable credentials.
    • Ongoing discussions concerning normative statements related to proof.
    • Ongoing discussions about terminology, including whether there should be a distinction between a "credential" and a "verifiable credential."
    • Ongoing discussions regarding the normative aspects of context definition and vocabulary in the VCDM.
  • This work is being funded by: The members of the W3C VCWG that are actively participating in the development of these specifications including funding from the US Federal Government, the European Commission, and the Canadian Federal Government.

You should also know that...

  • This work relates heavily to the following specifications: Verifiable Credential Data Integrity, Securing Verifiable Credentials using JSON Web Tokens, which is also something that the TAG will be actively reviewing around the same time.
  • Major changes since VCDM v1.1:
    1. the VCDM defined JSON-LD explicitly as the base media type,
    2. securing mechanisms are now externalized in a new specification and no longer contained in the VCDM,
    3. besides JSON-LD and Data Integrity other representations are made possible by defining specific media types.
    4. v2.0 introduces breaking changes such as changing the context, vocabulary and definitions of certain terms such as validFrom and validUntil, as well as deprecation of other terms such as issuanceDate.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

☂️ open a single issue in our GitHub repo for the entire review

Discussions

2023-06-26

Minutes

Rossen: they are asking us for horizontal review. - Data model V2. Not triaged yet.

2023-11-27

Minutes

Dan: could we alert the group to possible objections ... ?

Hadley: are the objections likely to be architectural in nature?

Tess: when they originally did the VC data model... it's supposed to be JSON-LD - you can't feed it arbitrary JSON-LD - it will choke on certain cases... a compliant with the spec VC data model processor would "choke".

Amy: I've seen that before - I don't think it's necessary for the processor to process all JSON-LD - you can pick one "expanded, etc..."

Tess: suppose you have a non-vc-data model and you ...

Amy: you could tell the tool to serialize it in compact form...

Tess: I don't think that would be enough...

Amy: the prefixes are set in a context...

Hadley: sounds right but need to double-check... I'm wondering how much has already been covered in our discussion on data model 1.0? We closed that unsatisfied - that our concerns were not addressed...

Tess: we could see if the things we wanted addressed have been addressed...

Amy: the explainer for 2.0 has a summary of the changes made in "Important Design Choices".

Hadley: IIRC Dbaron had concerns about earlier versions supporting json-ld and json.. in Syntax Agility - they demonstrated that a JSON-LD processor is nor necessary.

Tess: I have concerns with that... the way they subset JSON-LD means you can't reliably use JSON-LD tooling and have the output remain compatible with VC... you have to write a VC specific serializer... But also - most implementations are JSON but it's weird JSON... context... If your tool chain and your partner's tool chain are just treating it as plain JSON and not checking it with a jsonld processor at some point there is likely to be bitrot, mistakes that get copied around...

Amy: since vc data model 1.0 has been out for 5 years... presumably the justification for 2.0 is that there are changes from 1.0. Could we ask about that that bitrot problem? They should have seen it in the wild by now?

Tess: it's a positive sign that they're moving away from implicitly polyglotting to explicit polyglot.. talking about how it can be processed as json rather than just assuming it can...

Amy: I think it would be useful to have this list of things that make it challenging to use with JSON-LD tooling... then they could respond to that list...

Tess: you could imagine running a no-op json-ld processor that reads and writes json-ld - and randomizes prefix.. changes the pp ... for fuzzing ... all within the bounds of JSON-LD. If you have a toolchain where you have some VC tools into some JSON-lD tool into a VC tool... you'd have to be lucky for it not to break. The Non-VC aware tool should be able.

Amy: That's a thing to ask them - maybe that's not a goal.

Tess: Then it seems weird to me ... [for interop]

Amy: Maybe but I'm not sure if that round-tripping is a goal...

Tess: But a data model - has to have keys of these names and values of these types - that would round-trip... But the json-ld stuff - e.g. prefixes -

Amy: I see what you mean - we had similar issues with activity streams...

Tess: I'm used to formats like html ... you serialize a dom you parse the output of that and you get an equiv dom...

Dan: postel's law?

Tess: I feel like using JSON-lD is pretty cool. But I feel like what they've done is not using any of the benefits of it - the benefit is the ecosystem - pulling in other tools that are used to transform data - if you break round-tripping through those tools then you [don't have the advantage of using JSON-LD].

Amy: there is a bit in json-ld - authors "are urged not to use" ... "features that are not easily detected"

In order to increase interoperability, conforming document authors are urged to not use JSON-LD features that are not easily detected when performing credential type-specific processing. These features include: ...

Amy: I think it's worth asking about this... presumably this language came out of not having consensus on normative language

Tess: I did have conversations at TPAC ... Jeffrey opened issues on their repo...

Tess: I think a lot of the things I would have raised have already been raised... I'm happy to find what he filed and add a comment...

Amy: We can highlight that there are issues that have raised that have not been resolved if that's the case... There's a PR to address them, not yet merged https://github.com/w3c/vc-data-model/issues/1347 - remains to be seen if this will resolve the concerns

Dan: Looks like they feel they've addressed Jeffrey's concerns, there are PRs merged which link to Jeffrey's issues

Amy: any other general concerns than jsonld tooling?

Tess: steps in algorithms assumed json or json-ld last time I read it, polyglot transition wasn't clean, but that might have been fixed.. having a look to see if any are still pending

Tess: this issue seems like it might be an issue.. doesn't sound like the PR addresses it

<blockquote> Something something interoperability with JSON-LD tool chain. We note the language in the JSON-LD spec that discouages use of features that are not detectable. "urged to" language is weird

We also note that there are multiple issues that have been raised, whose concerns we share... Do VCs still need Media Types with Multiple Suffixes? We also note that there have eeb

</blockquote>

Amy to draft a comment to leave on the issue

2023-12-18

Minutes

Amy: no reply so far to my message.

assigned to f2f

2024-02-19

Minutes

Amy: I read Manu's feedback. I think it's fine. The group have thought about it... However I don't havea strong opinion about the polyglot issue. And it's clear that Tess does. https://tess.oconnor.cx/2023/09/polyglots-and-interoperability Manu asked for an official TAG perspective. We have this issue

Dan: one outcome for this could be that we say "no consensus"...

Amy: feels like a debate that has been going on for many years without a wrong or right answer...

Yves: https://www.w3.org/TR/html-xml-tf-report/#conclusions from 2012 - "little consensus"

Dan: worth noting.. it's one of those issues that becomes circular.. the TAG isn't adding any value by getting into this argument

Amy: also vague concerns about malicious issuers, but not sure how architectural that is, not very concrete

Amy: I'll draft a comment, and put it in design reviews chat and ping Tess

<blockquote> Thanks for your detailed reply, and patience as we work our way through our backlog. Sorry that we missed your CR deadline.
  • We have a general concern about the potential harm caused by malicious issuers, but that applies to the whole ecosystem, rather than the data model spec specifically.
  • We don't have a consensus position on polyglot formats, and we don't think the TAG can add anything of value by getting involved in the debate in the context of this spec. We note an open design principles issue on the topic here.
</blockquote>