Digital Credentials That Can Be Verified: A Lesson in Terminology

The terminology swirling around the world of digital identity can be overwhelming. Are we talking about verifiable credentials? Digital credentials? What about verifiable digital credentials? Do these terms have profound technical distinctions? Barely (though I suspect some of the more deeply engaged individuals may disagree). The nuances mostly arise from standards politics, the English language, and some good old-fashioned product marketing.

The Birth of Verifiable Credentials (VCs)

In 2017, the W3C Verifiable Credentials working group was formed to define a framework for sharing and verifying digital claims. They published the Verifiable Credentials Data Model v1 in 2019, and version 2 is now in the Candidate Recommendation stage. The W3C defines a verifiable credential as: “A tamper-evident credential whose authorship can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verifiable.”

As the term “Verifiable Credentials” gained traction, other organizations started exploring similar ideas for digital credentials that could be cryptographically verified. As you might expect, they sought to avoid confusion with the W3C’s model and put their own stamp on things, which has led us to these to terminology shifts.

Terminology Overlap in Standards and Marketing

The IETF Secure Patterns for Internet Credentials (SPICE) working group and the WICG Digital Credentials API project chose to call their work “digital credentials.” According to the Digital Credential API, a digital credential is: “A cryptographically signed digital document containing one or more claims made by an issuer about one or more subjects.”

While clear and concise, this term lacks the specificity needed to encompass the complexities involved. SPICE WG adds further nuance, defining a digital credential as: “A digital credential expresses claims about a subject and links them with cryptographic keys. Some sets of claim names have already been defined by the IETF and other standards development groups (e.g., OpenID Foundation).”

Recognizing this, the U.S. National Institute of Standards and Technology (NIST) recently adopted the term Verifiable Digital Credentials (VDCs) to bridge the gap between descriptive clarity and brevity. NIST defines VDCs as: “A cryptographically verifiable, digital representation of a credential or attributes secured in a dedicated application, often referred to as a digital wallet.” NIST is careful not to promote any specific solution or organization, so they’ve had to be particularly careful in selecting a term that is market-neutral.

A Tale of Media Types and Standards Conflicts

So, knowing there is confusion in the terminology is one thing. Let’s look at how that actually plays out in standards development.

The OAuth working group meeting at IETF 121 highlighted historical and technical challenges with defining and typing credentials. Brian Campbell presented a session on “SD-JWT and SD-JWT VC,” which included a truly excellent perspective on the history that led to some of this confusion; you should watch the recording.

• JWS/JWE/JWT:
  • JWTs (JSON Web Tokens) initially included type headers and media types to describe payloads. However, their utility for typing was minimal, as the data type could often be inferred by parsing the payload.
  • The IETF introduced explicit typing for tokens, such as application/at+jwt for access tokens, to clarify expectations for processing.

• Verifiable Credentials:
  • The term originated from W3C but was perceived as inaccessible by some.
  • A key debate arose around JSON-LD (a JSON-based format for Linked Data). While JSON-LD wasn’t initially mandatory, it later became a requirement for compliance with the W3C VC data model, leading some groups to pursue simpler alternatives within the IETF.

Media Type Conflicts

The overlapping work between the W3C and IETF led to conflicts in media type registries; it’s basically a functional example of how definitions and politics impact standards development. In this case, the W3C registered media types like vc+ld+json+sd-jwt, while the IETF sought to define types for SD-JWT VCs (Selective Disclosure JSON Web Tokens). This duplicity caused confusion and poses a threat to interoperability.

Don’t get too anxious about this example; working group participants did figure out a potential path forward. What people in the know will refer to as “the Dublin Proposal,” the group agreed to recommend a new media type, dc+sd-jwt, for SD-JWT VCs and tighten the scope and accelerate the timeline for relevant RFCs to make sure their position is solidly established.

Enjoying this post? Don’t want to miss the next one? Subscribe to be notified whenever a new post comes out!

The Challenge of Naming Things

Naming things is one of the two hardest problems in computer science. Where we are with digital credentials that can be verified is reflected in terminology confusion for all sorts of things throughout the industry. IDPro®, a professional organization for identity practitioners, has a freely available Body of Knowledge (full disclosure: I’m the principal editor for that work) that includes a consolidated terminology document. The terminology includes definitions from every article in the BoK, resulting in multiple definitions for even basic terms like “authentication.” It’s like we are compelled to make things difficult for ourselves.

For identity professionals, here’s my suggestion: always clearly define your terms. This could mean explicitly referencing a specification that outlines the definition you’re using or providing your own definition if no clear standard exists. Even in code, include comments clarifying which model or framework you’re adhering to.

For product marketers, I get the need to differentiate your solutions, but it will be much more compelling if you indicate you are standards’ compliant AND what standards you are compliant with. It may result in more words, but those words will help your customers have a much better sense of what you’re offering. Educated customers are the best.

If you’d like to read more about how some of the digital credential protocols differ, I have a few posts from last year which might be of interest:

• Verifiable Credentials and mdocs – a tale of two protocols
• More on the Options and Diversity of Verifiable Credentials

If you or your organization need support with standards development, let me know. With my experience across various SDOs, I’m here to help guide you through the complexities of Internet standards development.