Summary
An identity metasystem like the Sovrin Network provides the foundation for creating tens of millions of interoperable identity systems for every conceivable context and use. This post discusses how These identity systems are built, illustrative use cases, and the potential marketplace for credentials.
A metasystem is a system of systems. Metasystems employ protocols, governance, and convention to provide interoperability between the systems they comprise. Perhaps the most familiar example of a metasystem is the internet. The internet is not so much a communications system as it is a system for building communication systems that all interoperate.
An identity metasystem is a system for building interoperable identity systems. The concept of an identity metasystem was first introduced by Kim Cameron in 2005 (PDF). In describing this system, Kim said:
We need a unifying identity metasystem that can protect applications from the internal complexities of specific implementations and allow digital identity to become loosely coupled. This metasystem is in effect a system of systems that exposes a unified interface much like a device driver or network socket does.
The goal of an identity metasystem, like Sovrin Network, is to connect individual identity systems and allow them to interoperate since no single system meets the needs of every digital identity scenario. By providing a unifying protocol and consistent user experience, the metasystem creates the framework within which these identity systems are built and operate.
The Sovrin Identity Metasystem
I've spoken about the Sovrin Network as an identity metasystem before. The metasystem uses credential exchange as the unifying protocol for exchanging identity information. In credential exchange, an issuer issues a credential to a person or organization called the holder. The holder holds one or more credentials uses the protocols provided by the metasystem to prove things about themself to a verifier who needs trustworthy attributes. Figure 1 shows the layers of this system.
In this figure, the orange box represents the metasystem. The metasystem provides a universal means of discovering issuer identifiers and credential definitions in the ledger layer, and a universal protocol, called DIDComm, for connecting and sharing credentials in the agent layer.
The blue box on the top of Figure 1 represents an identity system built on top of the metasystem. There's more than one. In fact, there's tens of millions, maybe more. Every credential definition represents a new identity system created for a specific context. Anyone can define a credential for any purpose. And even though each identity system stands alone for its own purpose, they are interoperable because they are built on top of the metasystem.
For example, I may have a credential representing my drivers license and one representing my employee ID. These are designed for a specific purpose by the DMV and my employer. Yet, because they're based on a metasystem and use a common protocol, I could go to the bank and use those in concert to prove that I'm employed (employee ID) and my date of birth (drivers license) at the same time in one operation.
The two systems have different properties. The identity metasystem (orange box) provides important assurances about the fidelity of the credential. Specifically, the metasystem cryptographically assures (a) the identifier of the issuer and that (b) the credential was issued to the holder who is presenting it, (c) hasn't been tampered with, and (d) hasn't been revoked.
A credential verifier who receives a proof is concerned about credential fidelity, but they are also concerned with the credential's provenance: who issued it (not just their identifier) and on what authority they issued it under. Provenance depends on the design of the context-specific identity system (blue box). The verifier may ascertain the provenance of the credential in any way that satisfies them. In some cases, they may know about the issuer directly (e.g. many banks would know about local employers). In other cases, they may rely on things the business can prove about itself (e.g. I can determine if a business is a legally registered entity and other information from credentials they can present such as a business registration credential). Still further, the business may be part of a larger, formal organization that governs how they operate (e.g. an accredited university or a regulated bank). These latter are trust frameworks. Many already exist and I believe verifiable credentials will lead to the creation of many more.
The fidelity provided by the identity metasystem, combined with the credential provenance provided by the context-specific identity system operating on top of it, provides the basis for trusting the information that the holder has conveyed through credential exchange.
Identity Systems
When I say "digital identity system" most people probably think of just one thing: authentication. The digital identity systems we've built over the last 30 years are so anemic that it's difficult for us to imagine the kind of rich identity systems that exist in the physical world being available online.
In the offline world, we use credentials to prove things about ourselves to others. Each of these credentials constitutes an identity system, designed and built for a specific purpose in a given context. For example, businesses frequently give employees ID cards. I have one for Brigham Young University (BYU), my employer. I can use it to open doors, get a discount at the bookstore, get a car from the motor pool, and even ride a UTA bus or train. This flexible identity system allows the university to add new functionality over time as needs change. The university sets the rules about who gets an ID card and what it means. Of course, it also has use outside the context of the university, say, for example, at a store that gives discounts to university employees and is willing to accept the ID card as proof of employment.
Businesses are full of credentials. Every form or official piece of paper is a potential credential. Every bundle of data transmitted in a workflow is a potential credential. Here are a few examples of common credentials:
- Employee badges
- Drivers license
- Passport
- Wire authorizations
- Credit cards
- Business registration
- Business licenses
- College transcripts
- Professional licensing (government and private)
Here are some others that may not be typically thought of as credentials, but fit the definition:
- Invoices and receipts
- Purchase orders
- Airline or train ticket
- Boarding pass
- Certificate of authenticity (e.g. for art, other valuables)
- Gym (or any) membership card
- Movie (or any) tickets
- Insurance cards
- Insurance claims
- Titles (e.g. property, vehicle, etc.)
- Certificate of provenance (e.g. non-GMO, ethically sourced, etc.)
- Prescriptions
- Fractional ownership certificates for high value assets
- CO2 rights and carbon credit transfers
- Contracts
Since even a small business might issue receipts or invoices, have customers who use the company website, or use employee credentials, most businesses will define at least one credential and many will need many more. There are potentially tens of millions of different credential types. Many will use common schemas but each credential from a different issuer constitutes a different identity credential for a different context.
With the ongoing Anoncreds 2.0 work in Hyperledger Aries, these use cases expand even further. With its “redeemable credentials” feature, issuers can double-spend-proof proving credential possession without a ledger. This works for all kinds of redemption use cases like clocking back in at the end of a shift, voting in an election, posting an online review, or redeeming a coupon. If these use cases are interesting to you, please join the Aries WG calls and contribute.
You might notice that many of the things listed in the second list are solutions some people advocate building entire blockchains for. That's overkill when you can use a credential to get the job done. Especially when that credential is interoperable with others in a ubiquitous identity metasystem. By double-spend proofing credentials, you create a system capable of representing value of all sorts. Bottom line: an identity metasystem for trustworthy credential exchange has uses far beyond what we might typically think of as an "identity system."
A Marketplace for Credentials
Many credentials will be created for internal or non-commercial purposes (like the employee credential). But some will have a supporting business model. This is exactly what happens offline where many credentials are exchanged for money. The metasystem should support credential business models to achieve ubiquity. Daniel Hardman discusses this in his excellent blog post about Categorizing Verifiable Credentials.
Credentials may intersect with payment in different ways. Some may be issued and used for free; others may be purchased; still others may incur a fee with every use. And while payment could be viewed as entirely independent from credentials, the binding is actually more interesting. This is because economics and levels of assurance are intertwined. For example, a top-secret security clearance may require thousands of dollars of field work and investigation, and bump its holder’s salary by even more. Thus, business models that allow economic value to be harvested in any and all credential interactions are a no-brainer.
With non-free credentials, who pays whom is interesting. The most straightforward model is probably holder-pays-issuer; we already expect to pay a fee when we apply for a passport. But other variations are equally possible, and they represent potential innovation that’s been somewhat impractical with physical credentials. For example, a holder that’s applying to a university might pay the university a fee to verify their academic credentials. A potential employer with stringent security requirements might pay an issuer to achieve assurance that an applicant has a government security clearance. A medical researcher might pay a holder for the privilege of verifying genetic information from credentials, as part of a study they’re conducting.
While it's impossible to anticipate every possible credential use case that includes a reciprocal exchange of value, looking at a few use cases is instructive. The following use cases are just for the Holder-Pays-Issuer pattern, but other patterns, like Verifier-Pays-Issuer, are possible.
Drivers License—Drivers licenses are an excellent example of a credential people pay for. There are 112MM licensed drivers just in the US. If we assume each license costs $30 and is renewed every five years, almost $700 million is paid per annum for drivers licenses.
Memberships—Memberships in gyms are just one example of a membership credential where the credential holder pays the issuer. Gym membership revenues in the US in 2018 was $32BB according to Wellness Creatives. There are many more membership types that could be built on top of Sovrin.
Movie Tickets—Movie tickets are another credential that is bought. In 2018, 1.3 billion movie tickets were sold in the US. At $10 per ticket, that's $13 billion.
Airline Tickets—Airline tickets are a special kind of credential that is purchased. According to IATA, there were 4.1 billion airline passengers in 2017. The US Department of Transportation Bureau of Transportation Statistics reports that average airfare was $347 that same year. So we can estimate that worldwide airfare was about $1.4 trillion in 2017.
Online Sales—Online sales could be accomplished using Holder-Pays-Issuer credential exchange. By paying for the receipt (a credential) equal to the amount of the order, you can view all of ecommerce as a form of paid credential issuance. Linking payment to a credential and placing it inside a wallet that emphasizes relationships and credential management may make credential-related payments an important component of online retail. US online retail sales were $519BB in 2018.
These are just a few potential use cases where credentials and value are exchanged. While not all of these will necessarily come to pass, it's easy to conclude that the potential marketplace for credentials is in the trillions of dollars. The identity metasystem, with it's mutually authenticated messaging protocol, is an excellent platform for supporting commercial credential exchange. These workflows, with built-in value exchange, can be developed on the identity metasystem.
Supporting Value Exchange
I believe decentralized systems need a built-in method of value exchange in order to thrive. A credential marketplace is a great example why this would be important in an identity metasystem. A native means of exchanging value has several advantages over doing it outside of the network.
- First, information received from credentials can't easily be pulled back if payment isn't received. By incorporating credential exchange and value exchange in the same network, the system can ensure finality1, eliminating the need for escrow in many situations.
- Second, a native payment mechanism reduces friction because people building identity systems don't have to source and integrate a separate payment system if the native system meets their needs.
- Third, a native payment mechanism could provide payment services at greatly reduced fees when compared with external payment networks.
- Lastly, and most importantly, a native payment system can ensure that the integration of payments doesn't inadvertently provide a correlation path and compromise privacy
Conclusion
An identity metasystem like the Sovrin Network provides the foundation for creating tens of millions of interoperable identity systems for every conceivable context and use. By virtue of being built on the metasystem, these identity systems share a common protocol and similar user experience. The metasystem is available to all and is decentralized, allowing each participant to make their own decisions about what identity systems they will build and participate in to support their goals and ambitions.
Notes
- Finality is the ability to know that the payment for a transaction is complete before finalizing the transaction.