Subscribe: Phil Windley's Technometria
Added By: Feedage Forager Feedage Grade B rated
Language: English
code  data  decentralized  digital  foundation  identifiers  identity  mdash  network  sovrin foundation  sovrin  system  systems 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Phil Windley's Technometria

Phil Windley's Technometria

Building the Internet of My Things

Last Build Date: Mon, 12 Mar 2018 14:53:50 -0600

Copyright: Copyright 2018

What We Learn about Self-Sovereignty from CryptoKitties

Mon, 12 Mar 2018 14:53:45 -0600

Summary: CryptoKitties are a useful example of digital ownership and self-sovereignty except for one small flaw. Late last year CryptoKitties burst into the blockchain world. If you haven't been paying attention, CryptoKitties is a Web site that uses a browser-based wallet (MetaMask) to sell (for Ether) little virtual kitties. Once you have a kittie, you can breed it with others, to create new kitties. Each one is a unique individual created with some genetic algorithm. Some Gen 0 or Gen 1 kitties have sold for ridiculous amounts of money. If you were around in the 90's when the Web was taking off, think Beanie Babies meets Blockchain and you'll get the idea1. Except it's a little more interesting than Beanie Babies ever were because each CryptoKittie is really a non-fungible token on the Ethreum blockchain. This means each kittie has some interesting properties: Each kittie is disiguishable from all the rest and has a unique identity and existence Each kittie is owned by someone. Specifically, it is controlled by whoever has the private keys associated with the address that the kittie is tied to. Because of these properties, a CryptoKitty can be remixed and used in other applications. Just today, I heard that they are being sold on OpenBazaar for Bitcoin. Someone could create a game that uses the kitties that were part of the CryptoKitty game as characters in a new game. Because they are not just a line in some centralized company's database, they really do belong to the people who bought them and who can use them for anything they like. Why is this important? You can go on Amazon and "buy" a digital copy of a movie or song. But do you really own it? Do you have a unique copy that is controlled only by you? Not likely. In the wake of Louis C.K's sexual miscoduct allegations, many services cut their ties to the comedian. I'm not defending his actions in any way, but people who "bought" that content didn't own it, because someone else's decisions took the content away from them. That can't happen with a CryptoKittie (almost, keep reading). The token representing the kittie is mine and under my control. That's the idea of self-sovereignty. You control something without others being able to take the asset away from you. As I wrote in On Sovereignty: Sovereignty is about relationships and boundaries. When we say a nation is sovereign, we mean that it can act as a peer to other sovereign states, not that it can do whatever it wants. Sovereignty defines a boundary, within which the sovereign has complete control and outside of which the sovereign relates to others within established rules and norms. The border, in this case, is defined by Ethereum, the ERC-721 specification, the smart contract, and my private keys in my wallet. The only thing that can take my CryptoKitty away from me is Ethereum going away. They are a non-fungible asset like art and other collectible. They can be traded and they can be repurposed, but only with my consent. The Fly in the Ointment What I wrote above is almost true. The structure of individual ownership is all there2. There is one problem with CryptoKitties as a model of self-sovereignty: the CryptoKittie smart contract has a "pause" function that can be executed by certain addresses. This is probably a protection against bugs—no one wants to be the next theDAO—but it does provide someone besides the owner with a way to shut it all down. I have no idea who that someone is and can't hold them responsible for their behavior—I'd guess it's someone connected with CryptoKitties. Whoever has control of these special addresses could shutdown the entire enterprise. I do not believe, based on the contract structure, that they could take away individual kitties; it's an all or nothing proposition. Since they charged money for setting this up, there's likely some contract law that could be used for recourse. Nevertheless, we need more discussion of formalized governance in decentralized systems. How do we balance [...]

Sovrin Foundation Welcomes Nathan George

Tue, 27 Feb 2018 14:57:10 -0700

Summary: Hiring a full time CTO is a big step for the Sovrin Foundation. I'm excited Nathan is joining us.


