• Skip to primary navigation
  • Skip to main content

Identity Woman

Independent Advocate for the Rights and Dignity of our Digital Selves

  • About
  • Services
  • Media Coverage
  • Podcast
  • Blog
  • Contact
  • Show Search
Hide Search

JSON

My Understanding of the JSON vs.JSON-LD

Kaliya Young · July 21, 2023 ·

JSON, a Simple and Easy Start for Verifiable Credential Issuance 

JSON is really really simple. It is just name value pairs. There is a tiny IANA registry for JWT claims that defines about 100 JSON terms. This is the one registry of JSON terms that folks who love JSON reference repeatedly and say solves any needed disambiguation problems. However, beyond these approximately 100 terms, there is nowhere really to look up and figure out what a particular name asserted in JSON actually means. 

Having small known vocabularies works out fine for contained ecosystems where all the entities have a shared understanding of vocabulary they agree on. This small known vocabulary all actors agree on is known as “closed world” scenario because it assumes a boundary of knowing that is obvious to those involved who care and un-obvious to those outside the world but they don’t care anyway so who cares about them. 

If one is a receiver of a JSON VC with only name-value pairs and it contains values outside of that tiny IANA registry – then…what does one do if one isn’t “inside” whatever “world” the issuer assumed. One either has to go and contact the issuer to ask them OR potentially hire a big tech firm to help one do the discernment because that big tech firm has done the work to accumulate knowledge from all these closed worlds and are selling that discernment capability as a service. 

On the other hand JSON is very easily understood by developers. There is a lot of existing tooling that just works. Serialization isn’t required. It’s easy. It is human readable. 

So let’s look at some JSON. What is it? 

JSON (JavaScript Object Notation) is a widely used open standard object and document format used for data interchange  and is human readable. It consists of attribute-value pairs.  It is a generic data model. 

Here is an example of JSON (from the JSON Wikipedia page) 

There are several different data types and structures supported in JSON. From the example  above: 

  • Number  
    • Age 27  
  • String: a sequence of zero or more Unicode characters.  
    • firstName – “John”  
  • Boolean: either of the values true or false 
    • Is alive = true 
  • null: an empty value, represented by the string null 
    • No spouse 
  • Array: an ordered list of zero or more values, each of which may be of any type.  
    • phoneNumbers – represents an array 
    • There is more than one phone number listed, so it is represented as an array
    • children – represents an empty array 
  • Object: a collection of name-value pairs where the names (also called keys) are  strings. Objects are intended to represent associative arrays, where each key is  unique within an object. Objects are delimited with curly brackets and use commas to separate each name-value pair, while within each pair the colon ‘:’ character separates the key or name from its value. 
    • Address – an object consisting of four different name-value pairs.  

JSON alone doesn’t have very much meaning and is not machine readable. This format is needed as a kind of “on ramp” to the VC ecosystem because of the above qualities. It’s a good starting point for developers, people – and organizations to begin to issue VCs. However if JSON is the only way to express claims within VCs – more complex cool interesting things that are possible with JSON-LD are closed off.  The next part of this article will look at the key capabilities and features of JSON-LD. 

JSON-LD for Semantic Clarity and Interoperability

JSON-LD is newer – it takes JSON and adds one more piece to it – a way to refer to contexts and vocabularies that have meaning. 

JSON-LD can be read with JSON tooling – it just leaves out all the extra LD stuff. 

One of the main goals of JSON-LD was to make it very easy for developers to interpret JSON objects according to immutable and open data registries rather than local schemata, which can be separated from the data they are essential to interpreting. It was created for web developers working with data that must interoperate semantically across the Web. 

What distinguishes JSON-LD is that it supports an additional layer of context to map the name part of the name-value pair to an RDF ontology,  a knowledge graph that structures metadata in shared  vocabularies so that when machines read it they can understand more about what it means.  

Here is JSON-LD being used to describe the movie Avatar.  

At the top in the @context field it references the place where one can look up more about what  the terms below mean so in the schema.org context there is a type called “Movie” and they can then look up what are all the different terms for this type.  

JSON-LD allows credential issuers to define a type of credential they are issuing and then use the @context field for navigating a tree of schemata that explain the structure and content of a credential. The @context field is an address (URL) which also helps place the credential in its original context. This helps the verifier confirm the meaning of all the “attributes” of the  “attributes-value pairs” that are listed on the credential.  

JSON-LD supports disambiguation between properties found in different credentials issued by  different issuers and so verifiers understand what they are looking at.  

One of the features that is valuable for a multilingual world is the ability to map property values to another language via a language map. So, when a credential is published in one language, English, and is presented to a verifier who is familiar with another language, Thai, the program can go look up the values of the claims in the document and have them accurately translated so  they can be read by the verifier. 

This means that definitions can be expressed in different languages and translated. In addition to all the features JSON provides, JSON-LD introduces: 

  • a universal identifier mechanism for JSON objects via the use of IRIs, 
  • a way to disambiguate keys shared among different JSON documents by mapping them to IRIs via a context, 
  • a mechanism in which a value in a JSON object may refer to a resource on a different site on the Web giving the ability to annotate strings with their language, 
  • a way to associate data types with values such as dates and times, 
  • and a facility to express one or more directed graphs, such as a social network, in a single document. 

One of the industries that is really dependent on JSON-LD for credentialing is higher education. The Credential Transparency Description Language (CTDL)  work by Credential Engine that I am one of the advisors for is working to develop semantic mapping and meaning for over 1 million different credentials issued by 50,000 higher educational institutions in the United States.  Different but similar work is happening in Europe to map and make sense of credentials issued by various institutions. 

(Some parts of the post are excerpted and adapted from the Verifiable Credential Flavors Explained paper that I wrote a few years ago. My colleague Lucy and I are working on an update of this paper coming up in the fall.)

Misinformation Stops Here: W3C VC 2.0 Supports JSON

Kaliya Young · July 21, 2023 ·

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. 

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

  1. @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
  1. 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. 
  1. Here is another example of us limiting JSON-LD usage (to enhance the experience for JSON-only developers): 
  1. 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. 

 

 

Kaliya's the shit. Be there or be square.Enlighten yourself through her

     Copyright © 2023 Identity Woman  evelurie.com/web design/develop     

  • Terms of Use
  • Privacy Policy
  • Sitemap
  • Contact