Subscribe: Phil Windley's Technometria
http://www.windley.com/rss.xml
Added By: Feedage Forager Feedage Grade A rated
Language: English
Tags:
alice  bait shop  claims  foundation  identity  key  ledger  patient  sovereign identity  sovereign  sovrin  student  system 
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: Wed, 07 Dec 2016 20:19:10 -0700

Copyright: Copyright 2016
 



Sovrin Use Cases: Education

Wed, 07 Dec 2016 19:51:41 -0700

Summary: Sovrin's verifiable claims provide the means of creating a virtual university with little or no traditional integration between the various players. Lately, I’ve been thinking a lot about use cases for self-sovereign identity. This series of blog posts discusses how Sovrin can be used in different industries. In this article I discuss Sovrin and education. Last spring I wrote about how deconstructing the student information system at BYU is allowing us to create a virtual university. The idea is to create a decentralized system of student profiles that contain both profile data as well as learning records. These learning records can attest to any kind of learning activity from the student having read a few paragraphs to the completion of her degree. By making the student the point of integration, we avoid having to do heavy, expensive point-to-point integrations between all the student information systems participating in the educational initiative. This diagram shows a number of players in the virtual university (VU) system (labeled CES Initiative). They have no direct connections to each other, but present their own APIs, as does the student profile. As students interact with the various institutions, they present data in their profile (using an API). That's the only point of integration for these institutions, including VU itself. One of the design requirements for the student profile is that it be hostable where ever the student desires. We also put the student in control of authorizations to use data. These features mitigate regulatory requirements around privacy of student data. With millions of potential student spread among 188 different countries, this saves significant cost and headache trying to meet various regulatory hurdles. When the student is an active participant in sharing their data, the hurdles can be more easily overcome. The Role of Self-Sovereign Identity Self-sovereign identity can simplify many of the most difficult challenges of building the student profile. One of the key features of Sovrin is support for verifiable claims shared by their subject. Nearly everything in the student profile looks like a verifiable claim. Sovrin provides the infrastructure for issuing claims and using them in disclosures. Sovrin enables the receiver of the disclosure to verifying the claims in it. Verifiable claims also significantly ease the integration burden between the various systems involved in the virtual university. Say Alice wants to be a book keeper, but the book keeping microcourse has requirements for English language proficiency and secondary school completion, that she lacks. There could be four institutions involved in this scenario: Virtual University (VU), the English language certifier (ELC), the secondary education provider (SEP), and the college offering book keeping (BK). These last three institutions all have agreements with VU, but no technical integration with VU or each other. Alice has be admitted to VU and paid for the book keeping microcourse along with the require pre-requisites.1 She goes to ELC. Alice can prove she's a VU student and has paid for the English language certification by disclosing that information from the verifiable claims that VU wrote to her student profile. ELC can validate that the disclosure is true without talking VU directly. Alice registers for a course and, after she completes it, ELC writes a claim that she passed to her student profile. Alice, guided by the Student Profile, heads to SEP and discloses that she's a VU student. SEP validates her student status and that she's paid for the SEP program. They ask her to prove that she has the required level of english competancy and she provides a disclosure based on the claim that ELC wrote. She completes the secondary education program and SEP writes a claim stating such.2 The same thing happens for Alice's book keeping course at BK. One notable difference is that the microcourse that Alice signed up for might be made up of courses offered at different univerisit[...]



Notes from Defrag 2016

Thu, 17 Nov 2016 16:10:10 -0700