The Sovrin Foundation is excited to announce that we have hired of Nathan George as our Chief Technology Officer. Nathan was previously Chief Architect at Evernym, Inc. He has been instrumental in maintaining the Hyperledger open-source Project Indy, which is sponsored by the Sovrin Foundation. Nathan comes with a wealth of experience that will help Sovrin thrive and reach its full potential.

I’m very excited to have Nathan join the foundation. The Sovrin Foundation is much more than an advocacy organization for self-sovereign identity. As I wrote in Decentralized Governance in the Sovrin Foundation, the foundation exists to administer the Sovrin Trust Framework and a significant aspect of that entails designing and implementing protocols, managing Project Indy, and supporting the Sovrin Stewards in their operation of the network nodes. These tasks are technical and having a full-time technology executive focused on this is critical to the success of the network, and the foundation itself.

The Sovrin Foundation technology goals, on which Nathan will have primary focus, include:

  • Planning and following a roadmap that outlines Sovrin development
  • Implementing a Sovrin RFC and Improvement Project process
  • Supporting steward onboarding and operation
  • Managing the release process that prepares code for Stewards
  • Monitoring network operation and reliability
  • Impacting design of the various components of the Sovrin ecosystem
  • Supporting feature development through bounties and other developer incentive programs
  • Participating in standards processes that impact Sovrin

Hiring a CTO represents a big step along the path to self sustainability for the Sovrin network. A huge part of being self sustaining is technical independence. Having a CTO in the Sovrin Foundation will allow us to drive many technical developments and coordinate our open source projects from within the foundation.

Photo Credit: Circuits from Max Pixel (CC0)


Decentralized Governance in Sovrin

Sun, 04 Feb 2018 15:20:44 -0700

Summary: Decentralized systems require governance to function well. Ideally this governance should be clear, open, and effective without impacting the decentralized nature of the system. This post describes the governance of the Sovrin network. Our approach is a constitutional model based on an agreement we call the Sovrin Trust Framework that informs and guides everything from code development to the responsibilities of the various actors in the system. The Sovrin Trust Framework enables decentralized governance of the Sovrin network. Marc Hulty defines governance as "the processes of interaction and decision-making among the actors involved in a collective problem that lead to the creation, reinforcement, or reproduction of social norms and institutions." From this we can conclude that everything gets governed, the question is whether governance is ad hoc or formal, explicit or implicit. One of the ironies of decentralized systems is that they require better governance than most centralized systems. Centralized systems are often governed in an ad hoc way because the central point of control can easily tell all participants what to do. Decentralized systems, on the other hand, must coordinate across multiple parties, all acting independently in their own self-interest. This means that the rules of engagement and interaction must be spelled out and agreed to ahead of time, with incentives, disincentives, consequences, processes, and procedures made clear. The Internet is an excellent example of this. All the computers that connect to the Internet, along with those that route messages between nodes, follow a set of procedures determined ahead of time that cannot be ignored by participants without loss of functionality. These procedures are called protocols and they are embodied in the code that participants in the network—both edge nodes and routers—execute. Blockchain systems are no different. Their interactions are wholly or partially governed by protocols embodied in code. But these protocols are not emergent properties of the blockchain, rather they are designed by humans who write the code and agreed to by the humans who execute it. Without the design and agreement of humans, the blockchain does not function. The Sovrin blockchain is a good example. There are two primary components of how Sovrin operates: the design of the protocols and the operation of the ledger. We can ask governance questions about each. Sovrin's code is open source—specifically it is the Hyperledger Indy project under the umbrella of the Linux Foundation. This means developers from around the world collaborate to design and build the code that makes Sovrin work. Their decisions are governed in the way of most open source projects: rough consensus and running code with pull requests accepted by a core set of developers who manage the code base. Code embodies the rules that make up the Sovrin protocol. Since the protocol is a critical component of Sovrin governance, how decisions are made about the code is a key component of ensuring Sovrin is governed well. But with the Sovrin blockchain there is another kind of governance that is not embodied in the code. Sovrin is built on a public permissioned blockchain. This means that anyone can use the Sovrin ledger, but consensus is achieved by a known set of validator nodes. Validators perform a similar function on a permissioned ledger than miners perform on a permissionless ledger—ensuring that each copy of the ledger records the same data in the same order1. Since Sovrin’s validators are part of a known group, we should also examine how this group of validators is selected, organized, and governed. Decisions about how code is architected, which code is run by validator nodes, and how those nodes operate are made in accordance with the Sovrin Trust Framework, a document that specifies how the Sovrin Network is governed. The Trust Framework is Sovrin’s constitutio[...]

