More on the Options and Diversity of Verifiable Credentials

In writing the recent blog post on W3C Verifiable Credentials and ISO mdocs, I found a rat’s nest of options and choices that made understanding the landscape ridiculously challenging. When talking about verifiable credentials, you’re actually talking about a collection of format and protocol specifications that sometimes overlap. In order to understand the space, I needed to sort out several points:

• What is a digital credential?
• What is the difference between a format and a protocol?
• What are the formats and protocols that are most relevant when talking about verifiable credentials?
• How does someone decide what technology to pursue, and where do they find out more?

Because of the competing use cases, siloed focus, and general market politics, some of the concepts below are more of a continuum than clear distinctions from one area to the next. And that is part of why the space is so confusing. As there is no single arbiter of good taste when it comes to how the Internet functions, all this confusion only gets sorted out through years of discussion, debate, testing, adoption, and evolution.

Digital Credentials

A digital credential conveys data that is an authentic representation of information held in a registry at the time of issuance.

Andrew Hughes and Dr. Torsten Lodderstedt

To understand everything else in the world of verifiable credentials, first, you need to know what a digital credential is. Andrew Hughes and Dr. Torsten Lodderstedt described it in their Identiverse 2023 presentation: “A digital credential conveys data that is an authentic representation of information held in a registry at the time of issuance.” So many important words there! My translation is that a digital credential is a collection of information about a person or thing (in more generic terms, a subject) that has been packaged based on what was in a particular repository at a single point in time. How trustworthy the data is, how secure it is against tampering, all that is actually out of scope for what it is. A digital credential is the keystone to building an ecosystem; it isn’t all that interesting until we figure out how to use it.

Credential Issuance Formats and Protocols

A format is a the structure of the data.

A protocol is how you move that data around. 

If you have a digital credential in a format, but you haven’t issued it to the entity that needs it, what good is it? This is where issuance formats and protocols start making verifiable credentials usable. 

Looking to the W3C’s specifications, issuance and presentation formats are all contained within the W3C Verifiable Credentials Data Model, described in more detail later in this post.

OpenID for Verifiable Credential Issuance (OpenID4VCI, which is barely shorter than the name of the specification), is an issuance protocol. This issuance format can be used with just about any issuance format. ISO’s mdoc, W3C’s Verifiable Credentials, it’s open to most everything. The purpose of the protocol is to make sure that the credentials are transported in a standardized way. OpenID4VCI is still in draft, so it is something of a moving target for anyone not deeply embedded in the space already.

But OpenID4VCI isn’t the only issuance protocol under development. The  ISO/IEC JTC 1/SC 17 committee is working on 23220-3 – Cards and security devices for personal identification – Building blocks for identity management via mobile devices – Part 3: Protocols and services for issuing phase. My expectation is that this work will align more closely with the mdoc/mDL work and its more restricted underlying assumptions, but I am not closely tied to the ISO efforts.

If you want to truly dig into the rabbit hole of comparing credential formats, the Credential Format Matrix is the place to start.

Credential Presentation Formats and Protocols

Now we have the concept of a digital credential, it’s been issued, and we want to use it. That means putting it in a machine-readable format to present to something else and defining the protocols to use to get it there. There are a variety of requirements and constraints that influence what that format needs to be for any given use case. 

W3C Verifiable Credential Data Model

The W3C wants to create credential issuance and presentation formats for the web. The use cases this model supports are intended to allow for All The Things. From uber-secure data like government-issued credentials to meh-secure data like movie tickets, the W3C Verifiable Credential specification “provides a standard way to express credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.” They came out with the official version of their data model in 2022. However, specifications of this level of complexity rarely survive contact with reality. And so, people within the W3C are working on a new version that will include breaking changes from the first version.

My “ahHA” moment when researching this came from a conversation with Mike Jones when I asked if the W3C Verifiable Credential Data Model was a credential presentation format or credential issuance format. He said, “The issuance format is called a Verifiable Credential.  The presentation format is called a Verifiable Presentation.”

The format for a W3C Verifiable Presentation credential consists of three major parts: the metadata about the credential (e.g., who issued it, when it was issued, etc.), the claims that make up the credential (the details of the entity being described), and one or more proofs (see ‘digital signatures’ below).

Selective Disclosure JSON Web Token-based Verifiable Credentials (SD-JWT VC)

According to the IETF Internet-Draft abstract, the SD-JWT VC draft specification “describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) format.”

A few things make SD-JWT VC’s format different from the W3C’s Verifiable Credential format. First and foremost is its explicit mention that it does not use the W3C’s data format in v1, v1.1, or the draft v2. While both are general-purpose credential formats, the W3C requires the use of JSON-LD (described below in the section on data serialization). The SD-JWT VCs, on the other hand, focus on regular JSON payloads and the SD-JWT format. Some people find the restriction of JSON-LD too much to bear, which makes the SD-JWT VC format a more appropriate option for them.

ISO mdoc

As Anil John noted in a Mastodon thread, “The starting point for the W3C VC work and the ISO mDL work were radically different; the mDL work was directly focused on in-person use cases while the W3C work was focused on remote/online use cases. Both are trying to address the other at present, but the starting point has influenced the design choices that are inherent in both standards.” mdoc uses the Concise Data Definition Language (CDDL), a language that can be used either the CBOR or JSON data serialization formats. mdoc is standardized in ISO/IEC’s 18013-5, a specification on the in-person presentation of mobile driving licenses (mDL). There is a very readable description of mdocs and mDLs in ENISA’s Digital Identity Standards write-up from July 2023.

