---
tags: TOIP, TOIP layers, Governance Frameworks, design principles
---
# Governance Stack Design principles
- Authors: Drummond Reed, [Victor Syntez]([e-mail])
- Deliverable Type: *Recommendation - Design Principle*
- Status: [PROPOSED](/README.md#proposed)
- Since: 2020-11-04
- Status Note: Draft
- Supersedes: N/A
- Start Date: 2020-11-04
- Tags: (see ../../../tags.md)

[toc]

## Summary
This document is a template for ToIP Governance Stack Design Principles that might be used throughout all or any of the Trust Over IP Layers. It is based on several works:
1. Laws of Identity by [Kim Cameron](https://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf)
2. Presidio Principles by [WEF](http://www3.weforum.org/docs/WEF_Presidio_Principles_2020.pdf)
3. The Principles of SSI by Sovrin [(current version)](https://docs.google.com/document/d/1GhcLeZEujX9h5gqrFNP-C1dMrS71EdCY4Uc1hGQbqI0/edit#heading=h.jkpp8prq58uk)
4. Guiding Principles of the [PCTF](https://diacc.ca/wp-content/uploads/2020/09/PCTF-Model-Final-Recommendation_V1.0.pdf)
5. 7 Principles of Universal [Design](http://universaldesign.ie/What-is-Universal-Design/The-7-Principles/)

## Motivation

We see our task for creating this document in outlining ToIP Governance Stack design principles. These principles are needed for creating governing documents that will enable business, legal and social trust between entities engaged in any activity related to digitally verified credentials. By defining these principles we hope to assist in creating governance documents for user-centric, secure, accountable, interoperable, transparent and accessible utilities, protocols, applications, and ecosystems around verified credentials. Our goal lies in proposing not only the content of governance frameworks but also the way, how this content is organized for the future reading and use by humans and/or machines. We would like to highlight that these design principles are recomendations on **HOW** to create governing documents and **WHAT** these governing documents will contain.

## Scope
This document serves to provide an opportunity to discuss how further mentioned Design Principles MUST or SHOULD, or MAY be applicable on all or any layer of TOIP Governance Stack.

In many standards track documents words MUST, SHOULD, and MAY are used to signify the requirements in the specification. This matrix use these words according to IETF [RFC2119](https://tools.ietf.org/html/rfc2119).

Briefly describe the scope of this document – how it presents the architecture of this particular enabler.  Include an explanation of how this architecture relates to Organization Name activity.  If it adds clarity, also describe what is not in the scope of this architecture.  DELETE THIS COMMENT

## Important concepts
* **Verified Credential**. A Credential that includes a Proof from the Issuer. Typically this proof is in the form of a digital signature. In Sovrin Infrastructure, a Verifiable Credential uses Zero Knowledge Proofs by default and can usually be verified by the Issuer Public Key stored in the Credential Definition on the Sovrin Ledger. Based on the definition provided by the W3C Verifiable Claims Working Group. (from Sovrin [glossary](https://github.com/trustoverip/concepts-and-terminology-wg/blob/master/submissions/sovrin/Governance_Framework.md)).
* **Credential Verification** is the evaluation of whether a Verifiable Credential or Verifiable Presentation authentically and accurately represents the Issuer or Presenter. This includes verification that the proof is satisfied (normally via cryptographic validation), confirmation the Credential or Presentation is valid (e.g., is not suspended, revoked, or expired), and that the Credential or Presentation conforms to relevant specifications and/or standards. (from [PCTF Credential](https://diacc.ca/wp-content/uploads/2020/09/PCTF-Credentials-Relationships-Attributes-Component-Overview-Final-Recommendation-V1.0-1.pdf))
* **Governance Framework** - The set of business, legal, and technical definitions, policies, specifications, and contracts by which the members of a Trust Community agree to be governed in order to achieve their desired Levels of Assurance. Typically divided into a Master Document and a set of Controlled Documents. A Governance Framework is itself governed by a Governance Authority. A Governance Framework is also known as a Trust Framework. (from Sovrin [glossary](https://github.com/trustoverip/concepts-and-terminology-wg/blob/master/submissions/sovrin/Governance_Framework.md))

* **Design** - A design is a plan or specification for the construction of an object or system or for the implementation of an activity or process, or the result of that plan or specification in the form of a prototype, product or process.

## Trust Over IP Stack Governance Frameworks description (from [TOIP Stack](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0289-toip-stack/README.md))
The ToIP stack does not define specific governance frameworks. Rather it is a metamodel for how to design and implement digital governance frameworks that can be universally referenced, understood, and consumed in order to facilitate transitive trust online. The ToIP governance stack is designed to be compatible with—and an implementation vehicle for—national governance frameworks as well as for regional and local governance frameworks of all kinds.


**TL4:** **Ecosystem Governance Frameworks**. Layer Four is where humans will directly experience the ToIP Governance Stack—specifically the trust marks and policy promises of ecosystem governance frameworks. These specify the purpose, principles, and policies that apply to all governance authorities and governance frameworks operating within that ecosystem—at all four levels of the ToIP stack. Any group of issuers who want to standardize, strengthen, and scale the credentials they offer can join together under the auspices of a sponsoring authority to craft a governance framework. No matter the form of the organization—government, consortia, association, cooperative—the purpose is the same: define the business, legal, and technical rules under which the members agree to operate in order to achieve trust.

**TL3:** **Credential Governance Frameworks**. This is the layer where governance frameworks become a critical component for interoperability and scalability of digital trust ecosystems. Credential governance frameworks can be used to specify:
* Credential schema definitions.
* The rules governing who can serve as the authoritative issuers for those credentials.
* The policies those issuers must follow to issue and revoke those credentials.
* Applicable business models, liability frameworks, and insurance models.

**TL2:** **Provider Governance Frameworks**. At Layer Two, governance is needed primarily to establish interoperability testing and certification requirements, including security, privacy, data protection, for the following roles: Hardware Developer, Software Developer, Agencies.

**TL1:** **Utility Governance Framework**. A Layer One public utility may choose any governance model suited to the the constraints of its business model, legal model, and technical architecture. All ToIP architecture requires is that the governance model conform to the requirements of the ToIP Governance Stack to support both interoperability and transitive trust. This includes transparent identification of the governance authority, the governance framework, and participant nodes or operators; transparent discovery of nodes and/or service endpoints; and transparent security, privacy, data protection, and other operational policies.

## Design Goals
For designing this document we will try to use 4 principles of universal design. Our goal is to make this document perceptible for future use outside of the Trust Over IP community. For this we seek to implement below principles:
1. Equitable Use. This document is useful and marketable to people with diverse abilities and backgrounds.
2. Flexibility in Use. This document accommodates a wide range of individual preferences and abilities.
3. Perceptible Information. This document communicates necessary information effectively to the user.
4. Size and Format for Read and Use. Appropriate size and format is provided for reading, manipulation, and use keeping in mind diversity of knowledge about verified credentials among future consumers of the document.

## List of Principles
Principles are mentioned without any particular order. Below you will find principles and their meaning.
### 1. Interoperability and Portability
- Capabilities to port data between interoperable systems or parts of a system.
- Capabilities to have access to information sufficient to facilitate system interoperability.
- Capability to use various verifiable data structures, wallets, or cloud service providers to manage and use verified credentials.
- Ensuring users' identification/authentication portability and interoperability, allowing for separating the data from the application and for the user to have the right to decide where to store theidentification/authentication data.
- Promoting different identity providers offering different features. VC systems must be polycentric and also polymorphic.
### 2. Equity and Inclusion
- Identification and mitigation of legal, procedural, and social barriers in VC systems, with special attention to groups who may be at risk of exclusion for cultural, political or other reasons.
- VC systems should not be used as a tool for discrimination or infringement on individual or collective rights.
- Hardware and software should be common and affordable while allowing for sufficient speed and security.
- VC systems should not exclude or discriminate against any groups within its governance scope.\
- VC systems need to be easy to access and simple to understand.
### 3. Security and Privacy.
- Data protection in accordance with internationally recognized technical security standards.
- VC systmes should have safeguards against tampering, VC theft, data misuse.
- Establishing tools for end-to-end encryption.
- Verification that operations have been completed and confirmed in accordance with the system's rules.
- Security of VC at rest and during exchanges.
- Protection of VC security and privacy through VC system design. Information should be protected from improper and unauthorized use by default, through both technical standards and preventative business practices.
### 4. Transparency in governance and operation
- Capability to assess and verify the information necessary to understand the incentives, rules, policies, and algorythms under which VC systems participants operate.
- Availability of the governing documents among them principles, policies, regulations, etc.
- Availability of the system performance metrics and critical points in service delivery system.
- Open publication of institutional mandates, policies, and regulations.
### 5. User control and consent. *Explicit and Informed Consent*
- Empower VC systems participant to exert their control over VC by employing and/or delegating to the agents and guardians of their choice, including individuals, organizations, devices, and software.
- Necessity to allow for explicit and informed consent from VC system participatns.
- The VC system must be designed to put the user in control - of what data from her or his VC is used and released.
- The system must inform the participant whether his or her VC will be tracked.
- The system should reinforce the sense that the participant is in control regardless of context. It should support user consent in enterprice as well as consumer environment.
### 6. Rights and Obligations.
~~~
Every user of the GF Should have Rights and Obligations.
~~~
- Transparency around the roles and responsibilites of VC system participants.
- Clear description of potential risks and benefits of a VC system.
- Clear specification of the terms and conditions governing VC system participants relationship.
### 7. Independent audit and assessment.
- Creation of the independent oversight body (e.g. a national privacy commission) with appropriate powers to protect VC system participants against inappropriate access and use of their data by third parties for commercial surveillance or profiling without informed consent or legimate purpose.
- Ecosystem-wide trust frameworks must establish and regulate governance arrangements for VC systems.
- VC should be independantly monitored for effeciency, transparency, exclusion, misuse, etc.
- Disputes regarding VC and their use that are not satisfactorily resolved by the providers should be subject to rapid and low-cost review by independent administrative and judicial authorities with authority to provide suitable redress.
- On-going, functionally independent, and third-party assessments provide one way to ensure that ecosystem participants adhere to the Trust Framework requirements.
### 8. Human Integration for continuous feedback and consistent experience.
- Public and private stakeholders should be engaged throghout planning and implementation.
- The VC system should extend to and integrate the human user.
- Achievement of very high levels of reliability by continuous user testing.
- Maximization of usability and consistency of VC user experience.
- Capability to opt-out of not participation in the VC system that doesn’t treat data in accordance with internationally recognized governance and data protection standards.
- Necessity for VC players to be flexible, scalable, and meet the needs and concerns of people (users) and relying parties (e.g., public agencies and private companies).
### 9. Minimal Disclosure for a Constrained Use.
- VC system should disclose the least amount of identifying information and limit its use.
- VC system should disclose exactly the amount of information necessary for each interaction between only the required parties in the context of the service provided, in compliance with the applicable data protection rules.
- VC system should not disclose necessary personal information unless otherwise required.
- VC system should accept users who want to preserve high level of privacy and anonymity, e.g. by using pseudonym and/or other privacy-by-design mechanisms, associated in a trustworthy manner to their government-issued/recognized ID.
- VC system should provide a possibility to revoke consent for future data collection system and support user's "right to be forgotten"
### 10. Open and Automated systems.
- Maintance of VC system neutrality, openness and innovation.
- VC system should use open standarts and applicable open practices.
- Avoidance of vendor or technology lock-in.
- Enabling open design principles for market-based competition and innovation.
- VC system should provide capabilities for users to be subject to automated-decision making.

## Synopsis
~~~
a brief summary or general survey of something.
~~~

## Relevance
We consider that there is a need in documents highlighting not only the very principles of verified credentials governance but also organizing these principles in clear, consise, and appealing way. Therefore we wish that this document will create an emotional feedback from its consumers. We need to remember that for a product to be accepted by corresponding public it has to be of high quality and it has to be wrapped appropriately.

Explain the positioning of each principle against the overarching goals of this proposal.  How / where would they be used (example Use cases or industry sectors).
DELETE THIS COMMENT

## Trade-offs

Provide an assessment of the ramifications of including and/or excluding each principle in a solution.
DELETE THIS COMMENT