Announcing the Sovrin Whitepaper

Tue, 16 Jan 2018 15:14:04 -0700

Summary: The Sovrin whitepaper is now available. Identity in real life is much richer than online identity, flexibly and conveniently solving all kinds of thorny problems. Now with Sovrin, we can bring those rich identity transactions online. This paper shows how that happens and why it will impact every sector of the Internet in significant ways. I hope you'll spend some time reading it. I'm very pleased to announce that the Sovrin whitepaper is now available. The whitepaper pulls together in one place detailed information about why Sovrin exists, what Sovrin is, and how it will impact nearly every aspect of your online life. Here's the abstract: Digital identity is one of the oldest and hardest problems on the Internet. There is still no way to use digital credentials to prove our online identity the same way we do in the offline world. This is finally changing. First, the World Wide Web Consortium is standardizing the format of digitally-signed credentials. Secondly, public blockchains can provide decentralized registration and discovery of the public keys needed to verify digital signatures. These two steps pave the way to establish a global public utility for self-sovereign identity—lifetime portable digital identity that does not depend on any central authority and can never be taken away. The Sovrin Network has been designed exclusively for this purpose, including governance (the Sovrin Foundation and the Sovrin Trust Framework), scalability (validator and observer nodes and state proofs), and accessibility (minimal cost and maximum availability). Most importantly, Sovrin implements Privacy by Design on a global scale, including pairwise pseudonymous identifiers, peer-to-peer private agents, and selective disclosure of personal data using zero-knowledge proof cryptography. The emergence of this infrastructure can transform at least four major markets: identity and access management, cybersecurity, RegTech, and data integration. To provide economic incentives for credential issuers, owners, and verifiers, the Sovrin protocol will incorporate a digital token designed expressly for privacy-preserving value exchange. The Sovrin token should enable a global marketplace for digital credentials of all types and value levels together with ancillary markets for digital credential insurance and permissioned first party data (direct from the customer). As you can see, Sovrin will incorporate a native token for exchanging value in identity transactions. We're confident that a protocol token for Sovrin will enable use cases that would be unrealizable without it and drive the network effects for Sovrin adoption. The whitepaper has been a long time coming. We wanted to get it right and make it as clear and understandable as possible. I'm grateful for my co-managing editor Drummond Reed, a member of the Sovrin Board of Trustees and chair of the Trust Framework working group for his diligent efforts in making this a reality. Countless others participated in discussions, made comments, or proofread various versions of the document. And a special thanks to Monique Heileson for her fine work on graphic design, layout, and illustration. Internet identity has become synonymous with authentication and that's too bad. Identity in real life is much richer, flexibly and conveniently solving all kinds of thorny problems. Now with Sovrin, we can bring those rich identity transactions online. This paper shows how that happens and why it will impact every sector of the Internet in significant ways. I hope you'll spend some time reading it. Tags: sovrin identity whitepaper verifiable+claims sovrin+token [...]

Secure Pico Channels with DIDs

Wed, 03 Jan 2018 15:20:05 -0700

