
π Dear NGI Community:
In my previous article, I tried to outline the growing complexity of the technical landscape in decentralized digital identity and the fact that alternative technical standards and building blocks often compete (even conflict).
I would like to propose an explanation that such differences may be based not only on objective technical features but also on how they "feel" and on the values and worldviews that are inherent to specific technologies. Following in this article are three examples:
1. DIDComm vs. OID4VC
A protocol for a decentralized identity ecosystem is needed to exchange digital identity credentials. Well-known candidates are DIDComm and the OID4VC (OpenID for Verifiable Credentials) specifications.
Both can be used as protocols for digital identity wallets. But what's the difference, and which one should be used?π€
π‘The superficial explanation: The difference is that DIDComm is a novel, generic, transport-agnostic protocol that can be used for many different applications, including the exchange of digital identity credentials. It originates from early Self-Sovereign Identity (SSI) projects such as Sovrin and Hyperledger Indy. OID4VC, on the other hand, is an evolution of OIDC (OpenID Connect), an immensely successful protocol used for login and identity federation worldwide. The main difference is that DIDComm is more powerful, but OID4VC is simpler and easier to integrate with existing infrastructure.
π‘A deeper explanation: OID4VC is "simpler" than DIDComm, but DIDComm "feels" more decentralized. Despite all the efforts to adapt OIDC to the new world of decentralized identity, at its core, it is still based on the old OAuth2/OIDC model where you always have asymmetrical roles such as "client", "provider" and "relying party". Identifying one side of a transaction happens using completely different elements (client_id, client_secret, proof) than identifying the other (Credential Issuer Metadata). In DIDComm, on the other hand, the technical constructs are entirely symmetrical. You always just have DIDs and "peers" for all transaction participants. Therefore, OID4VC doesn't "feel" as decentralized and egalitarian as DIDComm.
2. W3C VCDM vs. SD-JWT VC:
Another component needed for decentralized digital identity is a data model for digital identity credentials, and again, we have different options. Two primary candidates are the original Verifiable Credential Data Model (VCDM) developed at W3C and more recent proposals such as SD-JWT VC.
What's the difference, and why do those exist?π€
π‘The superficial explanation: VCDM is based on JSON-LD, which has advanced features for expressing the semantics of linked data. However, it is also complex due to the requirement to understand and process an underlying graph of data. SD-JWT VC, on the other hand, is based on the familiar JWT format, which is, in turn, "just JSON." This is simpler to understand and implement.
π‘A deeper explanation: The real difference is how semantics (the "meaning" of data) work. In SD-JWT VC - as in traditional JWT -the semantics are established via some kind of out-of-band context (e.g., a specific use case) or central registries such as the one at IANA. The W3C VCDM, on the other hand, is an "open world data model", meaning anyone can define the meaning of data in a decentralized way without dependency on a central authority. This may seem like an unimportant technical detail, but centralized vs. decentralized semantics can profoundly impact power relations in the digital and physical world.
3. DIDs vs. the "cnf" claim
As a final example, let's examine how digital identity credentials are "bound" to a holder. How do you express that a credential belongs to "me", not to "you"? One traditional way of expressing this in JWT/OAuth2/OIDC-based architectures has been the "cnf" claim (a "confirmation method"), which contains a public key of a holder's device. In the W3C VCDM, however, a credential is typically bound to a holder via a DID, which resolves to a public key.
So what's the difference? π€
π‘The superficial explanation: A "cnf" claim contains a holder's public key. A DID (especially those using DID methods like did:jwk or did: key) also essentially contains a holder's public key. So, there is no real difference; the only difference is the encoding.
π‘A deeper explanation: The "cnf" claim is a technical construct that expresses a public key to which a digital identity credential should be bound. A DID, however, is more than that. It carries with it the idea of "independent existence." It is a digital realization of who you are as an individual in the digital world. Even though the technical capabilities are, in both cases, very similar, the "feeling" of what they express is, in fact, quite different.
β¨To me, arguments pro and contra certain technologies are not only about objective criteria and the features they enable. Privacy is essential, as are features and simplicity. But besides all that, there is also the "hidden" layer of values and worldviews inherent to certain choices.β¨
One thing that bothers me is that in the current EU Digital Wallet's Architecture Reference Framework (ARF) and the various large-scale pilot projects, the technologies that seem to be most popular are consistently the ones that are "simpler" but "feel" less decentralized, i.e. using the examples from this article, OID4VC (not DIDComm), SD-JWT VC (not W3C VCDM), and "cnf" claim (not DIDs).
-----------------
Important News: NGI Talk π’
Are you curious about decentralized digital identity and want to learn everything about it, or are you just wondering about its complexities?
β¨Join me in this NGI Talk: Technology is not neutral: the worldviews behind digital identity standards.β¨
Let's uncover the essence of digital identity technologies together in this exciting activity!
ππΌ Watch it now by clicking here.