While this format can be used for other digital credentials, its standardization in the mDL specification results in people (like me) conflating mdoc and mDL regularly. It’s hard to pinpoint when standardization started for mdoc; probably the best one to point to is 2014, when ISO/IEC kicked off the task force, resulting in ISO publishing 18013-5 in 2021. There is still plenty of work to do, particularly around how you’d take this credential presentation format and use it in a remote (rather than in-person) setting. That’s being covered in ISO/IEC 18013-7, still a work in progress.

Data Serialization Formats

You have a digital credential. You understand the choices you must make to decide what format it needs to be in. Now, you need the best way to transmit it to the thing that will consume it. That’s where data serialization formats come in. In the digital credential space, there are a handful that most people talk about.

If we’re talking more about tiny devices and digital credentials about things, then using something that focuses on keeping the format really, really efficient is critical. That’s something that the Concise Binary Object Representation (CBOR) exists for. If that level of efficiency isn’t necessary and more features are required, then JavaScript Object Notation (JSON) is probably better. Whether you find one better than the other, from an outside but still geeky perspective, is like arguing between emacs and vi. If you’d like something more structured and optimized for an environment where the data pieces are related to each other (for example, all parts of a single schema), then JSON for Linked Data (JSON-LD) is a great choice. Complicated, or so I’m told, but great.

But wait, there’s more! Continuing with the JSON theme, work is underway within the IETF that focuses on the selective disclosure (rather than all-or-nothing disclosure) of data in a JSON structure. That’s the Selective Disclosure for JSON Web Tokens (SD-JWT) draft. If you’re more interested in work being developed within the European Union, the European Commission’s European Blockchain Services Infrastructure (EBSI) project’s EBSI Improvement Proposal (EBIP) on selective disclosure might be a fit, even though it refers back to SD-JWT.

As individuals focus on their core use cases and the best formats to support them, they will drift apart in terms of the functionality supported and the terminology used. That, in turn, creates complications for people and organizations that need to support more than one use case that brings in more than one credential presentation format. Every additional format involves support overhead to maintain it. Wouldn’t it be better if we just … picked one?

Digital Signatures + Credentials

Now, let’s consider the security of all this. Looking at the fundamentals of security, confidentiality, integrity, and availability, what is the best way to secure the presentation and transmission of a digital credential? That’s where digital signatures come in. TechTarget has an excellent article explaining digital signatures. The tl;dr of it is that digital signatures are a way to cryptographically secure one or more pieces of data such that someone (or something) can look at it later and say, “Yep, that was signed and sent by who I expected and hasn’t been changed since it was sent.”

That’s important information, but now there are choices to make. What exactly should be signed when it comes to digital credentials? Do you include the signature in what you’re presenting so it’s a core part of the credential, or do you put a wrapper around it like an envelope? Or both? The answer to that is, as with so many things, it depends. Do you expect all the devices to be able to handle this kind of cryptography on the fly, possibly without access to the Internet? Are the devices powerful enough to handle all the math?

Taking this down a slightly different dependency path, depending on what data serialization format you’re using, you’ll have another set of specifications to learn about that tells you how to sign, encrypt, and decrypt the different possible formats.

The IETF created the JSON-based building blocks of JSON Web Token (JWT), JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Algorithms (JWA). LoginRadius has a great article describing each of these and, at a high level, how they fit together.

Similarly, the IETF is working on similar building blocks based on CBOR, including the CBOR Web Token (CWT) rather than JSON. For those organizations more committed to a CBOR-based model, the COSE working group is where to learn more.

Wrap Up

So much of this work is either still in draft or very early deployment. That means it is all subject to change. The descriptions of the technologies above may be lacking in several ways. My hope is that this post will help you understand where the debates are happening and the work is still in progress. If you think any of these efforts are going in the wrong direction, please engage in the conversation rather than creating Yet Another specification effort. The fragmentation in the space is not helping move this work forward. 

This is probably the least SEO-friendly post I’ve written in ages! Thanks for getting through it, and I hope it was as helpful to you as it is to me in understanding how all these parts are supposed to fit together. I encourage those more deeply involved in specification writing than I am to offer their feedback, either agreement or correction, in the post comments! It will help me learn and possibly help others as well.

But Wait, There’s More!

Feedback from Anil John:

There are two additional items missing from your formats and protocols listing:

❖ The Verifiable Credentials API (VC-API) which is an issuance, verification and presentation protocol. More @ https://w3c-ccg.github.io/vc-api/

Extensive interoperability testing, particularly in the education and workforce credentialing ecosystem, has been conducted using this API leading to global traction. More @ https://vcplayground.org/

This is equivalent to the work being done by OIDF on OID4VCI and OID4VP

❖ The W3C Data Integrity ECDSA Cryptosuites which includes support for selective disclosure mechanisms that use fully FIPS/NIST compliant curves. More @
https://w3c.github.io/vc-di-ecdsa/#selective-disclosure-functions

This is equivalent to the work being done on SD-JWT

If you’d like to have me on a podcast or webinar, my media kit is available for your reference.