Skip to content

mitmedialab/SovereignIdentityPrinciples

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 
 
 

Repository files navigation

Sovereign Identity Principles


Existing Starting Points


Sovrin Trust Framework Principles

https://docs.google.com/document/d/18V1c0rOQYxNMleuV_2z7yQny0KdBnuDkWlN8DNUrioM/edit#

  1. Purpose and Principles

The purpose of the Sovrin Network is to provide a global public utility for self-sovereign identity that adheres to the principles below.

2.1. Independence and Self-Sovereignty

An Identity Owner shall have the right to completely and permanently own and control one or more Sovrin Identities without the need to rely on any external administrative authority and without the fear that a Sovrin Identity will ever be taken away.

2.2. Guardianship

An Identity Owner who does not have the capability to directly control the owner’s Sovrin Identities (a Dependent) shall have the right to appoint another Identity Owner who has that capability (an Independent) to serve as the owner’s Guardian. A Dependent has the right to become an Independent by claiming full control of the Dependent’s Sovrin Identities. A Guardian has the obligation to promptly assist in this process provided the Dependent can demonstrate that the Dependent has necessary means to exert control. Guardianship also applies to Things.

2.3. Diffuse Trust

The Sovrin Foundation and the Sovrin Trust Framework and its Business Policies, Legal Policies, and Technical Policies shall not concentrate power in any single Individual, Organization, Jurisdiction, Industry Sector, or other special interest. Diffuse Trust shall take into account all forms of diversity among Identity Owners.

2.4. Web of Trust

The process and policies for selecting Stewards and Trust Anchors shall not be hierarchical but enable interlocking peer-to-peer trust networks that form an overall Sovrin Web of Trust.

2.5. System Diversity The process and policies for selecting Stewards shall maximize diversity of hosting locations, environments, networks, and systems in order to optimize availability and security.

2.6. Interoperability

The design, governance, and operation of the Sovrin Network shall endeavor to provide Members with maximum interoperability of their Sovrin Identities, Public Data, and Private Data both within the network and with other external systems and networks.

2.7. Security by Design

The design, governance, and operation of the Sovrin Network shall follow the principles of Security by Design to provide Members with security for their Sovrin Identities and Private Data to the greatest extent feasible consistent with the other principles herein.

2.8. Privacy by Design

The design, governance, and operation of the Sovrin Network shall follow the principles of Privacy by Design to provide Members with privacy for their Sovrin Identities and Private Data to the greatest extent feasible consistent with the other principles herein.

2.9. Portability The design, governance, and operation of the Sovrin Network shall provide Members with portability of their Public Data and Private Data to the greatest extent feasible consistent with the other principles herein.

2.10. Accountability

Members of the Sovrin Network shall be accountable to each other for conformance to the purpose, principles, and policies of the Sovrin Trust Framework.

2.11. Open by Default

The Sovrin Foundation and the Sovrin Network shall operate with full openness and transparency to the greatest extent feasible consistent with the principles herein, including the proceedings of the Sovrin Board of Trustees and the Technical Governance Board, the development and distribution of Sovrin Open Source Code, the qualification and operation of Stewards, and the listing of Agencies and Developers.

2.12. Identity for All

Consistent with the United Nations Sustainable Development Goal 16.9, the Sovrin Foundation and the Sovrin Network shall be accessible to and inclusive of all Identity Owners without discrimination and with accommodation for physical, economic, or other limitations of Identity Owners to the greatest extent feasible.

2.13. Collective Best Interest

The Sovrin Foundation shall govern the Sovrin Network in the collective best interests of all Identity Owners and shall not favor the interests of any single Identity Owner or group of Identity Owners over the interests of the Members as a whole.


ID3 Windhover Principles for Digital Identity, Trust, and Data

https://idcubed.org/home_page_feature/windhover-principles-digital-identity-trust-data/

Self-Sovereign Identity and Control of Personal Data:

Individuals and groups should have control of their digital personal identities and personal data.

