The Internet was initially architected without consideration for a secure, viable identity infrastructure. Passwords were an afterthought and there was little consideration given to privacy and how individuals could assert control over their personal data. There have been many attempts to remedy these shortcomings and there are growing open source and industry initiatives to deal with these issues. These factors combined with the move towards “personal data clouds,” mobile and sensor data, and the recognized importance of protecting and sharing personal data, is forcing a fundamental rethinking of the global Internet architecture for secure and privacy-preserving communications and computations.
What is clear is that the current infrastructure cannot be simply uprooted and replaced, and that the next “authentication, privacy and sharing layer” has to grow organically on top of the existing layer. Fortunately, a combination of technologies for the self-deployment and administration of services with new encryption, identity authentication and access controls technologies and protocols are making it feasible to scale new self-deploying infrastructures. Such new approaches make it possible for social groups to naturally emerge where individuals can control their own personal data in many ways that allow for a balanced, transparent and law-based approach for expressing and enforcing individual and group data rights. The Open Mustard Seed (OMS) platform represents an open source effort to enable such an architecture on a global scale.
The Open Mustard Seed project is an opensource Trust Framework for developing and deploying web apps in a secure, user-centric personal cloud. In this sense, it is both a Platform as a Service model (PaaS) as well as a basis for building global digital identity infrastructure and data asset ecosystems. Specifically, a Trust Framework is a combination of software mechanisms, contracts, and rules for defining, governing, and enforcing the sharing and protection of information.
A typical Trust Framework is described and often decomposed into Technical and Operational Specifications in conjunction with a set of legally binding Rules (Policies). Thus, the system itself is designed to orchestrate and execute the specifications and policies according to common, predictable, and independently verifiable standards of performance. The goal is for all parties to trust that the system will regulate, enforce and maintain the obligations of all participants in a transparent and auditable manner. To this end, we focus on the development of an ecological model for social/civic engagement, one that provides identity assertions in a manner such that all relying parties are subject to independent and autonomous contracts for data rights enforcement, whether those participants are represented by individuals, groups (e.g., elected representatives), system entities (e.g., autonomous agents), companies or even governments. In this sense, the Open Mustard Seed Trust Framework defines the processes and procedures that provide mutual assurance between “Institutions” and Decentralized Autonomous Organizations (DAO) and Decentralized Autonomous Authorities (DAAs) with respect to privacy, performance and remediation.
One of Open Mustard Seed’s main goals is to operationalize the creation of decentralized digital institutions in a generic framework, emphasizing Don’t Repeat Yourself (DRY) principles. In doing so, we recognize the need for a framework that allows for interoperability at scale, while providing a development environment for applications that can specify the requirements and rules that govern user participation in an extensible and reusable manner.
Below are some of the criteria reflecting a NSTIC (National Strategy for Trusted Identities in Cyberspace) perspective on organically creating an operational and autonomous Trust Framework:
Thus the Trust Framework itself provides a stack of core technologies that work together to provide a high level of security and ease of use when computing upon sensitive information. This includes: sharing and collecting personal and environmental data; controlling Web-enabled devices; engaging with others to aggregate information and view the results of applied computation via protected services; and participating in market creation and clearing events that allow parties to execute contracts that set forth the rules and obligations when it applies to managing and exchanging data rights and their associated risks.
The Hierarchy of Structural Decompositions in OMS
Trusted Compute Cell
Trusted Application Bundle
Open Mustard Seed Root Identity modules
In OMS, Trust Networks form distinct ecosystems. That is, an enterprise, an NGO, government agency, social network, academic institution, an artist collective or even an individual, can each host its own private cloud defining their own set of rules – while still remaining beholden to the organizational structures they exist within (e.g., automatic regulatory compliance based on physical location). Even though these are thought of as distinct Trust Networks, the virtual and physical infrastructure that composes them are likely to be massively varied and shared amongst many. For example, a Trust Network can be defined as the internal chat network that family members use to sync amongst themselves and thus might be contained in a small set of virtualized services hosted from a single source, such as their home entertainment system. On the other side of the spectrum, OMS could be used to develop a clone of a global social network (Facebook), only it would be distributed, autonomous and under the control of a group comprised of billions of Personas, accountable to user-centric data control, completely personalized, etc.
Noting that Trust Networks can also scale to be as complex as serving a multiplicity of simultaneous purposes, OMS employs federated single sign-on and user-managed access models to orchestrate massively distributed aggregations of data. To make managing such a deployment even feasible, any solution must embrace system design principles that emphasize stability-enhancing behavior. Thus OMS takes an ecological approach for the composition of services running at different sources with different users/admins at many levels in the hierarchy. Living systems are organized in such a way that they form multi-leveled structures, each level consisting of subsystems which are wholes in regard to their parts, and parts with respect to the larger wholes. We call systems that exhibit these properties a “holarchy” and the individual units themselves are known as “holons.” (See Chapter 11, “The Logic of Holonic Systems,” by Mihaela Ulieru.) This enables Trust Networks in OMS to provide a middle ground between network and hierarchical structures, and exhibit four basic characteristics:
Trusted Compute Cell
OMS allows developers to implement web services that are easily queued, monitored, and decommissioned in a trusted environment in the cloud. This is accomplished by use of secure computational containers. A Trusted Compute Cell (TCC) is the virtualized equivalent of the minimal Trust Network (a Group of one) that remains fully interoperable within OMS. TCCs are currently defined around industry standard Virtual Machine environments. For instance, a TCC can be deployed to the Rackspace Public Cloud (via OpenStack) or be hosted within a Public Cloud’s virtualized environment (VirtualBox); both are equivalent for all intents and purposes.
Since they provide all the privileges of a DAO, TCCs are typically employed as the basic unit of individual control over their data. That is, each Trusted Compute Cell (TCC) can serve as a Persona Manager for the user, providing the necessary operations in order to issue credentials in accordance with attribute-based access control policies. In its simplest form, an online digital identity is formed by users establishing their rootID within a TCC, allowing them to authenticate and grant themselves access to their own data. High assurances can be granted to the user by establishing a verifiable hardware and software chain of trust in conjunction with biometric based authentication. Fortunately, this functionality can be automated through the manner in which the TCC is configured.
From this point, the system architecture uses nested tiers of Trusted Compute Cells networking the individual, fully controlled cell (Private TCC) with other self-governed Group TCCs, and publicly accessible Portal TCCs. The idea is to enable trusted social relationships and collaboration that can scale.
Central to the proposition that users should control their own data is the Personal Data Store (PDS). For the user, access to their PDS resource is regulated through their TCC. The TCC enforces API permissions logic, referring to the user’s privacy and sharing settings to determine whether to allow a particular operation on an API. This allows TCCs to provide protected access to shared data for the purpose of computing results that do not violate the rules and permissions of users, the installed applications, or the Trust Network wherein they reside.
A user’s private sphere/hub is the set of Private TCCs that oversee his or her identities and personal data services. From this perspective, the user can see all of his or her data. This root/hub presents visibility/accessibility into all that “grows” from the data (the identity anchor point from which all builds in relation to), as illustrated below:
• All that the user collects, produces, manages, distributes, (for which they exercise their data rights).
• Privacy settings
• Linkage to social hubs or aggregation points, interfaces to curate personas
• Dashboard for managing the installation and availability of apps and services
OMS as a trusted compute infrastructure enables users to contribute to or interact with collective computation (serving the members of trusted group as well).
Although there is a significant complexity in the underlying infrastructure, OMS is designed so that the individual and even developers are shielded from this complexity by higher level interfaces that simplify both privacy setting and sharing choices and the requirements of developers to comply with privacy and security policies.
Trusted Application Bundle
The Trusted Application Bundle, or TAB, contains digital legal contracts that outline the opt-in terms of agreement for online interactions provided by the deployment of the APIs contained within the TAB’s Manifests. These agreements are subsequently enforced, on behalf of the persona – within the TCF to which the TAB instance was deployed. Furthermore, TABs specify what data may be collected, accessed, stored, how it may be used, etc.; what access-control mechanisms and policies will govern data; and the “constitutional rules” by which groups may form, manage themselves, and evolve.
To a user, Groups may be logically separated by the classes of contractual obligations they opt-into upon registering a Persona within the group context (data rights grant) or by installing a TAB and inviting other personas to join that TAB’s group. The installable TABs may be specified (and even distributed) by the entity hosting the Trust Framework and are the means for the institution to reflect rules and permissions options granted to its members. Thus, every Group is anchored and deployed in the context of its governing Trust Networks via association with a particular instance of an installed TAB. This is the relational matrix that reflects the meaningful information to the user.
Distributed systems can form such that each node can originate independently yet still remain interoperable across trans-institutional boundaries. Yet still, in OMS, the physical infrastructure and the software running on it determine a measurable or quantifiable Quality of Service for each distinct instance of a deployed TAB. This Interface/Abstraction Boundary also facilitates application of existing third-party certification of protocols and standards.
It is common for users to have groups they would like to keep separate (fully secure) but still be able to make chat connections with within a single interface. This potentially requires that they maintain completely separate virtual infrastructure, including root-of-trust pathways for each instance of the client application. In order to facilitate standardization around deployment patterns, we modularize around the TAB, allowing multiple instances to be installed and associated with distinct personas. A user may also replicate their deployments across many different hosted systems for added assurances around redundancy, availability, security, etc. This enables hosting to be commoditized at every scale.
It is like having separate copies of Skype running for each alias you might use day-to-day: colleague, friend, family, etc. However, with OMS the perspective can be controlled by the user or their proxy since they are the only ones that can re-aggregate all of their personas. This enables the UX to present views that are composed from data aggregated across various sets of their persona allowing for unified, convergent visualizations, reconstructing the 360-degree view of themselves.
TABs further include provisions for enforcing:
• What data is collected, accessed, stored, logged, etc.
• How users interact and share information
• How groups are formed, governed, managed, and evolved (See Chapter 12, “The Algorithmic Governance of Common-Pool Resources,” by Jeremy Pitt and Ada Diaconescu)
•How Markets and Exchanges can be built on top of decentralized data rights through contract enforcement
A root identity infrastructure provides a way for each person to own their single underlying root identity (i.e., the “Core Identity”) and to bind several Personas to that Root Identity without the need for other parties to access the Root Identity or be aware of any other persona.
The root of the chain of trust is anchored to a single physical token. From there a user can generate many downstream Personas – in this case, for use within an infrastructure that provides “authentication as a service.” This means that user-centered and user-owned Root Identities can be leveraged for a “claims-based” federated identity without giving up the Root Identity or unique information to every requesting party or other counter party or being aware of any other persona. Furthermore, it is possible for multiple aliases, accounts, and attributes to be authenticated in a reliable, privacy enhancing, and scalable manner.
In relationship to PDS or digital vault, rootID cryptographically originates keys for decrypting and controlling access to PDS. As such, rootID is portable and allows the user to backup “credentials.” OMS realizes that unless there is a framework enabling interoperability, each institution could possibly offer a unique data ‘vault’ to their customer leading to massive fragmentation of the user’s “identity.”
Open Mustard Seed is developing a open registration and authentication algorithm for supporting sovereign identities that are bootstrapped by the user and carry attributes verified by their online interactions and by attribute authorities within the rootID infrastructure. Users can install a native app that collects data to establish a biometric/behavioral “fingerprint” (Personal data + Social Interactions + Sensor Data = Unique “Signature”) for themselves to be used as their credential for authenticating into their Private Clouds. The native App further provides data-driven services (via a secure vault for storing high-value personal data assets) and sets up OMS in the background. This can be done such that the user doesn’t see any difference from how they install apps today except for the obvious notices about their data and opt-in agreements will be OMS.
Moreover, the Private TCC is meant to run in a myriad of locations where there is no central administrator. This ensures that when user’s data is imported, provenance/origination/indexing/meta-tagging/filtering/etc. will be automatically applied, as obligated by the installed governance principles, independent of the deployment.
What is a Persona?
A persona represents an aspect of a user’s digital identity. Granting a persona to an external (to the user) agent represents delegating an aspect of the user’s self to that agent. A good way to think about this relationship would be as a power of attorney: a physical being authorizes some legally recognized entity to act on their behalf in some capacity. That entity is implicitly granted any access required in order to fulfill that capacity, and anything done by that entity is considered as if done by the physical being directly.
Moreover, a persona is a self-contained composite object with embedded data or attributes. These attributes contain a list of scopes that determine the access the persona can be granted for a particular API. Thus, when a persona is granted to a client, the client is implicitly granted any scopes it has in common with the persona. In order to provide a convenience to the user, Personas can be created with different sets of scopes, consistent with particular contexts of the user. For instance, a “banking” Persona can be specified with a set of scopes that enable applications to access a user’s financial information while a “friends and family” Persona could provide access to a user’s photos and calendar information.
Besides containing scopes as attributes, Personas can carry generic information and provide a means for user to interact with other users in a trusted manner without revealing personal information. That is, personas are either anonymous, pseudo-anonymous, partially verified or fully verified. Verified Personas have attributes that have been digitally signed by a rootID Attribute service so that services can determine the validity of claims that Personas present without requiring direct access to the user that created the Persona in the first place.This data-driven functionality builds from initial provisioning of rootID. This process anchors the user’s identity in digital equivalent, PDS vault containing the “body” of Personal Information the user owns/controls. Subsequently, the user projects their identity through the equivalent to “identity proxies” or Personas. This allows the user to participate in particular contexts without having their identity exposed (or personal data leaked about them without their expressed approval).
OMS solves a number of interrelated problems about Big Data and the digital marketplace. A user may not know with whom they are really transacting, nor can they readily verify that their privacy preferences are actually respected and enforced. Users are often wary of exposing or sharing their data with third parties whose trustworthiness is not known. In this context, it is not surprising that protecting one’s personal information is seen as antithetical to commercial and governmental uses of it. However, users can now think of creating Personas in cases where they would like to control their privacy, e.g., use a persona for making an online payment where one of the attributes is a single-use authorization code. A Vendor can access Persona Attributes to verify shipping information, buyer reputation, etc. Both parties can feel protected while subject to automated dispute resolution and other protections.
Users have not had an easy or reliable means to express their preferences for how their personal data may be accessed and used, especially when one context (a bank) differs so much from another (a healthcare provider) and still others (family and friends). As a convenience for the user, each Persona can represent a different social norm or set of preferences, from which derivatives can easily be generated. This is so the user is not overwhelmed with managing the privacy preferences separately for each context.
Instead, for each context a user creates generalized/segmentation/template Personas and reuses them. For the default cases, Personas can be defined and automatically prepopulated. Other Personas could be based on the results of predictive analytics applied to the user’s behavior in such a manner that these Persona are highly likely to match the user’s actual preferences, i.e., machine-learning can predict most likely preferences and auto populate a Persona and then automatically apply it to the context/application domain.
“Ideally” every user wears self-initializing hardware rootID (Secure Element) that contains specialized hardware to generate public/private keypair physically tied to the user. Since the private key never needs to leave these devices and cannot be accessed from outside, rootIDs, personas can be derived and used to represent the user in online transactions, and can all be trusted to a standard level of performance.
For the most secure and trusted systems, there needs to be rootID installed at the sensor/chip level for every device that exists within the Trust Framework. Even keyboards built into mobile devices themselves or user “owned” virtual machines would also need to be paired with a secure element – if they are intended to be interoperable with any component of a Trust Framework that required a highly available chain of trust validation service.
The more the infrastructure can provide the appropriate level of assurance automatically, for a given context, the more self-enforcing trusted transactions can become the norm. Presently a tremendous wave of new data-driven market ecologies is poised to thrive, including robotics, Internet of Things, Quantified Self, geolocal-social trends.
Personas for Everything, Groups
A group itself can be a persona; each unit is self-contained while also being connected to everything around it. This allows us to reduce a “group” of personas and project it as a single persona that is afforded the consensus of the group and has the potential to leverage the sum total of all the resources available to its members. Our notion of groups may be quite novel and the implications are potentially very interesting.
Ideally, OMS itself would guarantee that the group node could be trusted with total transparency into its process – enough so that the participants would all be equally represented and they would be willing to enter into contracts with high entropy-enabling flow-through mediating high-risk transactions.
Data Asset Market – Executable Contracts
Groups can be considered as a pattern suitable for enabling spontaneous and variably lasting markets by connecting institutions with transferrable data rights. That is, a Group TCC’s policy manager essentially implements data rights exchange automation for distributing OAuth tokens to invited guests based on the credentials they were assigned by the acceptance of the invite (transfer of rights). This allows users in a chat channel to present themselves as authenticated and rootID-backed identities while leveraging attributes to specify their projection, from anonymous to completely verified digital identity. Within particular contexts, typified by shared social responsibilities or market participation rules, the Policy Manager is also expected to adhere to higher priority policies defined by the encapsulating Trust Network(s).
Looking at it from another perspective: we just want to be able to hyper-dynamically create, read, update, and delete (CRUD) networks of input/output sources and trusted computation. This takes us back to the problem of, “how do we get the best use out of the fact that the largest network is the one that moves the most data through it (and that means being able to connect everything to it and allow each of those things to self assert their identity), provide some verifiable measure of trust?”
This allows someone to walk into a restaurant, class room, client, hotel room, theme park, of the future and experience “bring your device to work” qualified security and have all the video cameras, keyboards, monitors, temperature sensors, microphones, every I/O device under rootID hardware. In the ideal world you get this much control over your data by being able to deploy your private infrastructure yourself or through a trusted third party who maintains it in a way that they provably cannot access, imped or otherwise destroy your data.
Open Mustard Seeds is an open platform as service intended to provide a powerful new self-deploying and self-administrating infrastructure layer for the Internet, which gives individuals control over their identities and their data, and which enables the formation and self-governance of Decentralized Autonomous Organizations, Authorities and Enterprises to enable the creation and exchange of “digital assets.” At the same time, OMS provides a framework for the autonomous regulation and enforcement of diverse global data protection and financial policies.
Moreover, OMS enables the definition, deployment, operationalization and enforcement of Trust Frameworks at scale to enable Data Ecologies based upon transparency and trust. OMS meets not just the aspirational intentions of the Consumer Data Bill of Rights; it is fully operational, autonomous and scalable. It addresses many long-standing and confounding institutional issues such as “who guards the guards” and the “principal/agent problem.” It also solves issues related to the chain of custody for identity verification and interoperability, and respect for context and data-minimization.
OMS differs significantly from other approaches in that it is self-deploying, self-healing, self-governing and self-enforcing and -correcting. It uses contracts not only to express and assert rights but to control how they are expressed. This is achieved through control over permitted data attributes and through the configuration, logging and correction of processes and VMs. Like the Bitcoin protocol, it uses algorithmic oversight and signing in preference to human intervention to enable efficiency, scale, performance, integrity, transparency and open innovation. It is based upon many open source bundles based upon the M.I.T. X11 open source license.
 Over the last ten years there have been many concerted efforts to deal with identity, authentication, and federation of access issues on the Internet and give users control over their personal data. Some the efforts related to this work include Microsoft’s Kim Cameron’s Laws of Identity, at http://www.identityblog.com); Project Higgins, a project started at the Berkman Center (http://www.eclipse.org/higgins); an industry consortium, Kantara (https://kantarainitiative.org); Project VRM, also started out of Harvard’s Berkman Center (Project VRM, at http://blogs.law.harvard.edu/vrm/); OpenID Connect (http://openid.net/connect); and more recently, from the Human Dynamics Group at the M.I.T. Media Lab, Open PDS (http://openpds.media.mit.edu).
 The approach to a Trust Framework is similar in principle to that proposed by the Open Identity Exchange (OIDX, at http://openidentityexchange.org/what-is-a-trust-framework) and the Open Identity Trust Framework (OITF) model with an important difference. The OIDX approach is based upon a loose set of industry principles and is not really open but is captive to the interests of its board and members. The Trust Framework presented here is an actual platform and an instance of Distributed Autonomous Organization.
 National Strategy for Trusted Identities in Cyberspace (NSTIC) is part of NIST (National Institute of Standards and Technology). See the website http://www.nist.gov/nstic.
 Mihaela Ulieru and Rene Doursat, “Emergent Engineering: A Radical Paradigm Shift,” International Journal of Autonomous and Adaptive Communication Systems (IJAACS), 4(1) (2011).
 Much of the initial work on getting personal data for predictive analytics was initiated at the M.I.T. Media Lab by Nadav Aharony (http://nadav.media.mit.edu/index.html%3Fn=Projects.Funf.html), which also triggered the development of OpenPDS by Yves-Alexandre de Montjoye, at http://www.demontjoye.com/projects.html.
 We are fortunate to leverage the open source version of OpenID Connect and OAuth 2.0 developed by Justin Richer of MITRE Corp., which is now being supported by the M.I.T. Kerberos and Trust Consortia. We did make modifications of the MITRE version to support Personas.
 IBM’s IDMIxer (http://researcher.watson.ibm.com/researcher/view_group.php?id=664) and Microsoft’s Uprove technology (http://www.microsoft.com/mscorp/twc/endtoendtrust/vision/uprove.aspx) provide zero knowledge proofs for protecting personal identity while providing requisite authentication.