Building Blocks for a New Architecture
Note: These are my opinions only, and not that of my employer. All information used in developing this post is open and freely available. No statements should be considered as advice or representing an official position. The material contained within are my thoughts in progress and are provided to encourage discussion and further insight.
To do the best thinking, I like to have a complete picture in my mind. When I say ‘picture’, it’s more like a diagram, that has only the important details at hand to help me along with my thinking. Any extraneous detail, I throw out, so that I have a solid skeleton of a foundation to work with before I build further.
Use Cases
For the last few months (please see my previous posts), I have been thinking about the problem (or opportunity, depending on which way you look at):
‘What would we need in a digital infrastructure so that I could trust it, but not trust it?’
I know that this problem sounds like a contradiction in terms, but what I am looking for is something like what I’ve been starting to call a trust-minimized platform — something you can trust for one thing only and no more. This is unlike many of today’s digital platforms — you have to trust them — until your data is breached, or used for purposes for which you don’t agree. When that happens, it is usually too late for further choice. That’s what’s motivated me to look for and define this new notion of a trust-minimized platform and understand what the building blocks for a new architecture might look like. This is what I’ve come up with so far:
After looking at the many different digital platforms and mechanisms: centralized, decentralized, proof-of-work, proof-of-stake, the list goes on, I have concluded that all of these new platforms boil down to fulfilling three core societal functions: value, identity, and status, underpinned by consensus. I’ve tried to crystallize this generalization in a use case class diagram shown below:
The first thing you will notice, that this is not your typical (hierarchical) class diagram, with the most general class at the top, branching into various sub-classes. In my analysis of the various schemes out there (Bitcoin, Ethereum, Sovrin, etc.) they all seem to have the same four elements (identity, value, status, and consensus);
- Identity — an address or identifier that denotes a thing, or can be related back to a person. It is usually cryptographic in nature, such as a Bitcoin address, or a decentralized identifier (or DID, described later in this post)
- Value — a ledger entry of some sort, indicating a balance or an account reckoning.
- Status — a state, or more specifically a change in state (state transition) resulting from executing a transaction.
- Consensus — a method of agreement that all actors have confidence in.
Despite the commonalities above, there are three different types of use cases driven by a community. Looking at the diagram, you can see three types of use cases existing on the edges: assets, exchange, and obligations. All of these use cases are also underpinned by consensus.
Relating this model back into the real world implementation: Bitcoin is focused on the exchange of value, Sovrin is focused the control of an asset (identity), and Ethereum is focused on the execution of contracts (smart contracts). These are very different (and purpose-built) platforms, having common elements, but serving very different use cases.
So far, I’ve been using this diagram to map any scheme into one or more of these three use case types. I can seem to describe in terms of these types.
Another insight that I have had, is that the characteristics such as centralization versus decentralization or proof-of-work versus proof-of-stake, as deployment options, not as strategic choices. For example, Bitcoin stakeholders may want a censorship-resistant system; while Sovrin may want a group of accountable validators. And these deployment options can evolve and change over time (Ethereum moving to proof of stake)
From these elements, it is possible to build analytical framework to describe any decentralized system that can serve a mix of societal functions (value, identity, status), with an emphasis one, two or three of these use cases.
Architecture
Switching from use cases to architecture, below is the diagram I have come up with as a general architecture.
First, you will see the Issuer, Holder and Verifier. This is the archetypal pattern of the decentralized architecture. An issuer issues something to a holder, who then presents it to a verifier, who make a decision. A simple example: government(issuer) issues you a passport (holder), which you present to a border control officer (verifier) who lets you through the gate. When you look at all the use cases (described above), they all fall into this pattern.
You will notice all of the boxes in the gray shaded area — that’s my current thinking of the key building blocks required for a generalized digital architecture. These boxes are only modeled to a degree to understand how they can be standardized, interact with one another, and be swapped out for another if necessary (i.e., not get locked in).
Moving left to right
- Verifiable Credential — this is the form in which claims are issued by an issuer. These verifiable credentials are provided to the holder.
- Agent — this is the software (code) that is acting on behalf of the holder. There are two key functions: storing the verifiable credentials and presenting verifiable credentials, or derivations thereof, as verifiable proofs. The agent construct helps abstract away whether it runs on a mobile device, a purpose-built device, or a cloud instance (or all three!)
- Verifiable Presentation — this is what actually gets presented to the Verifier. The reason this is not just a verifiable credential is that the holder may only want to present a subset of information (e.g., yes or no), a combined proof from several credentials (e.g. over age 19 and enrolled as a student), or a zero-knowledge proof (important, but I don’t have a good example yet)
Moving from top to bottom
- Authorizer — this is the component that conveys intent of the holder. Usually, this is a private key in a wallet, but it can also be something externally held by a holder such as a FIDO2 U2F cryptographic token.
- Store — this is where all of the protected stuff that the agent needs to do its work: verifiable credential, private keys and more.
Finally at the bottom is the Trust-Minimized Base Layer. This is the term I am currently using to generalize blockchain, distributed ledger, etc. This is the component that is mutually maintained by a trusted party (database), trusted parties (proof-of-stake ledger), or mutually suspicious parties (proof-of-work ledgers).
This architecture is then glued together by various standards. These are the ones currently in play:
- W3C Decentralized Identifiers or DIDs. The key value of DID concept is that it abstracts away the trust-minimized base layer into DID methods. This allows the various schemes to interoperate.
- W3C Verifiable Credentials. The standard way to issue claims that are portable. This also included the JSON-LD standard.
A big piece of the architecture is the Digital Wallet. Looking at this architecture, the digital wallet is a composite of the authorizer, agent and store. Standards and implementations are still early days, we are seeing some promising open-source implementation of Hyperledger Indy, Ursa and Aries.
Conclusion
In closing, how does this all hang together? Coming back to the problem statement at the beginning of the post
‘What would we need in a digital infrastructure so that I could trust it, but not trust it?’
The solution is discrete of building blocks as described above. Personally, I’m excited and starting to see the possibility of building a global infrastructure that is open and serves the need of any issuer, holder, and verifier without prejudice (not sure if that is the right term, but I will go with it for now). Maybe it will be a censor-resistant infrastructure like Bitcoin; maybe operated by a set of trusted stewards like Sovrin. Maybe it will be something entirely new. Time will tell. In the meantime, if we focus on what exactly what we want (no more or no less), we can build a global verification infrastructure that we can one take for granted, like the internet or GPS, and more importantly trust without worry.
Note: This is a work in progress and will be updated without notice. Alway pleased to receive constructive feedback.