In today’s digital world, we communicate, share and transact digitally over the Internet. Individuals who make use of the internet for these purposes should have control over their digital identities and personal data ensuring trust in our communications, and the integrity of the data we share and transact with.

Individuals, not social networks, governments, or corporations, should control their identity credentials and personal data. Control of one’s identity credential and personal data means that a person should have unfettered access to their persona data, and the ability to prevent unauthorized private access, and to verify attributes of their personal identity profile.

Systems should be designed so that duly authorized entities that rely upon individual identity credentials and attributes shall have requisite access to such data and credentials with verifiable proof of authorized permission in order to enforce norms, contracts, regulations and agreements to avoid identified harms and malicious activities. We support the collaborative open source development of systems that embed these governance and enforcement principles.

Transparent Enforcement and Effective Lite Governance:

Enhancing / improving personal privacy while allowing for effective governance and accommodation of legitimate auditing and enforcement needs.

As noted above, these Windhover Principles enable identity, trust, and data technologies to provide effective methods for the transparent and proportionate access and verification of identity data to address legitimate governance and enforcement concerns. That enforcement entities acting on the basis of transparent and verifiable approvals, can access though specific and limited APIs identifying personal data.

Insuring Trust and Privacy:

An effective identity system continuously furthers trust, security, accountability and privacy.

Protecting privacy and fostering trust are foundational Windhover Principles that support a fully functional identity system designed to collect and analyze data in a network in which identities are continuously and independently authenticated. These core principles are intended to foster development of more trustworthy, effective, and profitable services and offerings and reduce the risks and costs of fraud and other abuses.

Open Source Collaboration:

An inclusive open source methodology to build systems that embody these Principles.

Supporters of the Windhover Principles agree to cooperate to build systems that deliver these requirements, participate in Living Labs for development, and to ultimately provide strong technical product solutions that interoperate to meet these challenges.


The IDESG IDEF and the NSTIC Guiding Principles

https://www.idesg.org/portals/0/documents/core/IDEF-Functional-Model-v1.0_MOD-2.pdf and https://www.nist.gov/sites/default/files/documents/2016/12/08/nsticstrategy.pdf

The Guiding Principles are what distinguish the Identity Ecosystem envisioned by the NSTIC from other Identity Ecosystems. They call for all identity solutions to be:

  • Identity Solutions will be Privacy-Enhancing and Voluntary
  • Identity Solutions will be Secure and Resilient
  • Identity Solutions will be Interoperable
  • Identity Solutions will be Cost-Effective and Easy To Use

Christopher Allen’s Self-Sovereign Identity Principles

