The Case for Decentralized Identity

I go back and forth between thinking decentralization is inevitable and thinking it's just too hard. Lately, I'm optimistic because I think there's a good answer for one of the sticking points in building decentralized systems: decentralized identity.

Most interesting systems have an identity component. As Joe Andrieu says, "Identity is how we keep track of people and things and, in turn, how they keep track of us." The identity component is responsible for managing the identifiers and attributes that the system needs to function, authenticating the party making a request, and determining whether that party is authorized to make the request. But building an identity system that is usable, secure, maximizes privacy is difficult—much harder than most people realize.

The problem with decentralized identity is even more acute. Discovery is one of the key features of an identity system. And decentralized discovery is hard. Say, for example, that I have an identifier and need an associated attribute, a public key, for example. In a centralized identity system, there would be a database somewhere that associated identifiers with public keys. Make a query on the database with the identifier and I get back the key. Easy.

But doing discovery without a central database has been hard. Lack of decentralized discovery has made otherwise decentralized systems susceptible to denial of service attacks, insecure, or slow and inefficient.

Distributed ledgers—blockchains—promise to solve this by providing decentralized discovery that is secure and efficient. But just having a blockchain isn't enough. Decentralized identity might start with a distributed ledger, but making a system that is private, secure, and useful requires much more. Blockchains help with discovery, but you still have to worry about how to make key management and attribute exchange secure and private.

Having a global utility for identity solves this problem in a way everyone from the lone developer to the small startup to the global enterprise can take advantage of. In Fat Protocols, Joel Monegro argues:

[B]y replicating and storing user data across an open and decentralized network rather than individual applications controlling access to disparate silos of information, we reduce the barriers to entry for new players and create a more vibrant and competitive ecosystem of products and services on top.

Emerging blockchain-based identity systems are protocols for identity. As Joel says, this means that the applications riding on top of these identity protocols can offer more with less effort. For example, I've argued elsewhere that sharing economy companies like Lyft and AirBnB are based on identity platforms that allow for an exchange of trust. And that having a universal platform that allows anyone to do this accelerates the pace at which these kinds of services could be offered.

But more importantly, a universal, decentralized identity platform offers the opporunity for services to be decentralized. In the physical world, people start businesses all the time without some kind of platform. I lease a storefront, figure out how to get inventory, and my storefront can be up and running. I don't have to be a sharecropper for some large corporation. As an example, I can imagine a universal, decentralized identity system giving rise to apps that let anyone share rides in their car without the overhead of a Lyft or Uber because the identity system would let others vouch for the driver and the passenger.

The need for decentralized thinking has never been more acute. As I wrote in The CompuServe of Things:

My point isn't a narrow technical one. I'm not arguing for an open Internet of Things because of perceived technical benefits. Rather, this is about personal autonomy and ultimately human rights. As I said above, the Internet of Things will put computers with connectivity into everything. And I really mean "every thing." They will intermediate every aspect of our lives. Our autonomy and freedom as humans depend on how we build the Internet of Things. Unless we put these connected things under the control of the individuals they serve without an intervening administrative authority, we will end up building something that undermines the quality of life it's meant to bolster.

The emergence of a decentralized identity platform gives me hope that we can build online systems that respect human dignity. Back to Joe Andrieu:

When we build interconnected systems without a core understanding of identity, we risk inadvertently compromising human dignity. We risk accidentally building systems that deny self-expression, place individuals in harm’s way, and unintentionally oppress those most in need of self-determination.

Photo Credit: Vegetable Vending - Andul Bazaar from Biswarup Ganguly (CC BY 3.0)

Launching the Sovrin Network

This morning I participated in the launch of the Sovrin Network. About six weeks ago, we set up the Alpha network for testing. Validators participated in exercises to ensure the network was stable and could achieve consensus under a variety of circumstances.

This morning we transitioned from the Alpha network to the Provisional network. There are several important differences between the Alpha network and the Provisional network:

  • All validator nodes on the Provisional network are being run by Sovrin Stewards who have executed the Sovrin Provisional Trust Framework (a legal contract) with the Sovrin Foundation.
  • We do not intend to ever reset the ledger. All transactions on the provisional network are "in production."

In short, the provisional network is the real Sovrin network and is open for business. Transactions written to the provisional network will be part of the Sovrin ledger for all time.

The Launch Ceremony