Summary: The following are my live tweets from Defrag at the Omni Interlocken in Denver, November 16-17, 2016. The following are my live tweets from Defrag at the Omni Interlocken in Denver, November 16-17, 2016. Eric Norlin: Defrag is 10 years old. Happy birthday. Announcing that this is the last time Defrag exists independently. Combining with Glue. #sad Tim Wagner: Going server less with AWS lambda Does serverless mean no servers? No, but there are no software servers (web server framework, etc.) Serverless goes beyond VMs and containers so that functions are the unit of abstraction Serverless enforces good design: small individual units of code, persistence separated from compute, one way to do things Triggers by events or calls from APIs. Easy to do real-time processing, event processing Bring your own code, Lambda is the web server, uses simple resource model, processes are stateless Economic proposition for lambda is "never pay for idle" Lambda economic model makes building a service simple by removing need to understand servers, availability zones, scaling Would you rather carry a giant beachball of 700 marbles without a bag. Both suck. Monoliths and microservices... Lambda provides the bag for the marbles.pen spec and tools to package and deploy entire serverless model #comingsoon Serverless means bring your own frameworks. No need to learn a new framework Lambda is a universal webhook receiver platform. Lambda reduces the need for understanding complex distributed computing concepts Future is a hybrid of containers and serverless to bridge these two worlds Prediction: we go from abstracting compute infrastructure to abstracting computational systems Lorinda Brandon: Marketing person at a tech conference gets "you have stickers, right?" Marketing smells funny: they always have to good news, they're perky. Makes you think they're hiding something Marketing thinks developers are mean and scary. developers are great conversationalists. Developer marketing has to take the bad with the good. Get feedback Tips for developer marketing: Start with GOOD; respond with truth; actively listen be flexible; get out of the way API == assume positive intent Duncan Johnston-Watt: Hyperledger is a project of the Linux foundation; lots of fancy sponsors A world of many chains. There will not be a chain of all chains. There will be many public chains and millions of private chains Blockchain allows everyone to agree on who owns what (for example) rather than having central registry for the asset Hyperledger fabric is permissioned blockchain network written in Go, chaincode in Go or Java Cloudsoft's interest in Hyperledger is deploying managing the consensus network and deploying applications on it. For example: Sotheby's want to run an auction. Cloudsoft could manage the deployment and management of Sotheby's auction code Mike Zaccardo: Now Mike Zaccardo is demoing the Sotheby's auction demo Hyperledger fabric has a notion of containers that allow multiple blockchain apps to run on the Hyperledger fabric demo shows transferring lots from one client to another, ensuring ownership Duncan Johnston-Watt Hyperledger is too big to be owned by a single entity. We should own it in common. See http://www.cloudsoft.io/gethlf for more info Tags: defrag notes conferences [...]



Sovrin Use Cases: Healthcare

Mon, 14 Nov 2016 14:11:09 -0700

Summary: Sovrin can improve healthcare and make it less costly by providing an identity system that combines a secure means of exchanging verifiable claims and patient consent that is a structural component of the system. Lately, I've been thinking a lot about use cases for self-sovereign identity. This is the second in a series of blog posts that discuss how Sovrin can be used in different industries. In this article I discuss Sovrin and healthcare. Healthcare is broken and many look to information technology to help solve the problem. But that's not working out as well as we'd like. The root of the problem, like many, is identity. Self-sovereign identity is the solution. Consent and Privacy One of the fundamental tenants of healthcare is patient consent. Patients have the right to determine their care and treatment. And they have a right to privacy in their healthcare. But consent and privacy are not the strong suits of today's Web architectures. Consequently, they're a poor match for building online patient services and it shows. Take two examples, the patient portal and the health information exchange. Patient Portals If you've been to the doctor lately, you've probably been directed to their "patient portal." What a nightmare. The security is too good, forcing you through their generally awful user experience just to perform tasks like reading short, low-value messages. As Bruce Fryer notes, these portals don't link to each other and they use name and date of birth to probabilistically correlate patients across systems. Health Information Exchanges A health information exchange (HIE) is another new piece of healthcare software that "allows doctors, nurses, pharmacists, other health care providers and patients to appropriately access and securely share a patient's vital medical information electronically—improving the speed, quality, safety and cost of patient care." These are supposed to help with interoperability between patient portals, but without clear identifiers for each patient, it's hit and miss. What's more, as Dr. Adrian Gropper points out, current HIEs store massive amounts of patient data with little accountability and don't properly allow patients to control access to data or grant consent for specific uses. Adrian has rethought how a HIE could work to put the patient in the consent flow and has a wonderful concept he calls HIE of One. He's got numerous demos to illustrate different flows. Adrian's HIE of One solves the problem of exchanging information between healthcare professionals while allowing for patient consent and control by putting the patient in the flow. This is a huge step forward and shows that decentralized solutions can better solve consent problems than centralized solutions. Self-sovereign identity systems plug right into the HIE of One to provide patient credentials, but that's just table stakes. Using a system like Sovrin, a patient-centric HIE would provide verifiable claims about patient data including test results, clinical findings, past treatment, and drug history. Insurance companies and other payers could also use claims to exchange critical information in a trustworthy, secure manner. Sovrin allows for disclosure and records consent. These claims would be anchored in the Sovrin ledger to ensure they can be validated. The Role of Self-Sovereign Identity The healthcare industry has reopened the universal patient identifier (UPI) debate as a potential solution to the problem of correlating patients across portals and exchanges, but there are several problems with this. First, an UPI would be subject to all the same kinds of problems that the social security number (SSN) has been. Once there's a single identifier anyone can correlate patient activity wherever it shows up. This puts privacy at the mercy of agreements rather than providing structural mechanisms to support privacy. Second, an UPI doesn't solve the integration problem because it's just an identifier, not an integration method. We sti[...]



