Originally posted on DAVID LUNA’S DIGITAL IDENTITY BLOG ~ https://luna.co.uk
“Wallet-Based Credentials” refer to the issuer/holder/verifier (IHV) model of cryptographically-provable credentials in digital identity, as well as the technology and ecosystems that surround them.
The term is not meant as a replacement for the existing names, but rather as a superset that is somewhat all-encompassing. It’s especially useful when speaking to non-technical folks, or people not directly involved in digital identity through more traditional routes such as via IAM. It’s relevant when the concept wants to be discussed in an implementation-agnostic fashion – for example when it doesn’t matter about details such as which credential format is being used, or what infrastructure is used for key storage.
To understand where this name comes from we need to look at some of the goals that were top of mind when deciding to use it. We also need to look at other names that already exist in this space, and how they differ.
The Goals
It’s important to remember that while the IHV model is becoming increasily familiar to the identity community, it’s still a novelty to many both inside and outside of it. If this new paradigm is to be widely adopted it’s important to speak outside of our own circles, and use language that easily introduces the concept. With that in mind, here’s the criteria I consider most important.
Easy to understand – conversations happen fast and the core concepts have to be understood by technical and non-technical people alike. The longer time spent defining and explaining the name, the less there is to extoll its virtues or explore the proposition in more detail.
Relate new concepts to those that are already established – by defining a newer concept in relation to an established one, the audience is helped to bridge their understanding to previously unfamiliar thinking. Terms like “passwordless” and “social login” are fine examples of this.
Focus on the concept, not the implementation details – speaking in language that’s too specific can lock conversations to a given implementation, setting expectations or assumptions early that may not be desired.
Not collide with existing terminology – similar to being easy to understand, terminology should be clear to the audience. It must not be easy to confuse with other concepts – especially those already in the identity sphere.
Let’s look at some alternatives, from worst to best.
Blockchain Identity
“Blockchain identity” is a bad name. Not easy to understand, it doesn’t tell the audience what’s going on – other than it includes the magic word “blockchain”. Blockchain itself is still viewed with skepticism by very many people, and recent “Web3” developments that have broken into the public awareness such as NFTs have done little to break that trepidation.
“On-chain” vs “Off-chain” – Is the user’s identity stored on a blockchain? I sincerely hope not – an identity is not an immutable thing that should be forever written into digital ledgers – though perhaps some “on-chain” proponents would disagree. In the better-defined “off-chain” model of blockchain identity it is simply that the blockchain is used as the public key storage location.
While the storage of public keys on the blockchain is a possible implementation route of the IHV model, it is by no means required. There are many reasons that issuers may not wish to use blockchain (permissioned or public) as their key storage medium, especially while the concept is still to be proven at scale. The use of the name “blockchain identity” instantly precludes these, or at least requires constant caveats to be added.
While it does manage to relate itself to existing technology, and its use does evoke the concepts of wallets and cryptographic proofs, “blockchain identity” is by far the worst of the names presented here.
Self-Sovereign Identity (SSI)
“Self-sovereign identity” or SSI, is a tricky term. Its origins are well-explained in chapter 16 of the authoritative book on the subject – Self-Sovereign Identity, and the issues with the term itself are addressed early on in the first chapter. However, despite its pedigree and widespread use in the identity community, to someone coming to it for the first time it’s hardly self-explanatory.
It could be argued that SSI relates easily to existing concepts, but I’m not sure I agree. While “sovereign” is certainly an understood notion, “self-sovereign” doesn’t appear as a phrase outside of SSI itself. It also – sorry to say – comes with a lot of baggage, as the book readily addresses (really, go buy the book, you won’t regret it). Ask a lay-person what some of the key features of self-sovereign identity may be, and without prompting it’s hard to believe they will mention decentralised digital identity, credentials, wallets, or any of the core components that are relied upon to bring the IHV model to life.
It’s a great term for those of us inside the industry, and when both parties in the conversation have a clear vision of what flavour of IHV they’re discussing.
It covers by far the most ground of all the other phrases mentioned in this piece, as early on it was associated not just with the decentralised aspects of IHV, but also with their associated governance frameworks. However, it’s not a phrase that I want to use to my friends down the pub as I attempt to convince them of the brave new world of user-centric, wallet-based interactions that I’m excited to see become widely adopted.
Decentralised Identity
“Decentralised identity” is also somewhat tricky. It highlights well the key difference between the legacy model of centralised storage of user data and the distributed, user-centric nature of the IHV model. It may not specifically conjure the notions of wallets and credentials, but it does imply that something is stored somewhere other than in
It doesn’t worry about the implementation details at all, and its unambiguous in the industry as to what it covers.
However, in conversations I’ve bene in discussing this term, questions have been raised regarding “how decentralised?”. It’s easy to get caught up in these specifics. Similar to “blockchain identity” above, if an issuer does not wish to use a public ledger as their key storage layer we’re back down in the weeds of concerns around issuer-controlled key registries, and having to add caveats as we go.
As with “self-sovereign identity”, “decentralised identity” is a great term to use once both parties in the conversation have a common understanding of the specific flavour of IHV they’re discussing.
Verifiable Credentials
“Verifiable credentials” is a good name. It ticks the first three boxes of the criteria.
It’s easy to understand – we’re talking about credentials that are verifiable. Boom. Nailed it.
It relates to the existing concept of credentials, and adds on the verifiable aspect of it, all without worrying the audience with the implementation details of exactly how the credentials are verified.
But it falls short, and falls short hard, on the final piece of our criteria. The W3C Verifiable Credential Data Model is a specific implementation of the IHV model. Having to differentiate between “verifiable credentials” and “W3C Verifiable Credentials” makes introducing the concept to people unfamiliar with either hard to do. If I want to speak about ISO 18013-5 (mobile driver’s licenses) as a potential credential format for someone interested in implementing the IHV model, calling it a “verifiable credential” introduces confusion.
Wallet-Based Credentials
In contrast to the above, “wallet-based credentials” ticks all the boxes.
It’s easy to understand – the credentials are wallet-based. It puts the two core aspects of the technology that are relevant to the end-user front and center.
It relates to the already understood concepts of digital wallets, and (to an admittedly lesser extend) credentials. Indeed, even people that have no concept of a digital identity wallet are often familiar with their phone’s digital wallet as a medium for the storage of payment cards, loyalty cards, tickets, etc. Because of the use of these more generic terms, it doesn’t collide with any existing terminology.
It also doesn’t worry at all about the implementation details. The credentials in question may be W3C Verifiable Credentials, or they may be ISO 18013-5, or some other method that emerges in the future. They may adhere strictly to the user-centric principles of SSI, or they could be issued and controlled post-issuance by the issuing entity.
“Wallet-based credentials” doesn’t care – all it cares for are that the credentials are based in a wallet!