Summary: Decentralized identifiers are a perfect complement to the event channels in picos and provide the means of performing secure messaging between picos with little effort on the developer's part. Picos are Internet-first actors that are well suited for use in building decentralized soutions on the Internet of Things. See this description of picos for more details. Picos send an receive messages over channels. Each channel has a non-correlatable identifier, called an ECI. Because picos can have as many channels as they like, you can use them to prevent correlation of the pico's identity without the pico's participation. When two picos exchange ECIs to create a relationship, we call that a subscription. Wrangler, the pico operating system, supports creating and using subscriptions. Subscriptions allow picos to use peer-to-peer, graph-based interaction patterns. From a given pico's perspective, it has an inbound channel to receive messages (the Rx channel) and an outbound channel to transmit messages (the Tx channel). Decentralized identifiers (DIDs) are a "new type of identifier intended for verifiable digital identity." DIDs are used with blockchain-based resolution to create decentralized systems. The DIDs for Hyperledger's Indy Project (and consequently the Sovrin network) are derived from, and are thus uniquely associated with, a public-private key pair. Sean George completed a project this past Fall semester that made modifications to the channel identifier code in the Pico engine to use DIDs as the channel identifier. Because a DID is derived from an associated private key, that means that each channel also has a public-private key pair. Sean's work uses the channel keys to support signing and encrypting channel messages (using Diffie-Helman key exchange). When a subscription is created between two picos, each pico stores the DID and public key of the incoming Rx channel. Having the public key for the other pico in the subscription allows each pico to securely message the other. There is no way to access the private keys from within KRL to protect them from unauthorized access. This document on the Pico Labs documentation wiki includes sample KRL rules to shows how to use the built-in engine functions to sign, verify, encrypt, and decrypt messages. Future work will focus on making the use of these functions easier and more automatic. We will also be working on integrating the Sovrin network with the pico engine. Once the DIDs are registered on the Sovrin ledger, the ledger will be used to verify the public key and outside systems will be able to make use of these capabilities without storing the public key, so long as they know the DID. Tags: picos dids identity cryptograph sovrin [...]

Fixing the Five Problems of Internet Identity

Wed, 03 Jan 2018 15:43:45 -0700

Summary: Sovrin capitalizes on decades of cryptographic research and the now widespread availability of decentralized ledger technology to rethink identity solutions so that we can have scalable, flexible, private interactions with consent despite the issues that distance introduces. Andy Tobin has a great presentation that describes five problems of Internet identity. Our claim is that self-sovereign identity, and Sovrin in particular, solve these five problems: The Proximity Problem—The proximity problem is as old as the familiar cartoon with the caption "On the Internet, nobody knows you're a dog." Because we're not interacting with people physically, our traditional means of knowing who we're dealing with are useless. In their place we've substituted username-password-based authentication schemes. The result is that people's identity information is replicated in multiple identity silos around the Internet. The Scale Problem—Digital identity currently relies on hubs of identity information. We login using Facebook or Google—huge "identity providers." But for every place that uses one of these big identity providers, there are dozens that will never be part of the social login system. Many businesses are leery of giving up control of their customer information to another business that might decide next week to change things up. I don't think it's any accident that this is the same concern that was holding back online services in the days of CompuServe. The Flexibility Problem—Many of the so-called "identity solutions" in play today are limited by fixed schema or attribute sets. For example, GOV.UK Verify is a univeral identity assurance system for UK citizens but has a limited data set. And it's unlikely that they could reasonably expand whatever schema they have to cover all use cases, even if they were inclined to do so. The Privacy Problem—Current digital identity solutions rely on collections of data, often collected without subject's knowledge. The data is replicated over and over again in different systems. Third parties use universal identifiers like Social Security Numbers or phone numbers to correlate identity information, again without the subject's knowledge. They are a 20th century tool that is unsuited to the digital age. The Consent Problem—And the data in these thousands of identity silos is often shared with others without consent. Sometimes this is done in service of the subject, but often it's done in service of the bottom line of the organization who controls the silo. The Sovrin Architecture Sovrin has a unique architecture that addresses these five identity problems. Sovrin is designed to discourage correlation, minimize disclosure, and promote security. Sovrin's architecture is decentralized so that these benefits are available to all. This is achieved through the careful combination of several important technologies: Decentralized Identifiers (DIDs)—DIDs are identifiers intended for self-sovereign, verifiable digital identities. Sovrin uses DIDs in a manner that is pairwise and psedonymous. That is, each relationship is given a new, opaque DID by default to prevent correlation. DIDs point to DID Documents that contain public keys and service endpoints and are thus the means of locating the place the identifier can be used and providing the keys to use it. Verifiable Claims—Verifiable claims are the digital equivalent of the various third-party credentials we all carry around in our wallets. These credentials have several important properties: The format and content of the credential is determined by the issuer, not some central authority. Anyone can issue whatever credentials they like. Anyone can choose to accept whatever credentials suit their purposes The credentials say who they're about (using a DID) The credentials say who issu[...]

