JWT vs Linked Data Proofs: comparing Verifiable Credentials
Verifiable Credentials, a standard at the W3C as of late last year, is a verifiable data model which can be represented in multiple different assertion formats. Essentially, these formats, or ‘types’ of verifiable credentials, are just alternative ways to represent the same information. The data model described by VCs does not dictate a particular rendering or assertion format, however there are clear trade-offs between the different implementation choices that offer a number of useful insights.
Both of the existing VC formats build off of JSON, the primary serialization format used on the web today. The first of these is JSON Web Token, or JWT, and the other is Linked Data Proofs. The ‘Linked Data’ in Linked Data Proofs refers to JSON Linked Data, or JSON-LD. While Linked Data Proofs are designed specifically to work with JSON-LD, the JWT-based assertion format can be used with either JSON-LD or plain JSON.
Comparison
JWTs have the benefit of already being widely used in today’s identity technologies, most notably in the framework used by OAuth 2.0 and OpenID Connect. Because of this, there are a number of existing software libraries and tools that developers can use immediately to begin building out their implementations. In addition, due to the fact that JWT-based credentials rely on a shared assertion format with existing identity technologies, it may be an easier mental model for newcomers to adopt when starting to experiment with VCs. JWTs are, however, limited in other ways. While they are efficient at representing information, they do very little to allow humans and software to understand the context of the data they represent.
As the VC standard continues to mature and adoption increases, what’s starting to emerge is a web of verifiable data. The data in this ‘web’ originates from many different sources and many different contexts, so it’s important that we have some common standards to maintain the hygiene and quality of the data we are using. The widespread usage of a format such as JWT leads to deep data quality issues when you want to build an ecosystem on consistent, high-quality linked data. Because JWT poorly represents the context of data, its utility in the context of rich data supply chains is quite limited.
Fortunately, we have an alternative model that overcomes this significant limitation. Linked Data Proofs offer a number of improvements on top of JSON. The primary benefit of the JSON-LD format used by LD-Proofs is that it builds on a common set of semantics that allow for broader ecosystem interoperability. It provides a standard vocabulary that makes data more portable as well as easy to consume and understand across different contexts. In order to create a crawlable web of verifiable data, it’s important that we prioritize strong reuse of data schemas as a key driver of interoperability efforts. Without it, we risk building a system where many different data schemas are used to represent the same exact information, creating the kinds of data silos that we see on the internet today. JSON-LD makes semantics a first-class principle and is therefore a solid basis for constructing VC implementations.
JSON-LD is widely adopted on the web today, with W3C reporting it is used by 30% of the web and Google making it the de facto technology for search engine optimization. When it comes to verifiable credentials, it would be advantageous to extend and integrate the work around VC’s with the existing burgeoning ecosystem of linked data.
The security model behind these two approaches also teases out some important differences. JWT-based VCs use the existing JOSE framework for encryption and security. ‘JOSE’ stands for Javascript Object Signing and Encryption, and it was largely created to provide security guarantees around JSON-based identity technologies. Alternatively, VCs based on Linked Data Proofs use Linked Data Signatures for security. Linked Data Signatures provide a simple security protocol which is native to JSON-LD. They are built to compactly represent proof chains and allow a VC to be easily protected on a more granular basis; per-attribute, instead of per-credential. These features support a much more robust security model which has broader implications downstream from VCs, especially in terms of size and efficiency.
The limitations of the JWT approach come from the fact that JWT was originally designed to consume plain JSON rather than JSON-LD. In this permutation, JWTs offer a very limited semantic vocabulary that negatively affects data portability. Using JWTs with JSON is not suited for many complex use cases that need a more expressive data format.
While it’s true that JWTs can be used with JSON-LD to achieve some of the open-world data modeling features that make JSON-LD so useful, this approach suffers because it does not support the security features offered by Linked Data Proofs. In order to add protection to JWTs, it’s necessary to perform additional pre- and post-processing on the data. In contrast, protecting a JSON-LD based VC is as simple as passing a valid VC to a Linked Data Signatures implementation and generating a digital signature. To see a nuanced breakdown of these approaches, reference this chart.
What about zero-knowledge proofs?
Among the technologies that have often been used in conjunction with verifiable credentials are zero-knowledge proofs, or ZKPs. ZKPs are needed for non-correlatable selective disclosure of credential attributes. They allow a user to dynamically generate any number of proofs that minimally disclose information in order to satisfy credential presentation requests. Unlike more simple VC approaches, when using a credential that supports ZKPs, the original credential almost never leaves the Holder’s wallet. The piece of information that’s disclosed to external parties is the credential presentation which is dynamically generated as-needed, rather than the credential itself.
In discussions around the different VC assertion formats, it has often been stated that ZKP-based credentials represent a third ‘type’ of credential. In reality, ZKP-based credentials are not a new type of credential. Instead, ZKPs are an emergent property of certain digital signature schemes that can be represented in multiple different ‘types’ of VCs. Conflating these issues presents an interoperability barrier between ZKP-based credentials and standard JWT-based credentials or Linked Data Proof credentials.
The adoption of ZKPs in the decentralized identity community has largely suffered because of misconceptions about what a ZKP is, and how it fits into the overarching VC data types. An assertion format is a conceptually different level of abstraction than a particular kind of digital signature scheme. Although this distinction is obvious to low-level programmers, it may not be immediately obvious to many of the stakeholders in a VC ecosystem. This is partially because, until now, there have been no existing open-source implementations that attempt to bridge the gap. Our solution, which uses JSON-LD based credentials with ZKPs, creates an open-source reference implementation that demonstrates how these technologies can work together. See here for our approach to solving this problem.
Interoperability
So, what will it take to make the different VC assertion formats compatible with one another? To answer this question, we revisit the foundation of both of these formats: JSON. In order to get interoperability and compatibility between these types of VCs, we need to make sure that their data models share a common underlying approach that can be easily translated from one type to another.
In practice, this means that what is needed for VC interoperability is JSON processing, along with pre-configured ‘@context’ definitions. Having dynamically resolvable contexts and doing JSON-LD processing is not strictly necessary for an interoperable VC ecosystem. However, these features may add additional semantic data capabilities that are useful for many kinds of implementations.
As long as the community agrees to these minimum requirements, people can implement VCs however they want. A recent draft specification around VC JSON Schemas demonstrates how to use JSON Schema to represent credential schemas in parallel to the method used by JSON-LD. This approach can allow JSON Schema and JSON-LD to work symbiotically in the VC ecosystem.
VC JSON Schemas is motivated by an attempt to create convergence around the semantics of verifiable credentials. It does not address the fact that JOSE signatures and Linked Data Signatures work differently on a cryptographic level. However, it does demonstrate that a credential represented in JSON can be mapped to a functionally similar credential in JSON-LD.
The Verdict
Linked Data Proofs offer more flexibility and are thus more scalable for global decentralized networks. Due to their native compatibility with JSON-LD, they encourage adoption of an open-world data model and reusable schema definitions that make JSON-LD so powerful.
JWTs, in contrast, offer a simple and straightforward way to express data with a limited semantic vocabulary. Using JWTs with JSON-LD provides a potential compromise between the two approaches, but loses much of the flexibility provided by Linked Data Security.
By providing a bridge for different VC assertion formats at least on a semantic level, we can eschew much of the cryptographic incompatibility that exists on the layers below. While these implementation differences will remain in a diverse and healthy ecosystem, they should not prove to be a hindrance to the implementation of standards-based verifiable credentials.
