Subscribe: Phil Windley's Technometria
http://www.windley.com/rss.xml
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
decentralized  engine  identifiers  identity  internet  mdash  network  pico engine  picos  security  sovrin  system  trust 
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: Tue, 31 Oct 2017 14:53:24 -0600

Copyright: Copyright 2017
 



Fixing the Five Problems of Internet Identity

Tue, 31 Oct 2017 14:53:19 -0600

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 issued them (using a DID) The credentials are packaged in a way that makes them tamper-evident The claims can be verified by anyone[...]



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.

(image)

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.

Tags:




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 Sovrin becomes more self-sufficient. Is Sovrin Resistant to Attacks? Some attacks are mundane and can be handled using the same techni[...]



Equifax and Correlatable Identifiers

Fri, 08 Sep 2017 11:44:54 -0600

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 payment systems already exist—they're just not widely enough used yet. Photo Credit: Honey from unknown (CC0) Tags: secur[...]



Sovrin Self-Sustainability

Tue, 05 Sep 2017 16:09:16 -0600

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 milestopnes 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 [...]



The Case for Decentralized Identity

Thu, 17 Aug 2017 09:41:52 -0600

Summary: We cannot decentralize many interesting systems without also decentralizing the identity systems upon which they rely. We're finally in a position to create truly decentralized systems for digital 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 techn[...]



Launching the Sovrin Network

Thu, 03 Aug 2017 16:38:06 -0600

Summary: The Sovrin network for identity is now live and accepting transactions. Sovrin provides a global identity infrastructure that supports self-sovereign identity and verifiable claims. This blog post describes the launch ceremony that we conducted. This is the beginning of Identity for All. 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 p[...]



Identity, Sovrin, and the Internet of Things

Fri, 28 Jul 2017 12:33:55 -0600

Summary: Building the Internet of Things securely requires that we look to non-hierarchical models for managing trust. Sovrin provides a Web of Trust model for securing the Internet of Things that increases security and availability while giving device owners more control. 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 [...]



A Mesh for Picos

Thu, 03 Aug 2017 16:36:27 -0600

Summary: This post describes some changes we're making to the pico engine to better support a decentralized mesh for running 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: Picos are addressed by URL, so the pico engine's host name becomes part of the pico's address 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. [...]



Sovrin Status: Provisional Trust Framework

Sat, 08 Jul 2017 09:56:49 -0600

Summary: The Sovrin Trust Framework is nothing less that the constitution of the Sovrin Network. The Provisional Trust Framework was recently completed and approved. This post gives details about what the Sovrin Trust Framework is and why it's so important. 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. Tags: sovrin trust+framework trust web+of+trust [...]