https://github.com/ChristopherA/self-sovereign-identity/blob/master/self-sovereign-identity-principles.md

  1. Existence. Users must have an independent existence. Any self-sovereign identity is ultimately based on the ineffable “I” that’s at the heart of identity. It can never exist wholly in digital form. This must be the kernel of self that is upheld and supported. A self-sovereign identity simply makes public and accessible some limited aspects of the “I” that already exists.

  2. Control. Users must control their identities. Subject to well-understood and secure algorithms that ensure the continued validity of an identity and its claims, the user is the ultimate authority on their identity. They should always be able to refer to it, update it, or even hide it. They must be able to choose celebrity or privacy as they prefer. This doesn’t mean that a user controls all of the claims on their identity: other users may make claims about a user, but they should not be central to the identity itself.

  3. Access. Users must have access to their own data. A user must always be able to easily retrieve all the claims and other data within his identity. There must be no hidden data and no gatekeepers. This does not mean that a user can necessarily modify all the claims associated with his identity, but it does mean they should be aware of them. It also does not mean that users have equal access to others’ data, only to their own.

  4. Transparency. Systems and algorithms must be transparent. The systems used to administer and operate a network of identities must be open, both in how they function and in how they are managed and updated. The algorithms should be free, open-source, well-known, and as independent as possible of any particular architecture; anyone should be able to examine how they work.

  5. Persistence. Identities must be long-lived. Preferably, identities should last forever, or at least for as long as the user wishes. Though private keys might need to be rotated and data might need to be changed, the identity remains. In the fast-moving world of the Internet, this goal may not be entirely reasonable, so at the least identities should last until they’ve been outdated by newer identity systems. This must not contradict a “right to be forgotten”; a user should be able to dispose of an identity if he wishes and claims should be modified or removed as appropriate over time. To do this requires a firm separation between an identity and its claims: they can't be tied forever.

  6. Portability. Information and services about identity must be transportable. Identities must not be held by a singular third-party entity, even if it's a trusted entity that is expected to work in the best interest of the user. The problem is that entities can disappear — and on the Internet, most eventually do. Regimes may change, users may move to different jurisdictions. Transportable identities ensure that the user remains in control of his identity no matter what, and can also improve an identity’s persistence over time.

  7. Interoperability. Identities should be as widely usable as possible. Identities are of little value if they only work in limited niches. The goal of a 21st-century digital identity system is to make identity information widely available, crossing international boundaries to create global identities, without losing user control. Thanks to persistence and autonomy these widely available identities can then become continually available.

  8. Consent. Users must agree to the use of their identity. Any identity system is built around sharing that identity and its claims, and an interoperable system increases the amount of sharing that occurs. However, sharing of data must only occur with the consent of the user. Though other users such as an employer, a credit bureau, or a friend might present claims, the user must still offer consent for them to become valid. Note that this consent might not be interactive, but it must still be deliberate and well-understood.

  9. Minimalization. Disclosure of claims must be minimized. When data is disclosed, that disclosure should involve the minimum amount of data necessary to accomplish the task at hand. For example, if only a minimum age is called for, then the exact age should not be disclosed, and if only an age is requested, then the more precise date of birth should not be disclosed. This principle can be supported with selective disclosure, range proofs, and other zero-knowledge techniques, but non-correlatibility is still a very hard (perhaps impossible) task; the best we can do is to use minimalization to support privacy as best as possible.

  10. Protection. The rights of users must be protected. When there is a conflict between the needs of the identity network and the rights of individual users, then the network should err on the side of preserving the freedoms and rights of the individuals over the needs of the network. To ensure this, identity authentication must occur through independent algorithms that are censorship-resistant and force-resilient and that are run in a decentralized manner.


Jericho Forum Identity Commandments

https://collaboration.opengroup.org/jericho/commandments_v1.2.pdf

The Jericho Forum commandments define both the areas and the principles that must be observed when planning for a de-perimeterized future.

Whilst building on “good security”, the commandments specifically address those areas of security that are necessary to deliver a de-perimeterized vision.

The commandments serve as a benchmark by which concepts, solutions, standards, and systems can be assessed and measured.

Fundamentals

  1. The scope and level of protection should be specific and appropriate to the asset at risk. • Business demands that security enables business agility and is cost-effective. • Whereas boundary firewalls may continue to provide basic network protection, individual systems and data will need to be capable of protecting themselves. • In general, it’s easier to protect an asset the closer protection is provided.

  2. Security mechanisms must be pervasive, simple, scalable, and easy to manage. • Unnecessary complexity is a threat to good security. • Coherent security principles are required which span all tiers of the architecture. • Security mechanisms must scale; from small objects to large objects. • To be both simple and scalable, interoperable security “building blocks” need to be capable of being combined to provide the required security mechanisms.

  3. Assume context at your peril. • Security solutions designed for one environment may not be transferable to work in another. Thus, it is important to understand the limitations of any security solution. • Problems, limitations, and issues can come from a variety of sources, including geographic, legal, technical, acceptability of risk, etc.

Surviving in a Hostile World

  1. Devices and applications must communicate using open, secure protocols. • Security through obscurity is a flawed assumption – secure protocols demand open peer review to provide robust assessment and thus wide acceptance and use. • The security requirements of confidentiality, integrity, and availability (reliability) should be assessed and built in to protocols as appropriate; not added on. • Encrypted encapsulation should only be used when appropriate and does not solve everything.

  2. All devices must be capable of maintaining their security policy on an un-trusted network. • A “security policy” defines the rules with regard to the protection of the asset. • Rules must be complete with respect to an arbitrary context. • Any implementation must be capable of surviving on the raw Internet; e.g., will not break on any input.