Sovrin Use Cases: Authentication

Thu, 03 Nov 2016 18:13:25 -0600

Summary: This use case discusses authentication in a self-sovereign identity system called Sovrin. Sovrin simplifies authentication, reducing friction while providing a system that businesses can trust without building or maintaining it. Lately, I've been thinking a lot about use cases for self-sovereign identity. This is the first in a series of blog posts that discusses how Sovrin can be used for various purposes. We'll begin with authentication. Authentication has several facets. I’m going to discuss two of them below: enrollment and login. In this use case, a person named Alice will be enrolling and logging into a service provided by Bob’s Bait Shop. Enrollment How does Alice get a self-sovereign identity? If you read my How Sovrin Works article, you should be aware that there’s no such thing as “an identity” in Sovrin. Instead, Sovrin creates a unique identifier for each relationship that Alice has. Alice controls her identifiers and can correlate them, but no one else can without her permission. So, enrollment consists of Alice generating a key pair for a new relationship and the Bob’s Bait Shop associating that with an account. There are different ways this could work, but let’s explore just one that involves a Sovrin app called a connector. The connector runs on the person’s device and helps them manage their keys. In some ways, it would feel like a password management app such as 1Password. The connector is secured by the operating-system security services on Alice's device as well as app-specific mechanisms. When Alice wants to connect with Bob’s Bait Shop via a Web site or mobile app, she uses the connector to generate a new Sovrin public-private key pair for that relationship. The connector securely stores the private key, then uses the public key to generate and register a new identifier on Sovrin. Alice gives the identifier to Bob’s Bait Shop, who creates an account and associates the internal account identifier with the Sovrin identifier. This association could be memorialized as a claim. If desired, Bob’s Bait Shop could generate a challenge that Alice signs with her connector to prove that she gave them a real Sovrin identifier. Bob’s Bait Shop might also ask Alice to provide information for creating the account. The connector would automatically determine which claims (either verifiable or self-asserted) can be used to satisfy the request, obtain permission from Alice, and then transmit those claims to Bob’s Bait Shop. Sovrin can partially disclose the information in the claims to protect Alice’s privacy. As part of requesting information from Alice, Bob’s Bait Shop could send a consent receipt that records promises made to Alice about how her disclosed information will be used. The connector stores a hash of the consent receipt on the Sovrin ledger to notarize it. Note that Alice didn’t create a password or fill out forms. And she received a receipt documenting her consent. The connector remembers all of the services with which she’s enrolled and gives her a single place where she can see everyone with whom she has a relationship1. Bob’s Bait Shop doesn’t store or manage passwords. They didn’t have to validate email addresses or phone numbers (provided they received claims they trust). And yet, they have a secure method of authenticating Alice and account information they can trust. Login User authentication is the most obvious use case for any identity system. Based on the discussion of enrollment above, assume Alice and Bob’s Bait Shop have already exchanged an identifier and that Alice’s connector is storing the corresponding private key as well as an identifier for Bob’s Bait Shop that can be used as a public key. Authentication is done using any of the standard public-private key authentication schemes. One method consists of Bob’s Bait Shop presenting Alice with a one-time challenge string (i.e. a nonce) that her connector [...]



On Sovereignty

Wed, 02 Nov 2016 08:30:07 -0600

Summary: Sovereignty is much more than control. Sovereignty is about relationships and balance of power.

(image)

There's a lot of confusion about self-sovereign identity.

Many people hear sovereign and think "sovereign means the individual has complete control." Not really. As Scott David pointed out, "declaring yourself king of a deserted island isn't very useful."

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.

