Self Sovereign Identity (SSI) is an umbrella term well-detailed by Christopher Allen, and inspired by many in the Identity community before him, in his 2016 blog post: The Path to Self-Sovereign Identity, which identifies Ten Principles of Self-Sovereign Identity:
- Existence. Users must have an independent existence.
- Control. Users must control their identities.
- Access. Users must have access to their own data.
- Transparency. Systems and algorithms must be transparent.
- Persistence. Identities must be long-lived.
- Portability. Information and services about identity must be transportable.
- Interoperability. Identities should be as widely usable as possible.
- Consent. Users must agree to the use of their identity.
- Minimalization. Disclosure of claims must be minimized.
- Protection. The rights of users must be protected.
Since 2016, a lot has happened! There have been a flurry of conventions, discussions, papers, standards, software, and industry wide adoption of technology based on the principles of SSI. The space is at its most mature, and only growing.
Block’s mission is economic empowerment. Historically, this has looked like building products and offering services such as Square, enabling millions of merchants to take payments, manage staff, and conduct business in-store and online, and CashApp, which enables millions, especially the un and under-banked to send, spend, bank, and invest their money (and Bitcoin!). When TBD, a new business unit at Block formed in 2021, we expanded on Block’s mission, setting out to help create a decentralized future that returns ownership and control over your finances, data, and identity. TBD’s mission is strongly aligned with the principles of SSI.
To facilitate our mission, TBD launched Web5: a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols. Web5 takes SSI concepts, standards, and software and provides them as an opinionated bundle to enable all that self sovereignty and digital identity has to offer. What TBD is building for Web5 has a number of components today, and more tomorrow. Among those are the Self Sovereign Identity SDK and Self Sovereign Identity Service (SSI SDK, and SSI Service), Decentralized Web Nodes (DWN), and Identity Wallets. At the time of writing, all of these components are under active development. This was an intentional move by the team to adopt an ‘open-by-default’ model, and include the community in the development of Web5 from the beginning.
Here we’ll lay out the vision for a key component of Web5: Self Sovereign Identity. Specifically, how we at TBD are building standards based software in a community towards the goals of SSI and Web5. The two “SSI” named projects — the SSI Service and SSI SDK — sit along side Decentralized Web Nodes, Identity Wallets, User Interfaces, and much more — but focus on a set of standards-based building blocks of the Web5 stack.
Software Mission
TBD is developing open source, standards-based software to facilitate Self Sovereign Identity on Web5.
Open Standards
The vision of SSI is realized via Open Standards. Crucially, these standards are accessible to all: to view and to contribute. You may not be aware of it, but you interact with Open Standards every day: whether via web browsers, hardware you use and their underlying protocols, programming languages, audio files, internet and bluetooth devices, text documents, chat applications, encryption you use and so much more. Open Standards facilitate nearly every aspect of modern computation.
In the SSI space there a number of standards bodies that facilitate SSI-standard development. Though we may utilize specifications in multiple organizations such as the IETF, OpenID Foundation, the World Wide Web Consortium (W3C), and Decentralized Identity Foundation (DIF). TBD’s focus thus far has been primarily with the W3C and DIF organizations:
The W3C
The W3C, founded by Tim Berners-Lee in 1994, is one of the most prominent international standards organizations for the web. The W3C has a number of group types. Community Groups are the most open. The Credentials Community Group focused on Verifiable Credentials, and often serves as a staging ground for the Verifiable Credentials Working Group, responsible for the Verifiable Credentials Data Model (i.e. the Verifiable Credentials specification). The Decentralized Identifier Working Group is responsible for Decentralized Identifiers (i.e. the DID specification).
TBD is a member of the W3C, actively utilizes the work items from all three groups, and has made contributions to each group’s corpus.
The Decentralized Identity Foundation
The Decentralized Identity Foundation, or DIF, was founded in 2017 to focus on Decentralized Identity. Since then, it’s expanded to house a number of working groups around Identifiers, Claims & Credentials, Sidetree, Secure Data Storage, Wallet Security, Interoperability, and more. DIF produces technical specifications, reference implementations (as in the case of Sidetree and ION), and coordinates standards and software implementations for players across the industry.
TBD is a member of DIF, regularly attends working groups, contributing to both interoperability projects, specifications, and technical implementations.
Standards in Use
The set of standards we rely on and use for Web5 is unbound. However, we have a good sense of the standards we begin with. The list below will likely soon be out of date. Consider it as a reference as you orient yourself with what we’re working with.
| Specification | Standards Body | Description | Status |
|---|---|---|---|
| DID Core | W3C Decentralized Identifier Working Group | Decentralized Identifiers v1.0. | Recommendation |
| DID ION | DIF Sidetree | A layer 2 Decentralized Identifier network that runs atop the Bitcion blockchain, built on the Sidetree protocol. | Ratified Specification |
| DID Key | W3C CCG | A simple method to create a DID using a single cryptographic key. | Unofficial Draft |
| DID Web | W3C CCG | A DID method that allows bootstrapping trust using a web domain. | W3C Internal Document |
| DID Peer | DIF Identifiers & Discovery | A DID method that can be used independent of any central source of truth, intended to be “cheap, fast, scalable, and secure.” | Draft |
| Verifiable Credentials Data Model | W3C Verifiable Credentials Working Group | The Verifiable Credentials Data Model v1.1. | Recommendation |
| Data Integrity | W3C Verifiable Credentials Working Group | Describes mechanisms for ensuring the authenticity and integrity of structured digital documents…such as digital signatures. | Editor’s Draft |
| JSON Web Signature 2020 | W3C Verifiable Credentials Working Group | A cryptographic suite for the purpose of creating and verifying proofs for JSON Web Signatures using Linked Data Proofs. | Editor’s Draft |
| Verifiable Credentials JSON Schema | W3C CCG | A mechanism to use JSON schemas to back a Verifiable Credential. | Draft |
| Status List 2021 | W3C CCG | A privacy-preserving, space-efficient, and high-performance mechanism for publishing status information such as suspension or revocation of Verifiable Credentials. | Draft Community Group Report |
| VC Proof Format Test Suite | DIF Claims & Credentials | A test suite providing interoperability testing and reporting for Verifiable Credentials and Presentation for Linked Data and JWT signature types. | Unofficial Draft |
| Presentation Exchange | DIF Claims & Credentials | A claim format and transport envelope agnostic format for Verifiers to articulate proof requirements, and for Holders to describe proofs according to those requirements. | Working Group Draft |
| Credential Manifest | DIF Claims & Credentials | A common data format for describing the inputs a Subject must provide to an Issuer for evaluation and issuance of credentials, a means for a Subject to submit an application against those requirements, and a means for an Issuer to fulfill such an application. | Pre-Draft |
| Trust Establishment | DIF Claims & Credentials | A means of communicating trust statements and relations between parties in decentralized identity environments. | Pre-Draft |
| Decentralized Web Node | DIF Secure Data Storage | A DWN is a data storage and message relay mechanism entities can use to locate public or private permissioned data related to a given DID. DWNs provide multi-node sync, enabling the owning entity to secure, manage, and transact their data with others without centralizing factors. | Draft |
For brevity, I only included fifteen of the most prominent specifications comprising the foundations of the SSI stack in Web5. There are at least another half dozen either included or planned to be included in our software.
TBD Community
TBD is interested in building a space for community-driven projects, community members gaining merge and moderation access to community resources, and growing a diverse set of contributors interested in a broad set of use cases to be built on Web5.
We are not interested in becoming a standards body itself. Instead, we are focused on fostering a self-sustaining community focused on building and building on Web5. To facilitate this, we can expand our existing tools like adding sections of our Forums, creating new Discord channels, creating new purpose-specific GitHub repositories and investing in new tools for collaboration like an ideas board, job listing page, or a Web5 wiki. I’d love to see a Web5 incubator similar to Y Combinator that facilitates those building on Web5. The future’s possibilities are endless, and we are eager to adapt to the evolving needs of the community.
Sometimes, we may need more rigorous structure. As such, we are interested in forming working groups in the Web5 community where it makes sense. The output of these groups could be industry coordination, use-case building, software development, or even standards-related work that can be contributed to existing standards bodies. TBD has kicked off one such group to date around Credentials, first focused on creating a path for Know Your Customer (KYC) Credentials. This group already follows such a pattern: having built out use-case documentation in GitHub, having a purpose-specific Discord channel, and forum category. Soon we’ll adapt this group to a more “office hours”-style format, allowing anyone in the community to show off their work, ask for assistance, and help shape our project development roadmaps.
Today we have one GitHub org, run by the TBD team. We will open up roles for community management. Creating light processes for community-driven moderation and maintenance (e.g. managing pull requests, issues, labels, and milestones), in addition to having projects and repositories started and managed entirely by members of the community. One such idea we are considering is for a new GitHub organization for the “Web5 Community” to foster and highlight community-driven efforts. We’re additionally looking to launch an Incubation program that gives a formal path towards recognizing and promoting the work that begins in a grassroots manner in our community. We plan on making the rest of our tooling community-driven as well: today this means Discord and the Forums, tomorrow it will be a lot more!
While this is something we are focused on internally, it is crucial that you as community members are able to make suggestions, plans, and directly influence change. Reach out on Discord, our Forums, gain mindshare for your ideas, and we will help make them a reality.
Open Source
The foundations of Web5 are open source. This means that its source code is publicly available and, as stewards, we rely on external contribution—Web5 is only successful with the full innovation of a global community. Certainly there are cases where code cannot be open source for various reasons: this applies to the TBD business as well as members of our community. We do not mandate open source, but it is a guiding principle. We believe in the power of open, and all that comes with it. The more open Web5 can be, the better it will be.
Projects in the TBD GitHub may originate at TBD, or through the community (on our Discord, Forums). Today, the TBD team is acting as the primary steward and maintainer of all projects. As the community matures, we expect it to take the lead and for TBD to assume a higher-level maintainer role. We imagine this ends up looking like more community-driven projects, community members gaining merge and moderation access, and growing a diverse set of contributors interested in a broad set of use cases to be built on Web5. More broadly, we want to push forward to a world where TBD does not have the only, or final say on any Web5 decision: decentralization is a strength in the development of Web5.
This transition is only made possible by active engagement from the community. It is the reason our code is open, and we have set up avenues for engagement. We look towards the community to engage with TBD and others, and push for the future we wish to see built.
Software Vision
TBD is fostering a set of community-driven, open source, standards-based software to facilitate Self Sovereign Identity on Web5.
We want to realize the vision of the Web5 community: to build pragmatic standards-based software that serves a wide variety of needs. The software shall not be tied to any specific entity, nor, without good reason, exclude possibilities within the SSI space. Balancing both feature-richness and complexity we must work closely with our users to design software that meets the needs of all who wish to be on Web5. We think in terms of toolkits, composed of the purpose-specific tools in them. These toolkits exist in a hierarchy of abstractions from which powerful, intuitive, and human-centric software can be built.
The software must be designed in a flexible, modular manner. This means interfaces that feature a default implementation or two, but can be extended to facilitate integration into many systems (e.g. swapping out databases, encryption methods, credential formats as needed). The software is intended to be built on open standards in the SSI space. The standards space is fast-changing and there may be cases where we use ill-defined and ill-supported standards; we must be able to favor practicality and working implementations over robust standards with a commitment to see the standards through. There may be cases where we use our software to innovate past the current state of these standards and open the opportunity to contribute back to existing standards and standards bodies.
We recognize that the SSI ecosystem is full of competing and developing standards. Often this can feel like developing against a set of moving targets and promises of feature sets. There’s a lot of information to grok and everyone has an opinion—this is a good thing! It can be difficult to pick winners, and even more difficult to choose between multiple standards that appear to do the same thing: we do not want to create a Swiss Army knife that contains five different types of scissors, we’d rather it contain one (or maybe two) scissors that get the job done well 99% of the time. We favor evaluating the addition of features and standards on a case-by-case basis, and looking towards implementations of standards and features that are well-reasoned, with committed developers. Bonus points if there is already demonstrated usage and interoperability.
We also recognize that the SSI ecosystem uses a wide set of tools, languages, and technologies: working across web browsers, mobile applications, backend servers, ledgers, and more. For languages we’ve started with Go (for the SSI SDK and SSI Service) because of its robust cryptographic support, speed, ability to be compiled to WASM, and, above all else, simplicity. It is crucial that the code we write is approachable to encourage contribution. Simple and clear is always preferred over clever. The future is multi-language, and multi-platform. We welcome initiatives for improving multi-language and multi-platform support, and are open to fostering them into our GitHub organization.
SSI SDK
Named ssi-sdk, this SDK encapsulates a set of standards related to Self Sovereign Identity. The ssi-sdk intends to provide flexible functionality based on a set of standards-based primitives for building decentralized identity applications in a modular manner: with limited dependencies between components.
Primarily, the SDK serves to support Decentralized Identifiers and Verifiable Credentials and their associated standards. Interacting with Decentralized Identifiers: resolving identifiers, signing, verifying, encrypting, and decrypting data using cryptographic keys found in DID Documents. Interacting with Verifiable Credentials: creating and using data schemas, facilitating credential application, issuance, and exchange.
The SDK is an active work in progress, and can be found on the TBD GitHub.
SSI Service
The Self Sovereign Identity Service (SSIS) facilitates all things relating to DIDs and Verifiable Credentials — in a box! The service is a part of a larger Decentralized Web Platform architecture. The SSI Service is a JSON-API web service that wraps the ssi-sdk to facilitate user-focused interactions on Web5. The service is intended to interact with user interfaces, wallets, decentralized web nodes, and other web infrastructure.
By taking the lower-level building blocks exposed by the SDK, the service is intended to drastically lower the barrier to entry for any individual or organization interesting in building on the Web5 stack. Like the SDK, it is agnostic to any specific business or use case, and design to be pluggable into external infrastructure whether existing or new.
The service is assumed to be run by a single organization and assumes external authentication and authorization. The service assumes no infrastructure requirements and is flexible to multiple deployment models, databases, key management solutions, and user interfaces. We expect that a wide array of users and use cases will use and build on top of the service, creating layers of abstraction and intermediation for processing business logic, handling user accounts, and so on.
The service is an active work in progress, and can be found on the TBD GitHub.
How Features are Developed
We are in the early days of Web5. By intention, we’ve announced our ideas and projects way before they are ready for an alpha release, let alone inclusion in a production-ready application. Transparency is an asset in sharing our thinking and gaining mindshare for what we are building. As such, there are many forks in the road fast-approaching. To move past these forks, and the forks after those I introduce some light process to guide principled decision making:
- Features shall be developed using the Socratic method: making statements, interrogating them, asking whys and hows, being intellectually honest with risk, uncertainty, consider second, third and n-order effects.
- All new feature proposals shall include a light design document outlining desired functionality, end-user utility, prior art, room for improvement and next steps, risks and mitigations, considerations, and open questions.
- A quorum of project maintainers shall review and progress feature proposals in a timely manner.
Templates for the aforementioned process have been created on each GitHub repository. I encourage you to create GitHub issues and Forum discussions to explore thinking, and revise designs before going forth with a contribution.
For templates on feature development, philosophies on versioning and releases, and more information view our GitHub documentation:
SSI Service GitHub Docs | SSI SDK GitHub Docs
The Goal
I believe in setting public and ambitious measurable goals. This serves as a powerful self-discipline mechanism, as well as a call to action for forward progress. Officially the timeline for Web5 can be found on our site. Unofficially, here is my ambition:
By January 1st 2023 the following shall be true:
- The first beta release of the SSI SDK and SSI Service (0.1.0) will be released.
- Each SSI project will have >75% test coverage.
- Each project will have robust user and developer documentation with clear examples.
- The SSI SDK will have feature complete specification implementations for at least all fifteen standards identified above.
- The SSI Service will be deployable in an infrastructure-agnostic manner, demonstrated on ≥ 2 platforms.
- The SSI Service will facilitate practical end-user flows facilitating:
- Creating and managing DIDs using ≥ 2 DID methods
- Creating and issuing Verifiable Credentials backed by JSON schemas
- Creating Credential Manifests, accepting Credential Applications, and fulfilling Credential Applications
- Creating Presentation Definitions, sending Presentation Requests, and accepting Presentation Submissions
- Creating Credential Revocations and checking Credentials against them
- Creating and processing Trust Establishment documents
- The SSI SDK and Service will support the Decentralized Web Node specification and the Service will work with at least one DWN.
Parting Thoughts
You should now have a pretty good sense of how we conceive of SSI software on Web5, and how its journey will unfold. Most importantly the mission is not TBD’s alone, it is that of the community. We build real software for real people and favor pragmatism above all else. What I’ve written here is current thinking and is always subject to evolution—with your help. I’m looking forward to you joining us in pushing SSI and Web5 forward, gaining new perspectives, solving new use-cases, and building some cool shit.