The Need for Trust

  1. All people, processes, and technology must have declared and transparent levels of trust for any transaction to take place. • Trust in this context is establishing understanding between contracting parties to conduct a transaction, and the obligations this assigns on each party involved. • Trust models must encompass people/organizations and devices/infrastructure. • Trust level may vary by location, transaction type, user role, and transactional risk.

  2. Mutual trust assurance levels must be determinable. • Devices and users must be capable of appropriate levels of (mutual) authentication for accessing systems and data. • Authentication and authorization frameworks must support the trust model.

Identity, Management, and Federation

  1. Authentication, authorization, and accountability must interoperate/exchange outside of your locus/area of control. • People/systems must be able to manage permissions of resources and rights of users they don't control. • There must be capability of trusting an organization, which can authenticate individuals or groups, thus eliminating the need to create separate identities. • I n principle, only one instance of person/system/identity may exist, but privacy necessitates the support for multiple instances, or one instance with multiple facets. • Systems must be able to pass on security credentials/assertions. • Multiple loci (areas) of control must be supported. Access to Data

  2. Access to data should be controlled by security attributes of the data itself. • Attributes can be held within the data (DRM/metadata) or could be a separate system. • Access/security could be implemented by encryption. • Some data may have “public, non-confidential” attributes. • Access and access rights have a temporal component.

  3. Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges. • P ermissions, keys, privileges, etc. must ultimately fall under independent control, or there will always be a weakest link at the top of the chain of trust. • Administrator access must also be subject to these controls.

  4. By default, data must be appropriately secured when stored, in transit, and in use. • Removing the default must be a conscious act. • High security should not be enforced for everything; “appropriate” implies varying levels with potentially some data not secured at all.

Conclusion De-perimeterization has happened, is happening, and is inevitable; central protection is decreasing in effectiveness:

Also see: Identity 3.0 - Principles

http://www.globalidentityfoundation.org/downloads/Identity_3.0_Principles_v1.1.pdf

© Global Identity Foundation 2014 Version 1.1 – June 2014

Risk

  1. Decisions around identity are taken by the entity[1] that is assuming the risk; with full visibility of the identity and attributes of all the entities in the transaction chain2

  2. Attributes of an Identity will be signed by the authoritative source for those attributes.

  3. Identity will work off-line as well as on-line; with a lack of on-line verification simply another factor in the risk equation.

Privacy

  1. Every entity shall need only one identity which is unique and private unto the entity; there will be no body issuing or recording identities.

  2. The Identity eco-system will be privacy enhancing; attributes will be minimised, asserting only such information that is relevant to the transaction.

  3. Entities will only maintain attributes for which they are the authoritative source.

  4. The identity of one entity to another will be cryptographically unique; negating the need for usernames or passwords and minimising attribute aggregation.

  5. The biometrics (or other authentication method) of an entity will remain within the sole control of the entity; biometric information will not be used, exchanged or stored outside of the entities sole control.

Functionality

  1. The digital representation and function of an entity type will be indistinguishable from another entity type, and will be interchangeable in operation.

  2. The Identity ecosystem will operate without the need for identity brokers, CA of last resort or other centralised infrastructure.

  3. Identity will be simply expandable to encompass the security of data; E-mail (for example) can be encrypted simply by having an entities e-mail attributes shared with them.

  4. Identity shall be (as much as possible) invisible to the end user; identity and attribute verification and exchange should be a background operation until such time that increased levels of user verification is required.

  5. Everyone plays their part – no more!


[1] The five entity types are: People, Devices, Organizations, Code and Agents. (definition source: the Jericho Forum)

[2] Remembering that risk will probably be bi-directional and both entities in a transaction will share the risk, though usually disproportionally.

About

Developing General Principles for Sovereign Identity

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published