Launching the provisional network wasn't as simple as pushing a button. Rather, launching a distributed ledger involves a ceremony that is designed to give everyone confidence that the network is secure and has no backdoors through the principle of diffuse trust. Multiple participants, in many locations, witness the process of creating the ledger's genesis block. The ceremony ensures that this is done with maximal transparency. Some launch ceremonies have gone to extreme lengths to achieve these goals.

In the case of Sovrin, almost 50 people participated in the launch ceremony from all over the world. The genesis block on the Sovrin ledger holds public identifiers and keys for six Sovrin Trustees and ten Sovrin Stewards. The entire ceremony was recorded and will be made available soon. The ceremony requires Trustees and Stewards who are part of the genesis block to verify their identifiers and keys and allows many parties to witness the incorporation of that information into the ledger. Doing so, provides evidence of the integrity of the ledger and the identities of those participating in its launch.

Now that there is a genesis block, the identifiers for trustees who weren't able to participate today along with those of stewards who join over the coming weeks will be written as new transactions on the ledger. The sandbox network is still available for non-production testing.

Over the coming weeks and months we'll be rolling out additional features and updating the trust framework to fill in a number of additional sections that must be completed, approved, and agreed to before the Sovrin network is declared ready for general availablity.

By the Numbers

Here's some information about the codebase for Sovrin network at launch:

  • Slightly over 130,000 lines of code
  • 721 tickets (stories, bugs) closed
  • 37 contributors from: Italy, Austria, Luxembourg, India, Russia, Venezuela, Finland, USA, and others.
  • Participants from six continents
  • 1012 pull requests
  • Approximately 17.8 person-years of coding and QA effort

Identity for All

This day has been a long time coming. I'm very excited to see Sovrin become a reality. I'm grateful to everyone who has worked hard for this day. Thanks especially to Timothy Ruff, Jason Law, and everyone at Evernym for their dedication and hard work. Thanks to the Sovrin Trustees and Technical Governance Board. I'm also grateful to the founding stewards who have made this possible.

Sovrin provides a global identity infrastructure that supports self-sovereign identity and verifiable claims. Over the coming weeks, we will put in place the means for issuing identifiers on the network and make available information on how people and organizations can start to use Sovrin. This is the beginning of Identity for All.

Update: Here's the recording of the Sovrin launch ceremony. Its not terribly exciting, mostly people certifying things and reading keys. But it is the official record. For reference, stewards were brought online at 1:18:47 and verifying consensus occurred at 1:22:16 in the video.

Identity, Sovrin, and the Internet of Things

Doc Searls put me onto this report from Cable Labs: A Vision for Secure IoT. Not bad stuff as far as it goes. The executive summary states:

IoT therefore represents the next major axis of growth for the Internet. But, without a significant change in how the IoT industry approaches security, this explosion of devices increases the risk to consumers and the Internet. To reduce these risks, the IoT industry and the broader Internet ecosystem must work together to mitigate the risks of insecure devices and ensure future devices are more secure by developing and adopting robust security standards for IoT devices. Industry-led standards represent the most promising approach to broadly increase IoT security. Given the global and constantly evolving nature of threats, industry must utilize its expertise and reach to develop, adopt, and enforce fundamental IoT security measures.

The paper goes on to outline the "technical goals of an industry-led, standards-based approach as well as the governance goals of the development organization." It says:

To achieve the needed level of security, an IoT security standard must address: (i) device identity; (ii) authentication, authorization, and accountability (onboarding); (iii) confidentiality; (iv) integrity; (v) availability; (vi) lifecycle management; and (vii) future (upgradable) security.

You can see from that list that the first four of those are all identity topics. And, not surprisingly, the paper spends a good deal of time talking about identity. I'd love to see the authors and readers of the paper at Internet Identity Workshop in October to discuss these topics. You'll find a lot of identity experts anxious to engage in solving these problems. Consider this an open invitation.

In the section on device identity, the paper says:

To support strong security, the device identifier must be immutable, attestable, and unique. Today, IoT devices typically do not use identifiers that are both unique and immutable and the device identifiers are almost never attestable. Attestability enables the device identity to be cryptographically verified, dramatically reducing the risk that the device is being impersonated (or “spoofed”).

The answer, from the paper, is to use PKI and certificates to solve the problem. True enough, but the devil is in the details. The problem is that the current best practices for certificate management leads to an architecture for the Internet of Things that is unduly hierarchical. Certificate manage implies a hierarchy of certificate authorities where each authority verifies those lower in the hierarchy until you get to the root certificates that are embedded in the devices.

