Getting to Practical Interop With Verifiable Credentials

Standards compliance is a noble ideal, but by itself, it’s not going to get us to practical interop on verifiable credentials (VCs). That’s because there’s not enough agreement on which standards we’re talking about, and the ones we all like aren’t clear enough to force alignment. The W3C’s Verifiable Credential standard defines a data model, not a data format. It specifies how elements of a verifiable credential (VC) should relate to one another structurally, and what those elements mean. It leaves many questions out of scope, including these which are crucial to interoperability:

1.    What should be the format of the bytes that comprise a VC file?

2.    What API or protocol should be used to request and share VCs?

3.    How should credential interactions be governed for consent, privacy, and accountability?

Several VC ecosystems have grown up around the VC spec. Each touts standards compliance and interoperability, yet they do not currently interoperate with one another. Let’s have a look at their differences and commonalities, and then explore a simple proposal that might make which language your VCs “speak” as transparent as which language you choose when you watch a movie.

Language settings for a movie
We take for granted the language interop on the DVDs we watch. Let’s do something similar for VCs.

Linked Data

One ecosystem has emphasized how VCs fit into a larger strategy for linked data on the semantic web. This is the world of JSON-LD and RDF. The VC spec mentions several linked data features and could combine nicely with others. Viewing VCs through linked data lenses makes it natural to combine them with ontology work at It also allows for namespace-based extensibility and provides a rigorous parsing model with many semantic benefits.

When folks in this ecosystem talk about “standards compliance,” they typically mean more than compliance with the core VC spec; they advocate the use of additional standards or standards proposals such as Linked Data, RDF, Linked Data Proofs, CHAPI, HTTP Signatures, zCaps, and so forth. Public DIDs are used in this ecosystem to bind credential holders to their credentials. They can be rooted on many blockchains; Veres One is prominent because it was designed with linked data in mind. Although the web itself is a robust foundation, other technologies in the stack are at different maturity levels and have different levels of adoption and support. “Interoperability” in this worldview is not just interoperability with other SSI vendors, but with a large family of web technologies and with the general world of the semantic web.

JOSE and OpenID Connect

Another ecosystem has focused on how VCs could be expressed with technologies that already have deep traction in enterprise security. JWTs, JWEs, and other IETF standards for JSON-based signed and encrypted payloads are familiar to many web developers, and they enjoy broad library support; this ecosystem uses them as the basis of a VC format. OpenID Connect is widely used for social login on the internet; this ecosystem favors login as the basis of a VC exchange protocol and seeks to add support for self-sovereignty by maturing and re-standardizing what was originally a marginalized feature of OIDC known as SIOP. Public DIDs are used in this ecosystem to bind credential holders to their credentials, and Sidetree is important as a way to make various blockchains for those DIDs more scalable. Linked data features of VCs are de-emphasized.

When this community talks about “standards compliance” and “interoperability,” it is focused on existing IAM standards and interop with today’s web trust model and enterprise systems. It prioritizes use cases where institutions are issuers and verifiers, and individuals are holders/customers/employees; it does not prioritize institutions as holders, individuals as issuers, or rules that apply equally to both. This ecosystem is newer than the Linked Data community, and its work on SIOP is not yet standardized. However, the JOSE family of IETF standards are mature, and they enjoy significant gravitas outside SSI. One of the key proponents of this approach is Microsoft, which has the ability to deploy an updated OpenID Connect+SIOP mechanism to many thousands of enterprise customers — so significant traction is a possibility in the future. Microsoft has begun developing ZKP technology in this ecosystem.


A third VC ecosystem has emerged under the sponsorship of the Linux Foundation at Hyperledger. In terms of VC deployments in production, this is the oldest and largest of the three ecosystems today, with important production milestones in 2017 and 2018, widely implemented interop profiles, and with hundreds of organizations running pilots and production deployments.

The Hyperledger initiative has open SDKs and frameworks for numerous programming languages and platforms, including mobile, web, and embedded. It emphasizes peer agents communicating asynchronously over secure protocols, rather than enterprise-centric flows that depend on traditional client-server APIs. Many but not all of the stacks in this ecosystem leverage open source projects; Hyperledger Ursa for common crypto, Hyperledger Indy as a ledger component, and Hyperledger Aries for protocol definitions. The Sovrin Foundation and parts of the Canadian government have been prominent supporters of this ecosystem, reinforcing a deep and we believe necessary interest in formal governance and regulatory compliance. Peer DIDs, KERI, and the Trust Over IP Foundation are often associated with this ecosystem, although they are each independent of it.