The 10-Year Platform: Shutting Down KRE

Tue, 19 Sep 2017 13:03:09 -0600

Summary: The original pico engine, KRE, is no more. But the ideas and capabilities of the platform live on in the new pico engine.


A few years ago, I announced on this blog that Kynetx was done. But the platform we'd created, the Kynetx Rules Engine, or KRE, lived on. Today I am annoucing that KRE is dead too. We shut it down last week.

Despite the demise of Kynetx, the platform continued to be open and available. Fuse was still running on it and my students were using it for class and research. But Fuse stopped working for good last spring when the MVNO we were using to process cellular data from the car devices shut down. And the new pico engine is working so well that we use it for everything now.

KRE was started in 2007 and envisioned as a cloud-based programming platform for events. While we had several different uses for it over the years, the focus on cloud-based program evaluation never changed. KRE was a PaaS play and so we built it with the idea that it would be a big chunk of infrastructure that we maintained for use by our customers.

Back at iMall in the 90's, Steve Fulling, Wade Billings, Mark Horstmeier, Cid Dennis, and I developed a core competancy around running big server farms. And AWS was still a fairly new thing. So, we built KRE using Dell servers, Linux, virtual servers, Puppet, and other technology we were familiar with. When we built iMall, not many people could do this well and we got good at running large infrastructure. So when Kynetx started up, that was our natural path. If I were doing it today, or even just 5 years ago, I'd do it on AWS.

Over the past 10 years, KRE has operated day in and day out without fail. The only time it's been offline is when we had to physically move the servers from one data center to another. Turning off KRE and retrieving the servers is the final step in the long, exciting dance that was Kynetx. A few weeks ago I realized that the platform I'd poured my soul into for the last 10 years was no longer needed. But the ideas that it spawned live on in the pico engine. Shutting it down is bittersweet, but I'm excited for the future.


Is Sovrin Decentralized?

Thu, 21 Sep 2017 15:19:14 -0600