Self-sovereign identity (SSI) describes the same situation. A self-sovereign identity system (SIS) defines the things over which an entity (person or organization) has complete control along with the rules of engagement for its relations with other entities in the SIS system.

For example, an SIS might give entities complete control over what claims they share in response to queries about them. But sovereignty doesn't mean that a party relying on a claim has to accept it. The relying party's sovereignty allows it to determine what claims satisfy its demands and which don't.

But sovereignty means that all powers are reciprocal. Continuing the example, anyone can reject the claims others choose to present to them. The key to sovereignty is that all entities are peers. I have the same rights you do. The beauty of sovereignty isn't complete and total control, but rather balance of power that leads to negotiations about the nature of the relationships between various entities in the system.

Tags:




When People Can Share Verifiable Attributes, Everything Changes

Thu, 20 Oct 2016 14:32:45 -0600

Summary: Verifiable, owner-provided attributes are the engine that will drive wide-spread adoption of self-sovereign identity systems. This article explains how this models the way credentials work in the physical world and describes benefits of owner-provided attributes. In the physical world, people carry credentials to prove to others that they have certain attributes or hold certain privileges. Online, this is not possible. For example, a driver's license contains attributes like name, address, and date of birth that have been validated by the Driver's License Division. The driver’s license is widely viewed as trustworthy. Consequently, people use driver's licenses for purposes other than driving. For example, a school or pharmacy can easily verify that a license belongs to the person presenting it, and confirm the validity of the license without ever contacting the Driver's License Division directly. In other words, in the physical world, people hold and are the conveyors of their own trustworthy attributes (called “claims” by identity experts). These attributes can be used when needed and without prior agreement. Online, such interactions are only possible through pre-arranged integrations between the APIs of specific computer systems. Identity systems in use today include federation for business-to-business credential sharing, and social login for consumer authentication1. Neither of these offers a foundation upon which third-party claim issuers can easily build services that allow for the kind of ad hoc attribute sharing that happens in the physical world. Consequently, entities who want to rely on attributes from many parties have to perform integrations with all of them. This is slow, complex, and costly, so it typically happens only for high-value applications. Decentralized identity systems, like Sovrin, have built-in support for third-party claims that function in the same way physical credentials work: they’re presented directly by the identity owner. The identity owner can use a claim from one party to disclose attributes to another party without those parties even having a relationship, much less a technical integration2. Claims can be used in ad hoc situations, just as they can in the physical world, allowing individuals to function as integration points. When you can instantly trust what someone says about themselves, workflows and integrations are dramatically simplified. There are other benefits to owner-provided attribute sharing. First, when owners share attributes, the receiver automatically gains consent to use the attributes for the requested purpose. This significantly reduces liability. Second, when the owner is part of the process, they can check the accuracy of the attributes as they’re being shared, resulting in better data. Owner-provided attributes are a powerful driver that will push decentralized identity systems well beyond the current uses of federation and social login. Businesses can reduce or even eliminate API integrations and manual verification processes, and instead trust what's presented to them by customers, because the claims can be verified. Customers become the source of what's true about them. Businesses will find great value in this, driving adoption by individuals as customers are brought into decentralized identity systems through day-to-day business activities. See Self-Sovereign Identity and the Legitimacy of Permissioned Ledgers for more on the difference between self-sovereign identity systems and social login. See How Sovrin Works for details on how claims can be received, stored, and shared as verifiable disclosures. Tags: distributed+ledger identity sovereign-source claims sovrin [...]



TL;DR: How Sovrin Works

Fri, 07 Oct 2016 14:55:41 -0600

Summary: An animation showing how Sovrin works.

If you're too busy to read How Sovrin Works, here's a short animation that summarizes the post using my graphics. Thanks to Andy Tobin for putting it together.

(image)

Tags:




How Sovrin Works

Mon, 10 Oct 2016 09:44:26 -0600

