Unlike what we’ re tempted to think, identity is not limited to a number assigned by a government — it’s much broader and simply means “Who are you?”. There are many answers to that question, depending on who is asking and what you expect from each other.
Also, the source of the response plays a great role in the outcome of the conversation: in some contexts you can claim “I’m 21”, while in others there will be an expectation for that claim to come from a particular third party.
The figure below shows 3 components that prove identity every day.
An identified subject that makes a claim about themselves and expects a certain outcome in response to that claim. The subject can be an individual, an organization or even a thing.
Example: “I (as an establishment) am authorized to sell alcohol. I expect law enforcement to allow me to do it”.
· A relying part that will make a final decision related to that expectation. The relying part can also be an individual, an organization or a thing.
Example: “I (as a law enforcement officer) will trust that this establishment is allowed to sell alcohol”.
· A credential that is used to prove that claim. It can take any shape, from the tone of one’s voice over the phone (“Hi sweetie, this is mum!”) to a government-issued paper certificate, a concert ticket or a username/password combination. The method used by the relying party to verify the proof depends on the type of proof.
Whether you’re taking a cab, entering a building, buying medicine, driving a motorbike, applying for a job, this pattern is present nearly everywhere, every day. Still, issuers often have to reinvent the wheel and come up with new formats for credentials, for the claims inside them, for verification methods and even for how subjects are identified (name, picture, government ID, email address, username, employee number…). This leads to a lot of wasted time, nearly no reusability of tools, and poor interoperability.
This is where standards come in!
A group of people took the initiative to build a common language and formed 2 working groups at the W3C: verifiable credentials (nicknamed VCs) and decentralised identifiers (nicknamed DIDs). Because identity is sensitive, one important focal point of those working groups is that no one is placed in a position of domination. In other words, keep everything as decentralized as possible so it can be adopted confidently as an internet standard.
The role of private companies
Over the last years, it’s become clear that collaboration with a mindset of open standards, rather than a strategy of silos, is the new approach to competition — often called “coopetition.” Helping as a consulting company is more interesting as we have the opportunity to participate from the viewpoint of a large set of strong businesses all over the world simultaneously.
As part of embracing coopetition ourselves, we increased our activity around a technological area that is specifically designed for collaboration between actors with divergent interests: Blockchain, Distributed Ledger Technologies, and more generally trust-enabling digital architectures.
When we looked around to understand what blockchain could bring to the table for businesses, we realized most use cases could be built on two pillars: Digital Identity and Tokenization. The subject of this article is about Digital Identity because it’s a powerful base for the empowerment of businesses through collaboration.
Identity standards + DLTs for organizations
W3C identity standards caught everis’s attention since their early days (DID wasn’t a proper W3C Working Group yet). We realized there are interesting things to be done by combining them with blockchain technologies. This is a huge potential for businesses and organizations from KYC to delivering reliable information to the world, to the creation of new business models such as the exchange of information between organizations.
Interestingly, both the Verifiable Credentials and the Distributed Identifiers standards are defined in such a way that you can easily build on them — think of those standards as a framework rather than closed protocols — so we decided to contribute not only by using the standards but also by extending them.
In the next section we’ll explain how VC and DID specifications are designed to be extended, and the work being done by everis.
Extending Verifiable Credentials with proof types
A Verifiable Credential (VC) is a machine-readable content made of the following elements:
· A unique identifier of the subject of the credential (e.g. their DID, see below)
· A set of claims about that subject. For example birthdate, citizenship or name.
· The identifier of the issuer of the credential.
· A proof (or possibly several proofs) to make the credential actually verifiable. It can be a cryptographic signature or any deterministic mechanism. The actual mechanism is called type and is listed as an attribute of the proof element.
The VC specification doesn’t actually define the proof type. Rather, it leaves room for anyone to document, publish and implement their own types. At everis, we’re defining a few proof types. One approach is leveraging the Ethereum blockchain, and specifically smart contracts. It’s documented formally, but the simplified idea is the credential hash is stored by the issuer in a trusted smart contract. Some of the benefits of that approach are that the issuer may revoke the credential at any time (bye-bye complex CRL mechanisms), and it’s possible to audit successive status changes. Since only hashes are stored on the blockchain, verification is only possible if given the content of the credential via some other channel — no actual information is leaked on the blockchain.
Using one hash per credential introduces limitations in terms of scalability, so we’re studying a few approaches such as the use of Merkle trees or delegated signatures. We’re also considering using only smart contracts for revocation, since those are normally much less frequent than the original signatures.
Extending Distributed Identifiers with methods
Credentials make claims about individuals, organizations, things, etc. This means at some point you need a way to refer to those entities by some kind of unique identifier. Examples of where identifiers appear are:
· Issuer of a credential
· Subject(s) of a credential
· Optionally, additional entities involved depending on the semantics of the credential. For example a marriage certificate might feature the identities of the two people getting married but also the witnesses, the religious officer involved or maybe a church as an organization, etc.
Verifiable Credentials may use any kind of identifier. However, the problem with most identifier schemes is that they’re generally controlled by someone else. For example, your passport number is assigned by a government. So is your name. Your nickname is probably not unique, or guaranteed to stay unique forever. Your email address is assigned and controlled by an email provider (left part) and by the Internet’s DNS hierarchy (right part), both of which can technically take your address away from you.
What about DIDs? A DID is a globally unique identifier that is guaranteed to be controlled by its subject (thanks distributed ledgers, thanks cryptography!).
Just like for VC proofs, the DID spec is like a meta-standard. It does not define an actual algorithm to generate decentralized identifiers. Instead, it creates a frame for anyone to describe new methods that will do that. All you need to do is to name your method, describe it formally as a standard that will come on top of DID, publish it to the world, and start using DIDs, and bonus points if you can build software that actually implements it to help others make sense of your identifiers.
At everis, we created a DID method based on Ethereum and we called it “GID”, or “Global ID.” As for proof of ownership, we’re defining a separate protocol called “DID Connect”, derived from OpenID Connect but decentralized. It’s a work in progress, so we really hope you’ll take a look at it and use it, criticize it, or contribute if you’d like!
We see Digital Identity as a powerful base for the empowerment of businesses through collaboration.
At everis, we believe actual code also has importance, so we made KayTrust, a trust suite that packages credentials, DIDs, and business logic together.
KayTrust is meant for private and public organizations that would like to leverage Digital Identity. It’s super modular because we know every business has different needs.
Let’s introduce the main members of the KayTrust family.
KayTrust Hub is a credential store that’s super smart and collaboration-oriented. It’s able to store credentials, share credentials to clients and other instances of the KayTrust Hub, forming a mesh network, based on search criteria and/or specific sharing rules. This enables neat business models such as billable credential sharing between organizations — always with user consent thanks to OAuth 2.0.
KayTrust Provider issues credentials, from request to approval to actual issuance — APIs and frontends included. KayTrust Provider is able to issue new DIDs on the fly as well as issue credentials to users’ existing DIDs, and can take care of recovery so that users never lose control of their identity even if their device is stolen.
KayTrust Wallet is a decentralized mobile app to keep your credentials at hand. It’s available for Android and iOS and lets you store your credentials and share them easily at your own discretion. No cloud service here! It can also handle multiple identities, so your rock-star, boring-manager and poem-writer personalities will stay happily separated.
The KayTrust Suite also includes components such as a graphical credential viewer and SDKs, to make everyone happy.
At everis we’re excited to be part of this historical move. Besides helping our customers, we’re also involved in larger communities such as Alastria and LACChain that seek an alliance of efforts and the adoption of open standards to help social and business development everywhere.