Summary: To determine whether Sovrin is decentralized, we have to ask questions about the purpose of decentralization and how Sovrin supports those purposes. People sometimes ask "Is Sovrin decentralized?" given that it relies on a permissioned ledger. Of course, the question is raised in an attempt to determine whether or not an identity system based on a permissioned ledger can make a legitimate claim that it's self-sovereign. But whether or not a specific system is decentralized is just shorthand for the real questions. To answer the legitimacy question, we have to examine the reasons for decentralization and whether or not the system in question adequately addresses those reasons. This excellent article from Vitalik Buterin discusses the meaning of decentralization. Vitalik gives a great breakdown of different types of decentralization, listing architectural decentralization, political decentralization, and logical decentralization. Of these, logically decentralized systems are the most rare. Bitcoin and other decentralized ledgers are, in fact, logically centralized. There's one ledger. But the architecture (no infrastructural central point of failure) and politics (no one controls them) of Bitcoin are decentralized. But of course, these aren't binary options. There's a spectrum. For example, while it's true that Bitcoin miners aren't centrally controlled in some aspects (e.g. who can use them, who can verify transactions), there are points of control such as the code itself. No one person has control but many have a lot more than others. I'm not saying this to throw shade on Bitcoin. Rather, I'm making the point that not even Bitcoin is completely governed by technology. There's some balance between the business, technical, and legal agreements that make up any functioning decentralized system. The more important question about decentralization is: does the level of decentralization serve the goals of the system. There are several good reasons for going to the effort of creating a decentralized system: Avoiding common mode failure—This is one of the most frequently stated reason for decentralization. An architecture built from many parts is less likely to fail if one of them fails. Of course, this assumes that the many components are put together combined in a way that makes this possible. And it also assumes that the failure isn't due to something they're all susceptible to (otherwise known as the monoculture problem). Resisting attacks—Attacking a decentralized system requires taking on many components in a coordinated manner. Lack of central control points makes attacking decentralized systems much more expensive. Avoiding collusion—Collusion is, as Vitalik puts it "coordination that we don’t like." When participants in the system conspire to cheat or gain an unfair advantage, we call it collusion. So, rather than asking "Is Sovrin decentralized?", we might ask how the Sovrin network avoids common mode failure, resists attacks, and makes collusion difficult. Is Sovrin Resilient to Common Mode Failures? There are many kinds of common mode failures, but there are techniques we can use to avoid them. Sovrin is built on a distributed ledger that is readable and writable by nodes on the network. These nodes are operated by organizations of different types, industry affiliations, and size. They are spread out around the globe. Nodes are operated on different hardware, in different kinds of data centers, with different operating systems. There are no secret nodes. Everyone running a node is known. The code is open source. There are several shortcomings currently: First, there is only one implementation. Second, most of the development is being done by one company. Both of these will be remedied over time as Sovr[...]

Equifax and Correlatable Identifiers

Fri, 15 Dec 2017 07:49:03 -0700

Summary: We can avoid security breachs that result in the loss of huge amounts of private data by creating systems that don't rely on correlatable identifiers. Sovrin is built to use non-correlatable identifiers by default while still providing all the necessary functionality we expect from an identity system. Yesterday word broke that Equifax had suffered a data breach that resulted in 143 million identities being stolen. This is a huge deal, but not really too shocking given the rash of data breaches that have filled the news in recent years. The typical response when we hear about these security problems is "why was their security so bad?" While I don't know any specifics about Equifax's security, it's likely that their security was pretty good. But the breach still occurred. Why? Because of Sutton's Law. When Willie Sutton was asked why he robbed banks, he reputedly said "cause that's where the money is." So long as we insist on creating huge honeypots of valuable data, hackers will continue to target them. And since no security is perfect, they will eventually succeed. Computer security is difficult because computer systems are non-linear—small errors can result in huge losses. This makes failure points difficult to detect. These failure points are not usually obvious. But hackers have a lot of motivation to find them when the prize is so large. How do we avoid honeypots of data? By decentralizing it. Decentralized identity breaks the data up so that no single hack returns enough data to be profitable1. No one would break into Equifax to steal the data from a single random individual. It's only in aggregate that the data has sufficient value to justify the effort. But we can make even individual records worth less by getting rid of universal identifiers. Things like credit card numbers, social security numbers, and phone numbers are all examples of universal identifiers. Universal identifiers allow a single person's activity to be tracked across multiple domains. If Equifax's database has consisted of a bunch of identifiers that only meant something to Equifax, there would be no reason to steal them. They're valuable because of the correlation. The great news is that building identity systems that use pairwise, pseudonymous, non-correlatable identifiers is doable now. The Decentralized Identifier (DID) specification describes an interoperable system of identifiers. Imagine when you need to give a merchant the ability to contact you or charge your account, you gave them a DID created just for them instead of of a credit card number2 or phone number. They could still use this DID to contact you or to charge you a monthly subscription, but it would be unique to them. If there was a breach and your DIDs were lost, you simple cancel them without affecting any other relationship. Non-correlatable identifiers are not worth the trouble to steal. The technical details of how this might work are beyond the scope of this post, but with today's computer technology we don't have to rely on correlatable identifiers. They are a 20th century tool that is unsuited to the digital age. It's time we stopped using them and started using technology that is designed to protect privacy without sacrificing functionality. If you're interested in exploring the details, I invite you to look at Sovrin, a decentralized, public, global identity system built to support non-correlatable identifiers by default. Notes: This is the general case. If you have a private key that protects million of dollars worth of bitcoin, that single private key would in itself be worthy of extraordinary efforts to retrieve. Note that systems like Apple Pay and Android Pay already use one-time identifiers in place of a credit card number for added security. Non-correlating [...]