Summary: This article describes how Sovrin works by showing the interactions of a Sovrin user, Jane, with organizations she does business with. The examples highlights Sovrin's features and method of operation. Sovrin is an open-source identity network built on distributed ledger technology. Sovrin is public and permissioned. Public means everyone can use it. Permissioned means that the network nodes that ensure consensus of transactions on the ledger are governed, in this case by the non-profit Sovrin Foundation. In this discussion we're going to look at the interactions of a Sovrin user named Jane with her bank, her local government, a potential employer, her school and a retailer. The following figure shows Jane's view of her identity on Sovrin. Right now there's nothing there, but we're going to add things as we discuss Sovrin's capabilities in the following sections. Jane's identity doesn't really exist as depicted. The view is a virtual representation. Jane's Sovrin identity is the collection of all of her Sovrin identifiers, claims, disclosures, and proofs. The things in the box labeled "Jane's identity" are stored in various places. Most, but not all will be on the Sovrin ledger itself, some might be stored off the ledger in other repositories like the private ledger we'll discuss later. Jane and an empty ledger The diagram also shows the Sovrin Ledger. The ledger is shown to emphasize that everything we talk about is using the ledger. There are far too many lines for the diagram to show all the various interactions with the ledger itself, so I've chosen to merely represent it and use it as a place to show the diagram's legend. The Sovrin Identity Network (SIDN) consists of multiple, distributed nodes located around the world. Each has a copy of the ledger. Nodes are hosted and administered by stewards. Each node has a copy of the ledger. Stewards are responsible for validating identity transactions to assure consistency about what is written on the ledger and in what order. They do this using a combination of cryptography and an advanced Byzantine fault tolerance algorithm. See the Sovrin whitepapers The Inevitable Rise of Self-Sovereign Identity (PDF) and The Technical Foundation of Sovrin (PDF) for more details. Keys, Identifiers, and Relationships Sovrin tracks keys and identifiers. One of the major concerns with identity is correlation. If Jane were to use one identifier in multiple places, those places might collude to correlate that identifier and amass significant data about her without her permission. Sovrin avoids this by allowing Jane to use a different identifier with everyone she relates to. By default, Sovrin identifiers are cryptonyms, an encoded Ed25519 digital signature verification key. Sovrin also supports DID’s (Distributed Identifiers), which are identifiers with no cryptographic properties. These identifiers also have an associated Ed25519 verification key. In the diagram the signing key is represented by a small letter and the verification key is represented by a big letter. These two keys represent a private-public key pair. Jane never shares her signing key, only the verification key. Jane's relationships Jane has a relationship with her bank. She shares a verification key, A, with the bank that created specifically for this relationship. This key represents Jane's identity to the bank and can be used to verify any interactions that they have. The bank also has its own key, K. This is a well-known key that represents the bank to the world. Jane would also have a copy of that so that she can validate communications she has with her bank. The verification keys of both Jane and the bank are found on Sovrin, so they can both know they are using the latest verification keys of the other party. As we add new relationships to this diagram, you'll see that J[...]



Announcing the Sovrin Foundation

Thu, 29 Sep 2016 05:36:36 -0600

In London today, we're announcing the formation of the Sovrin Foundation. Sovrin Foundation is a private-sector, international non-profit that was established to govern the Sovrin Identity Network (SIDN). SIDN is a public, permissioned distributed ledger purpose built for identities. The Internet was created without any way for people and organizations to be identified. On the Internet, only machines get identities in the form of IP numbers. This is understandable given what the creators of the Internet were trying to achieve. But the lack of a decentralized, heterarchical, and interoperable identity system has created an environment where the services most people use online are a lot more centralized than the Internet they're built upon. Sovrin Foundation aims to rectify that. Using the virtues of Internet as a model, The Sovrin identity protocol uses a distributed ledger to replace today's centralized identity intermediaries. I believe an Internet-like identity system will create new opportunities for everyone by streamlining interactions and enabling stronger levels of trust. As I wrote earlier, self-sovereign identity creates a vast new identity ecosystem because it frees millions of organizations to write claims on the ledger. Sovrin is designed to allow this ecosystem of claims providers to thrive. A permissioned ledger needs a governance process to determine the business processes and overarching legal framework that validators on the network must follow to ensure that2 SIDN can be trusted. Sovrin Foundation provides the lightweight governance that is needed to do that. Sovrin Foundation governs the network and the open-source code that makes it work, but we don't own or control people's identities, they are sovereign. The Foundation has four primary duties: Develop and maintain the Sovrin Trust Framework, governing the selection and monitoring of Sovrin stewards and operation of the Sovrin Ledger. Coordinate and monitor steward activity to ensure the ledger is stable, correct, and trustworthy. Manage the Sovrin Project—the open source code that operates, validates, and provides access to the ledger. Promote universal acceptance of the Sovrin ledger for self-sovereign identity. I've agreed to serve as the inaugural chair of the foundation. I co-founded the Internet Identity Workshop with Kaliya Hamlin and Doc Searls a dozen years ago with the goal of promoting what we then called "user-centric identity." My motivations in doing that were the same as they are here: find a way to unlock the vast potential of people who own and control their online identity. We have a tremendous, global Board of Trustees who have agreed to serve and help organize the foundation. Each person on the board brings unique talents and perspective. I'm excited to work with them in organizing Sovrin Foundation and bringing this to fruition. Evernym developed the code that makes Sovrin work and has generously gifted that code to Sovrin Foundation. Making it open source wasn't enough. Sovrin Foundation can't govern SIDN without also owning the code that makes it work. Timothy Ruff and Jason Law, Evernym's founders, saw early on that the best way to make Sovrin successful was to give it away. Sovrin Foundation is grateful for their support and this demonstration of trust. You can get more information from the following links: Technology White Papers If you'd like to know more, feel free to contact us. We invite your participation. Tags: sovrin distributed+ledger identity sovereign+source sovrin+foundation [...]