I think we can do better than hierarchical certificate management for the Internet of Things. Indeed, I think we have to. A hierarchical model puts large collections of devices at the mercy of the the validity of root certificates.

The alternative is a decentralized web of trust. Sovrin provides a way to use cryptography to establish trust without a hierarchical public key infrastructure. The result is a decentralized system that is more available because it has fewer central points of control that might become single points of failure. I wrote in Sovrin Web of Trust:

PKI is good for one thing on the Web: showing the public key used to secure HTTP transmissions is correct. In contrast, Sovrin’s decentralized web of trust model is good for anything people need. The goal of Sovrin is to provide the infrastructure upon which these overlapping webs of trust can be built for various applications. Lyft, Airbnb, and countless other sharing economy businesses are essentially specialized trust frameworks. Sovrin provides the means of creating similar trust frameworks without the need to build the trust infrastructure over and over.

Imagine each device with a Sovrin decentralized identifier (DID) that links to its public keys on the Sovrin ledger. The DID provides a unique identifier for the device. And since it links to the public keys, anything can figure out how to communicate with the device securely. Sovrin's revocation features ensure that the keys can be updated as needed. Sovrin Trustworthy Claims serve as globally verifiable attestations about the device and these can be made flexibly by any party. All on a globally available, decentralized identity infrastructure that anyone can use.

If we're going to avoid the CompuServe of Things and build a true Internet of Things, we need to base it on a decentralized identity infrastructure. Sovrin is provides that. Let's talk.

Photo Credit: hairy from Windell Oskay (CC BY 2.0)

A Mesh for Picos

Picos are Internet-first actors that are well suited for use in building decentralized soutions on the Internet of Things. Here are a few resources for exploring the idea of picos and our ideas about they enable a decentralized IoT if you’re unfamiliar with the idea:

  • Picos: Persistent Compute Objects—This brief introduction to picos and the components that make up the pico ecosystem is designed to make clear the high-level concepts necessary for understanding picos and how they are programmed. Over the last year, we've been replacing KRE, the engine picos run on, with a new, Node-based engine that is smaller and more flexible.
  • Reactive Programming with Picos—This is an introduction to picos as a method for doing reactive programming. The article contains many links to other, more detailed articles about specific topics. You can thus consider this an index to a detailed look at how picos work and how they can be programmed.
  • Promises and Communities of Things—Promise theory provides a tool for thinking about and structuring the code that implements communities in groups of social things. This blog post discusses some initial thinking about promises and picos.
  • Social Things, Trustworthy Spaces, and the Internet of Things—Social things interacting in trustworthy spaces represent a model for an Internet of Things that is scalable to trillions of devices and still works. This post describes that concept and proposes picos as a platform for building social things.
  • Market intelligence that flows both ways—Doc Searls talks about how pico-based shadows of products are useful in creating new customer service interaction patterns. The pico-based system he references, SquareTag, is no longer in active development, but we're replacing it with a new system called Manifold that reflects the community of things ideas I reference above.

The New Pico Engine

Picos run on an engine that provides the support they need for Internet services, persistent storage, and identity. Over the past year, we've been rebuilding the pico engine. The Classic Pico Engine was a big cloud service. The New Pico Engine is a small, nibble Node program.