Sovrin Self-Sustainability

Wed, 10 Jan 2018 08:35:46 -0700

Summary: For Sovrin to become a global, public utility that helps everyone create and manage self-sovereign identities, it must be independent and self-sustaining. This post outlines four idependence milestones for Sovrin Foundation. The Sovrin Foundation began life about a year ago. We launched the Sovrin Network just last month. For Sovrin to achieve its goal of providing self-sovereign identity for all, the Foundation and the Network have to be independent and self-sustaining. The idea for Sovrin-style identity and the technology behind it was developed by Evernym. To their credit, Evernym’s founders, Jason Law and Timothy Ruff, recognized that for their dream of a global identity system to become reality, they’d have to make Sovrin independent of Evernym. At present, Evernym continues to make huge contributions to Sovrin in time, code, money, and people. Our goal is to reduce these contributions, at least as a percentage of the total, over time. Achieving complete independence and becoming self-sustaining can be measured with four milestones. We have achieved the first and are working on the second which would lead to the resources necessary to achieve the third and fourth. Legal independence—Sovrin Foundation is legally separate from Evernym. Furthermore, I and the majority of people involved with the foundation governance have no relationship to Evernym. No one on the board represents an organization. They are on the board as people and recruited because of their support for self-sovereign identity. My belief is that the Board of Trustees should represent the people with identities on the network, not specific organizations. Financial independence—This is harder to achieve. I don’t believe that Sovrin can provide self-sovereign identity for people as an “industry association” where big companies come together to determine how Sovrin works. So, I’ve resisted fund-raising that would require that Sovrin trade influence for dollars. We are working on some alternative methods and hope to make some announcements about this soon. Technical independence—This will follow from financial independence as we hire people to take over some of the management roles in the foundation that are now staffed by Evernym and other volunteers. We will also begin to drive many technical developments and coordinate our open source projects from within the foundation. Ecosystem independence—This will be achieved when there are multiple competitors to Evernym on the Sovrin platform. As the network becomes more capable, we will begin to recruit more companies to use Sovrin. Evernym will be just one of many companies that use Sovrin. Our goal is to build a platform that is universal and owned by nobody. Further we don’t want the platform to be dominated by any one company. Our vision is for Sovrin to become an Internet for identity with all that that term implies. Beyond these four milestones, the ultimate goal for Sovrin Foundation and the network is self-sustainability. Sovrin must be in a position where it is self-sustaining so that it can remain free from outside influences that might rob it of its independence. We are fortunate to have a network model that can return value to the foundation for its role in developing the code and governing the stewards who operate nodes on the network. This model will support a vibrant, growing ecosystem of applications with positive network effects. Watch for upcoming announcements about Sovrin and self-sustainability in the near future. Thanks to Timothy Ruff for suggesting the four milestones of independence. Photo Credit: travel-fly-balloon-sky-sunset from Gellinger (CC0) Tags: sovrin identity self-sovereign sovrin+foundation evernym [...]