The approach to VCs in this community is not uniform. Hyperledger Indy offers a ZKP-oriented implementation of VCs that emphasizes privacy, selective disclosure, and user control. These libraries were shipping before the VC standard was finalized, and although their authors contributed important content to the VC spec, they have been slow to converge back to the standard. But recently the ecosystem has made significant interop strides; it has begun moving toward the adoption of BBS+ signatures (thank you to Mattr and SecureKey for leading out here) and has been steadily working toward integration. This offers a chance to build a bridge to linked data without sacrificing privacy. A pull request against Indy SDK introduces W3C compatibility in Indy proof formats. DIDComm v2 bases its message envelope on an IETF JSON Web Message, which is part of the JOSE family. The Hyperledger Aries Present Proof Protocol 2.0 describes how to present non-Hyperledger VCs in a standardized way. It also includes information about how to use DIF’s presentation exchange format, which builds bridges to the JOSE and OpenID Connect communities. So there’s progress.


All of these ecosystems believe in the value of DIDs and verifiable credentials, in the Verifiable Credential Model standard, and in the not-yet-finalized DID standard. All of them care about interoperability. All of them believe that decentralized approaches to identity add important value over traditional identity-provider/federated models.


The Linked Data community values the semantic web more than the other groups. It considers Linked Data Signatures and JSON-LD to be additional standards that the larger community should adopt, arguing that the semantics of VCs are incomplete without them.

The JOSE community is institution-centric and wants to achieve adoption of these new technologies by incremental modifications to existing IAM/IDP models. It tends to use the term “decentralized identity” rather than “self-sovereign identity” because individual autonomy and privacy are not the most pressing priorities — although this may change as Microsoft’s ZKP efforts develop.

The Hyperledger community has not valued JOSE or JSON-LD as highly as its peers. It has urged the world to stop binding holders to credentials with public DIDs, citing the privacy risk. It has also explored formal governance as a way to guarantee regulatory compliance and counter-surveillance — not feeling satisfied with censorship-resistant blockchain.

Suggested Steps to Convergence

Each of these ecosystems has valuable insights and important concerns. Market forces will produce convergence sooner or later — but all of us want to accelerate the process. What more could be done?

I would like to suggest three action items. Each is modest in size — neither trivial nor overwhelming. Each allows vendor investments to be preserved. Each protects our customers from disruptive change while advancing everyone’s combined interests. We can work on them in parallel.

1.    Hyperledger can implement support for JWT-oriented VCs.

2.    All of us can implement support for DIF’s new presentation exchange format.

3.    All of us can come together to choose conventions for a multi-format VC, allowing one credential to carry multiple signatures so it’s usable in more than one ecosystem.

Regarding Step 1

This would erase the most important line between the Hyperledger and JOSE ecosystems. All Hyperledger stacks that leverage a common credential library could verify credentials from a JOSE-oriented issuer and could issue credentials to a JOSE-oriented holder. It would be possible to use lighter weight JWT-oriented creds for use cases where selective disclosure is not needed, and ZKP-oriented creds when the stakes for privacy are higher. The portability of a credential would leap forward for holders. Hyperledger’s work on governance would be usable in both ecosystems. Importantly, we would get immediate convergence wins, and remove schedule dependencies on the effort to refresh the OIDC standard with SIOP updates, and on Microsoft’s ZKP tech. (While those efforts unfold at their own pace, Hyperledger’s credential exchange protocols can facilitate flows for either credential type, using production software that already has demonstrated interop from many vendors.)

Interop isn’t finished with this step, of course. Pure JOSE stacks wouldn’t be able to validate ZKP-oriented credentials without extra work (an excellent potential step as well; would anybody like to volunteer?). And the OIDC+SIOP work — plus hard conversations about whether a login standard is really the right way to pass arbitrary credential attributes — would remain on the to-do list. But we’d have momentum.

Regarding Step 2

Much of our interop angst has been on the format for shared credentials, but another hole has always lurked. Until now, only the Hyperledger community has had a rich, carefully specified way to ask for credential-based proof. We haven’t even been able to ask one another questions about credentials in a mutually intelligible way!

DIF’s presentation exchange plugs this gap for the other two communities — and if Hyperledger shifts to the same format as well, we’ll have strong convergence on a crucial behavior. Since Hyperledger is already moving in this direction to bridge the gap, this seems like an easy and uncontroversial win.

Regarding Step 3

Despite format divergences, there’s surprisingly good agreement on the data that VCs should hold for a given use case. Step 3 builds on this insight, suggesting that issuers change their behavior to issue a single digital artifact that’s signed in multiple ways. This might add a few cryptographic library dependencies to issuer software, but it need not change their processes a lot — and it can be almost transparent to holders and verifiers. It’s akin to releasing a single DVD that has audio tracks and closed caption data for multiple languages. We know that multiplies addressable markets without a lot of cost or complication. Let’s reap the same benefits for VCs.


We’re on an interop journey. This is a process we undertake together; no single vendor or ecosystem can afford to do all the heavy lifting for convergence. Hyperledger is trying to converge with the other communities and is willing to sign up to do more. A few judicious investments, made now, could go a long way toward bridging the gaps. All of us that sell SSI technology know our customers would love it. Shall we join together to make it happen?