We recently built several demos with the pico engine to show this. Both used the pico engine running on a Raspberry Pi in IoT scenarios. The first was a demo of a computer closet (here's a wrietup of an early version of that demo) that uses temperature sensors and several fans to show how picos can cooperate to achieve some goal (in this case keeping the closet sufficiently cool). The second was an overengineered Jack-in-the-Box that had a pico engine running internally to play music and spring the door.

A Mesh for Picos

Picos operate in a mesh, regardless of where they're hosted. Picos don't have to be running on the same pico engine in order to form relationships with each other and interoperate.

We've begun a program to more fully support this ideal by making the engine itself part of a larger mesh of engines, each capable of hosting any of the picos in that ecosystem. The vision is that someone using a pico doesn't need to know what engine it's hosted on and that picos can move easily from engine to engine, moving computation close to where it's needed.

There are two problems to solve in order to make this a reality:

  1. Picos are addressed by URL, so the pico engine's host name becomes part of the pico's address
  2. Picos have a persistence layer that is currently provided by the engine the picos is hosted on.

We propose to solve the first problem using the Sovrin identity platform. I wrote about that idea in some detail in Sovrin Use Cases: Portable Picos. The synopsis is that Sovrin allows us to find picos by name rather than location using the distributed ledger as a storage location for names based on decentralized identifiers (DIDs) that point to the current location of the pico.

We propose to solve the second problem by incorporating the Interplanetary File System (IPFS) into the engine as the persistence layer for picos. By using IPFS, the pico's persistent state would be available to it regardless of where it is being run.

With this two changes in place, we can create a mesh of pico engines. Individual pico engines can come or go as necessary without impacting the ability of the picos themselves to operate normally. The Classic Pico Engine was a child of the early 2000's and used all the tools and techniques we'd learned to create availbility and reliability including load balancing, primary and secondary databases, server farms, monitoring, and automated service configuration.

The new pico engine will be something much more decentralized, lightweight, and adaptable. Pico engines can join a pool to support additional computational needs without complicated configuration or management. I envision a world where IoT device shadows in the form of picos run on a global, secure mesh of pico engines. These meshes could be public or private and supply generalized computer resources on demand.

Photo Credit: Blurred Bokeh Fence Lights from Pexels (CC0 Public Domain)

Sovrin Status: Provisional Trust Framework

Last week, the Sovrin Foundation Board of Trustees voted unanimously to approve the Sovrin Provisional Trust Framework (PTF). Trust is the primary benefit of Sovrin. I've written before about Sovrin as a universal trust framework and Sovrin's web of trust model. The Provisional Trust Framework is a set of legal documents that provide the foundation for Sovrin's trust model.

Sovrin is a permissioned ledger, meaning it achieves consensus using a known set of validators—in this case, trusted institutions around the world. This is in contrast to permissionless ledgers like Bitcoin's blockchain that rely on validators who are not identified. The permissioned model has advantages in both speed and cost of transactions. But it means that Sovrin needs governance. The PTF is the set of documents that spells out how various participants in the network must behave and the agreements that Sovrin Stewards make in order to operate a validator node. Each Steward will sign the Sovrin Founding Steward Agreement before they operate a validator node on the Sovrin network.

Sovrin is also a public ledger, meaning anyone can use it. This is in contrast to other permissioned ledgers that are operated as private systems for their owner's specific purposes. Sovrin is designed to operate as a global public utility for identity. Sovrin can be used by anyone. The PTF supports this goal, enumerating the participants in the network and their obligations and qualifications. The PTF also spells out how Sovrin's Web of Trust model works.

The PTF outlines:

  • the principles that govern the Sovrin network and by extension the Sovrin Foundation and Stewards;
  • key definitions and terminology;
  • the obligations of the Sovrin Foundation;
  • business policies for identity owners, stewards, trust anchors, and guardians;
  • legal policies for identity owners, stewards, agencies, and developers;
  • legal policies for dispute resolution;
  • legal policies for confidentiality;
  • technical policies for node operation, monitoring and reporting, write permissions, transaction limitations, and service levels; and
  • policies for amending the PTF.

The PTF governs the operation of the Sovrin network while in "provisional" status, meaning during its first months of official operation when it is still being “battle-tested” in live operation by the Founding Stewards. The PTF has a number of additional sections that must be completed, approved, and agreed to before the Sovrin network is declared ready for general availablity. At that point these documents will graduate and be called the Sovrin Trust Framework.

The completion of the PTF is an important step for the network. The Trust Framework Working Group and it's chair, Drummond Reed, have spent long hours hammering out this vital set of documents. With the PTF's completion and approval, Sovrin takes one more important step to being a reality.

Sovrin Status: Alpha Network Is Live


Sovrin is based on a permissioned distributed ledger. Permissioned means that there are known validators that achieve consensus on the distributed ledger. The validators are configured so as to achieve Byzantine fault tolerance but because they are known, the network doesn't have to deal with Sybil attacks. This has several implications:

  1. The nodes are individually unable to commit transactions, but collectively they work together to create a single record of truth. Individual nodes are run by organizations called "Sovrin Stewards."
  2. Someone or something has to chose and govern the Stewards. In the case of Sovrin, that is the Sovrin Foundation. The nodes are governed according to the Sovrin Trust Framework.

The Sovrin Network has launched in alpha. The purpose of the Alpha Network is to allow Founding Stewards to do everything necessary to install and test their validator nodes before we collectively launch the Provisional Network. It’s our chance to do a dry-run to work out any kinks that we may find before the initial launch.

Here’s what we want to accomplish as part of this test run:

  • Verify technical readiness of the validator nodes
  • Verify security protocols and procedures for the network
  • Test emergency response protocols and procedures
  • Test the distributed, coordinated upgrade of the network
  • Get some experience running the network as a community
  • Work out any kinks and bugs we may find.

With these steps complete, Sovrin will become a technical reality. It’s an exciting step. We currently have nine stewards running validators nodes and expect more to come online over the next few weeks. Because the Alpha Network is for conducting tests, we anticipate that the genesis blocks on the ledger will be reset once the testing is complete.

Once the Alpha Network has achieved it's goals, it will transition to the Provisional Network. The Sovrin Technical Governance Board (TGB) chose to operate the network in a provisional stage as a beta period where all transactions were real and permanent, but still operating under a limited load. This will enable the development team and Founding Stewards to do performance, load, and security testing against a live network before the Board of Trustees declares it generally availabile.

After many months of planning and working for the network to go live, we're finally on our way. Congratulations and gratitude to the team at Evernym doing the heavy lifting, the Founding Stewards who are leading the way, and the many volunteers who sacrifice their time to build a new reality for online identity.

Photo Credit: Sunrise from dannymoore1973 (CC0 Public Domain)

Correlation Identifiers

Let's talk for a bit about correlation identifiers. Correlation IDs are used to identify the different parts of a computation when they happen concurrently. Picos are single threaded, so you never have to worry about this in a single evaluation cycle (response to one event) in a given pico. But as soon as there is more than one actor involved in a computation, you run the risk that things might not happen in order and parts of your computation will come back differently than you expect.

For example, in Fuse, creating fleet report was initiated by an event to the fleet pico. This, in turn, caused the fleet pico to send events to the vehicle picos asking them to do part of the computation. The vehicle picos responded asynchronously and the fleet pico combines the results to create the completed report. Suppose the initiating event is received twice in quick succession, the vehicle picos will get multiple requests. It's possible (due to network delays, for example) that the responses will come back out of order. This picture shows the situation:

Asynchronous responses can lead to out or order reports
Asynchronous responses can lead to out or order reports (click to enlarge)

The response pattern on the left is what we want, but the one of the right is one of many possible combinations that could occur in practice. The colors of the two events and the events they spawn (red or blue) are a pictoral correlation identifier. We can easily save the various responses and then combine them into the right report later if we know all the red responses go together and all the blue responses go together.

To make correlation IDs work in KRL, you wouldn't use colors, of course, but rather a random string for each initiating event. So long as all the participants pass this ID along as an event attribute in the various computations that occur, the fleet pico will be able to use the right pieces to create each report.

Updated Pico Programming Workflow

Pico Tool chain and programming workflow

I just got done updating the page in the Pico documentation that talks about the pico programming workflow. I use the idea of a toolchain as an organizing principle. I think it turned out well. If you program picos, it might be of some help.

Sovrin Web of Trust

The Web of Trust model for Sovrin is still being developed, but differs markedly from the trust model used by the Web.

The Web (specifically TLS/SSL) depends on a hierarchical certificate authority model called the Public Key Infrastructure (PKI) to determine which certificates can be trusted. When your browser determines that the domain name of the site you're on is associated with the public key being used to encrypt HTTP transmissions (and maybe that they’re controlled by a specific organization), it uses a certificate it downloads from the Website itself. How then can this certificate be trusted? Because it was cryptographically signed by some other organization who issued the public key and presumably checked the credentials of the company buying the certificate for the domain.

But that raises the question "how can we trust the organization that issued the certificate?" By checking its certificate, and so on up the chain until we get to the root (this process is called “chain path validation”). The root certificates are distributed with browsers and we trust the browser manufacturers to only include trustworthy root certificates. These root certificates are called “trust anchors” because their trustworthiness is assumed, rather than derived.

Webs of Trust

In contrast, a Web of Trust model uses webs of interlocking certificates, signed by multiple parties to establish the veracity of a certificate (see Web of Trust on Wikipedia for more detail). An entity can be part of many overlapping webs of trust because its certificate can be signed by many parties.

Sovrin uses a heterarchical, decentralized Web of Trust model, not the hierarchical PKI model, to establish the trustworthiness of certificates. The methodology for doing this is built into the Sovrin system, not layered on top of it, by combining a decentralized ledger, decentralized identifiers, and verifiable claims. While Sovrin Foundation will establish some trust anchors1 (usually the same Stewards who operate validator nodes on the Sovrin network), these are merely for bootstrapping the system and aren’t necessary for the trusting the system once it is up and running. Sovrin uses this trust system to protect itself from DDoS attacks, among other things.

By allowing an identifier to be part of multiple webs of trust, Sovrin allows for reputational context to be taken into account. For example, being a good plumber doesn’t guarantee that a person will be a good babysitter, but a person who was a good plumber and a trustworthy babysitter could be part of different webs of trust that take these two contexts into account. The makes the overall trust model much more flexible and adaptable to the circumstances within which it will be used. PKI is good for one thing on the Web: showing the public key used to secure HTTP transmissions is correct. In contrast, Sovrin’s decentralized web of trust model is good for anything people need.

The goal of Sovrin is to provide the infrastructure upon which these overlapping webs of trust can be built for various applications. Lyft, Airbnb, and countless other sharing economy businesses are essentially specialized trust frameworks. Sovrin provides the means of creating similar trust frameworks without the need to build the trust infrastructure over and over.

Building Trust

Trust anchors are not the only way one could build trust in an identifier for a given purpose. I can think of the following ways that an identifier could come to be trusted:

  1. Personal knowledge — The identifier is personally known to you through interactions outside Sovrin. People close to me would be in this category. This category also includes identifiers like those for my employer or other entities who I interact with in the physical world and can thus establish a trust connection through means outside of Sovrin. If I know and trust the Web site of an entity, a well-known discovery scheme could let me know what identifiers they claim and consequently I’d gain trust in those identifiers. Such a system could piggyback on the PKI used for Web certificates.
  2. Verifiable claims — The identifier is verified by reliance on other trustworthy claims. This is analogous to how banks use KYC to establish trust in a person opening an account. They check other documents that they can trust (like a driver license or passport). They trust those documents by relying on trust established via the method described in (1).
  3. Web of trust — The identifier is introduced to me by someone I trust or who can be transitively associated with someone I trust. This category most closely follows the PGP Web of trust model described in the wikipedia article I reference above. Various entities have signed the certificate associated with the identifier and I can trace those signatures back to other entities I trust.

Trust anchors, as the term is used in the Sovrin documents, have been designated by Sovrin or other trust anchors as a trustworthy source. But they are not the only source of trust.

In conclusion, trust on Sovrin works much the same way as it does in the physical world. This has advantages and disadvantages. The chief advantage, as I’ve pointed out, is that Sovrin is flexible and adaptible to various circumstances.

The chief disadvantage is that it relies on people being responsible for determining whether or not to trust something. There are lots of clues that people can use. How well it ultimately works depends on the user experience and whether people understand what’s being asked of them. But there will be cases where people mistakenly trust things they shouldn’t. Of course that happens today, online and off, as well. I’m hopeful that a richer set of trust clues will lead to less fraud than we currently see. Whether that’s true or not depends on design decisions yet to be made. Fortunately those can be made with 15 years of experience from identity on the Web to guide us.


  1. Because the term “trust anchor" is heavily associated with PKI, it might make sense to use another one to avoid confusion.

Photo Credit: Spiderweb with Frost from Yintan (CC BY 4.0)

Sovrin In-Depth Technical Review

The Sovrin Foundation and Engage Identity announced a new partnership today. Security experts from Engage Identity will be completing an in-depth technical review of the Sovrin Foundation’s entire security architecture.

Sovrin Foundation is very concerned that the advanced technology utilized by everyone depending on Sovrin is secure. That technology protects many valuable assets including private personal information and essential business data. As a result, we wanted to be fully aware of the risks and vulnerabilities in Sovrin. In addition, The Sovrin Foundation will benefit from having a roadmap for future security investment opportunities.

We're very happy to be working with Engage Identity, a leader in the security and identity industry. Established and emerging cryptographic identity protocols are one of their many areas of expertise. They have extensive experience providing security analysis and recommendations for identity frameworks.

The Engage Identity team is lead by Sarah Squire, who has worked on user-centric open standards for many organizations including NIST, Yubico, and the OpenID Foundation. Sarah will be joined by Adam Migus and Alan Viars, both experienced authorities in the fields of identity and security.

The final report will be released this summer, and will include a review of the current security architecture, as well as opportunities for future investment. We intende to make the results public. Anticipated subjects of in-depth research are:

  • Resilience to denial of service attacks
  • Key management
  • Potential impacts of a Sovrin-governed namespace
  • Minimum technical requirements for framework participants
  • Ongoing risk management processes

Sovrin Foundation is excited to take this important step forward with Engage Identity to ensure that the future of self-sovereign identity management can thrive and grow.