Self-Sovereign Identity and the Legitimacy of Permissioned Ledgers

Wed, 21 Sep 2016 14:12:47 -0600

Summary: This post justifies the claim that an identity system based on a permissioned distributed ledger is legitimately self-sovereign. The post also examines the claims to legitimacy that social login and distributed ledger identity systems make. My last blog post was about creating an Internet for identity, a decentralized system that allows people and organizations to create identities independent of intervening administrative authorities. The post describes this system as self-sovereign and I call the system a self-sovereign identity system or SIS. I believe the right way to construct SIS is using a public, permissioned distributed ledger. Permissioned ledgers have important properties that make them specifically useful for identity systems. But permissioning implies governance. Someone has to determine who has permission to participate in approving transactions. If there are people making these kinds of decisions, how can a governed, permissioned ledger justify a claim that it supports self-sovereign identity? John Locke and Sovereignty John Locke was an English philosopher who had a big impact on the thinking of America’s founding fathers. Locke was concerned with power, who had it, how it was used, and how society is structured. More importantly, Locke’s theory of mind forms the foundation for our modern ideas about identity and independence. Locke argued that “sovereign and independent” was man’s natural state and that we gave up freedom, our sovereignty, in exchange for something else, protection, sociality, commerce, among others. This grand bargain forms the basis for any society. As a community, the Internet proposes a similar bargain. The goal of being self-sovereign isn't to be completely independent. With regard to the Internet: only machines without a network connection are completely independent. In the case of identity: only people without any relationships are completely independent. Seen from Locke's viewpoint, sovereignty is a resource each person combines with that of others to create society. Voluntarily giving up some of our rights to a state confers legitimacy on that state and its constitution. Constitutional Orders and Legitimacy Wikipedia defines legitimacy as the right and acceptance of an authority, usually a governing law or a regime. While this is most often applied to governments, I think we can rightly pose legitimacy questions for technical systems, especially those that have large impacts on people and society. With respect to legitimacy, Philip Bobbit says:1 The defining characteristic ... of a constitutional order is its basis for legitimacy. The constitutional order of the industrial nation state, within which we currently live, promised: give us power and we will improve the material well-being of the nation. In other words, legitimacy comes from the constitutional order: the structure of the governance. Citizens grant legitimacy to constitutional orders that meet their expectations by surrendering part of their sovereignty to them. Regarding constitutional orders, Bobbitt says the following:2 The constitutional order of a state and its strategic posture toward other states together form the inner and outer membrane of a state. That membrane is secured by violence; without that security, a state ceases to exist. What is distinctive about the State is the requirement that the violence it deploys on its behalf must be legitimate; that is, it must be accepted within as a matter of law, and accepted without as an appropriate act of state sovereignty. Legitimacy must cloak the violence of the State, or the State ceases to be. Legitimacy, however, is a matter of history and thus is subject to change as new events emerge from the future and new understandings reinterpret th[...]