Misinformation sometimes gets a foothold and spreads across the digital identity oriented forums.
A most recent piece that is percolating is: the Verifiable Credential (VC) Data Model 2.0, which is under development within a formal W3C working group, does not or will not support JSON.
What is true:
W3C VC 2.0 is 100% capable of supporting JSON.
Always has been and always will be.
And that is the simple fact
However, navigating and making sense of the technical politics and different motivations among different groups over the long span of standards development and evolution are never simple. I have theories that seem to change daily depending on who I talk to about what is going on and why but that isn’t really relevant or important at this point. As the standard we have all been putting our heart and sweat into gets serious market attention and adoption, as a community, we need to stand together and bring simple basic truths to light.
The Historical Context of the JSON vs. JSON-LD
From the very beginning of the VC work, there have been two camps:
- the JSON people
- the JSON-LD people
- AND the “can’t we all get along people” ← I put myself in this group.
I have empathy for both camps. I understand the reasoning both have and I think both are needed to make a viable ecosystem work in the long run (I explain more about this in a separate post here). Both camps worked incredibly hard to find a way to make sure both could live with the V1 of the specification.
Here is my explanation of the compromise for V1:
There is one “extra” field that JSON-LD requires/needs which is @context and if you didn’t want to use it and simply wanted to ignore it and just do JSON you could. The VC would be entirely compliant and thus both data expression formats could live in the same specification. JSON-LD credentials that did have an @context that were being read by tooling that just did JSON could still read the credentials – it did nothing to interfere. This seems like a pretty good “let’s figure out how to live with each other” solution.
Another simpler way to understand this is that JSON-LD is JSON but the inverse is not true. JSON is not JSON-LD.
That is, a few little bits need to be added in to make JSON-LD be JSON-LD but those little extra bits don’t make it “NOT” JSON. However these little extra bits if they are not there…mean the data model is no longer JSON-LD.
I was there for the discussions at the Verifiable Credential Working Group face-to-face meeting that happened in Miami in early 2023, where a similar compromise was reached for V2 of the specification that was inclusive of JSON and JSON-LD.
Relevant Community Work/Discussions on V2.
The community had very long (296 comments) very intense discussions threads on the issue #947.
It has been suggested that the use of @context should be made optional. This would be a normative change to the current specification, as the use of @context is required in both JSON and JSON-LD. This issue is to discuss if this is a good idea and the mechanism(s) that could be used to accomplish the task.
Both sides are very passionate and have their own points of view and good reasoning. Lots of in person discussions were on this with the chairs sitting at a table talking to lots of community members for a long time.
Incredible work was done by the community to figure out how both could be supported.
Orie Steele did an amazing job of fairly putting forward the core issues that came up on the thread with both sides. He also summarized three different solutions. One path forward was chosen to go with media types. Here is the resolution that passed and celebrated that is the compromise for V2.
This was it:
Resolution #1: The base media type for the VCDM is credential+ld+json. @context is required (MUST) in the base media type; other media types MAY choose to include @context. Serializations in other media types (defined by the VCWG) MUST be able to be transformed into the base media type. Another media type MUST identify if this transformation is one-directional or bi-directional. Bi-directional transformation MUST preserve @context. Transformation rules MUST be defined, but not necessarily by this WG..
It was a really intense day to get to this resolution. If you want to read the whole discussion from that day and all the polling you can. I am an invited expert in the working group and I was there through the whole thing. I was really proud of how everyone really struggled to find a path forward that everyone could live with. It was a huge relief. Everyone felt it, the JSON people and JSON-LD people. Mike Jones, one of the strongest JSON proponents, said this at the end of the day.
Michael Jones: I would not FO [File an Objection], and is grateful for people’s work today.
Addendum: The for the above resolution to work the IETF Media Type group needs to accept such a media type construction. I’m at IETF right now we shall see where it goes.
More Community Context Since the Miami Meeting
In the last few weeks some strange things have happened with the specification.
Recently a section of the specification on Syntaxes that was worked on in V1 of the specification that was explicitly created to make sure JSON was included was removed – even though concerns were raised about doing this by JSON-LD people who didn’t want it taken out
The most problematic removal was this:
“Just because there is a @context doesn’t mean you have to do JSON-LD processing”
In the last week several Issues and Pull Requests to support further clarification of how the V2 specification does support JSON.
- This one fully implements the resolution from the Miami F2F meeting: (giving all JSON-only, mdoc-only, CBOR-only formats a path to compatibility with Verifiable Credentials) by adding a section on Ecosystem Compatibility.
- This issue articulates the issue documents how VCs are processed as JSON today and this is the pull request that demonstrates JSON Processing has engagement to really help clarify the language in the specification itself.
It is also worth understanding some key compromises have been made in particular by the JSON-LD people over the course of developing the specification in the last year.
- @vocab was added to support developers who know JSON & JWT be able to do semantics (Here is the issue) below is a quote from it
- By adding @vocab to the core data model context, we can give these developers the same experience they have with JWT private claims, which you should read about here: rfc7519#section-4.3
- ALL JSON is compatible w/ the VCDM now (as long as you have that ONE @context name in your VC) – you can see this explained in the getting started section.
- Here is another example of us limiting JSON-LD usage (to enhance the experience for JSON-only developers):
- Another another example of “turning off error reporting in JSON-LD” to address the needs of the JSON-only crowd
There is a whole sub specification within the working group that was just updated this week.
Verifiable Credentials JSON Schema Specification 2023, JSON Schemas for Verifiable Credentials, W3C First Public Working Draft 12 July 2023
Here is an in depth comment explaining how the spec is capable of supporting JSON.
A lot of hard work and compromises were made to have both JSON and JSON-LD both be within V2.0.
We need to stop the misinformation. It is destructive and corrosive to the community.