This page represents the proposed structure of the ToIP Governance Metamodel. The purpose of the metamodel is to provide an overall template for ToIP-compatible governance frameworks from which the GSWG will then develop layer-specific templates. Each layer-specific template will be an instance of the metamodel that adds details such as:

• Standard Layer specific ToIP Roles at that layer (see the GSWG Process and Roles TF)
• Standard ToIP Layer specific ToIP Processes in which actors in those roles are engaged (see the GSWG Process and Roles TF)
• Recommended Policies for Requirements for those Processes (see the GSWG Process and Roles TF)
• Standard Risks Layer specific Risks against which a Risk Assessment should be performed (see the GSWG Trust Assurance TF)
• Standard Layer specific elements of a Trust Assurance Framework to address those risks (see the GSWG Trust Assurance TF)

The balance of this page defines the proposed metamodel and the requirements for each component. In these requirements, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" are to be interpreted as defined in RFC 2119.

All terms appearing in First Letter Caps on this page MUST be added to the ToIP Glossary tagged for inclusion in the ToIP Governance Glossary. (Note: the Concepts and Terminology WG has been briefed on this dependency.) The following terms have specific definitions used in this document:

Primary Document

The Primary Document is the "home page" for the Governance Framework (GF). It:

1. MUST have a DID (Decentralized Identifier) that serves as an identifier of the entire GF.
2. MUST have a unique DID URL (defined in the DID spec) to identify each specific version of the Primary Document.
3. MUST contain authoritative references to all other documents included in the GF, called the Controlled Documents.
4. MUST include Policies in the Revisions section stating how the Controlled Documents are governed by the Governing Authority.

Introduction

This section is a non-normative general introduction to the GF whose purpose is to orient first-time readers as to the overall context of the GF. It:

1. SHOULD have a reference to the ToIP Foundation, the ToIP Stack, and the specific version of the ToIP Governance Template from which it was derived.
2. MAY include an "Acknowledgements" section to acknowledge the contributors to the GF.

Primary Document

The Primary Document is the "home page" for the governance framework (GF). It:

1. MUST have a DID (Decentralized Identifier) that serves as an identifier of the entire GF.
2. MUST have a unique DID URL (defined in the DID spec) to identify each specific version of the Primary Document.
3. MUST contain authoritative references to all other documents included in the GF, called the Controlled Documents.
4. MUST include Policies in the Revisions section stating how the Controlled Documents are governed by the Governance Authority.

Introduction

This section is a non-normative general introduction to the GF whose purpose is to orient first-time readers as to the overall context of the GF. It:

...

...

Purpose

This is a short, clear statement of the overall purpose (mission) of the GF. It:

...

1. SHOULD clearly state the primary Governed Actors Roles in the Trust Community.

2. SHOULD state any other relevant stakeholders.

3. SHOULD state the primary types of interactions or transactions these Governed Actors Roles will be engaging in. 
4. SHOULD, if applicable, clearly state who and what are out of scope.

...

1. SHOULD serve as a guide to the development of any Requirements based Requirement based on each Principle ("Principles guide Policies").
2. SHOULD refer to existing Principles—whether defined by other ToIP GFs or by other sources—whenever possible.
3. SHOULD be referenced (along with any other relevant parts of the GF) in any Legal Agreement between Members and the Governance Governing Authority.
4. MUST NOT include requirements using RFC Requirements (e.g., using RFC 2119 terms) for which either human or machine conformance can be directly tested — those should be stated as Requirements elsewhere in the GF.

...

This section contains Requirements that apply to the GF as a whole and not just in the context of a particular Controlled Document. It:

1. SHOULD include the Policies thatRequirements that:
   1. Apply generally to governance of the entire Trust Community;
   2. Apply to the structure of the GF, e.g., what Controlled Documents must be specified by whom and applied to whom.
   3. Guide the development of more specific Policies within Requirements within the Controlled Documents.
2. SHOULD NOT include Policies that Requirements that apply only within the context of a specific category addressed by one of the Controlled Documents.
3. MUST include Responsible Use Policies that apply generally to infrastructure governed by the GF.
4. MUST include any Regulatory Compliance Policies that are not specified within particular Controlled Documents.
5. SHOULD include any Code of Conduct that applies broadly within the ecosystem, if any.

Revisions

This section contains the specific Policies Requirements governing revisions to the GF. It does not include Governance Policies for Requirements for the Governance Governing Authority or interdependent Governance interdependent Governing Authorities (those are should be defined in Controlled Documents in the Governance Requirements category). It:

1. MUST state the full legal identity and contact information for the primary Governance Authority or interdependent Governance Authorities.MUST include Policies specifying include Requirements specifying how any revisions to the GF are identified, will be developed, reviewed, and approved.
2. MUST include Requirements for how all new versions will be identified with a DID URL.
3. SHOULD include at least one public review period for any GF that will be available to the public.

...

This section applies to GFs that permit extensions via the incorporation of other GFs (a common feature especially of some ecosystem GFs). It:

...

Anchor
risk-assessment risk-assessment

Risk Assessment

This category includes links to an ISO 27005 (or compatible) risk assessment for managing risk. Controlled Documents in this category:

• SHOULD identify key risks that MAY negatively affect the achievement of the GF's purpose and objectives within its scopeScope.
• SHOULD include a Risk Assessment process output that provides an assessment of each key risk that the GF is designed to address and mitigate.
• SHOULD assess which Roles and Processes are vulnerable to each risk and how they are affected.
• MAY include a Risk Treatment Plan (RTP) for how identified risks are treated (e.g. mitigated, avoided, accepted or transferred); however, all risks that are to be mitigated by directives Mandates in the GF SHOULD be identified.

Trust Assurance and Certification

This category specifies Policies Trust Criteria for Governed Actors be Parties be held accountable against Requirements of the GF. Controlled Documents in this category:

1. SHOULD include a Trust Assurance Framework document that defines a scheme in which Roles Governed Parties assert compliance with the Policies of the GF and the mechanisms of assurance over those assertions.
2. SHOULD (if applicable) define the roles of Auditors and Auditor Accreditors and the directives governing their actions.
3. SHOULD (if applicable) define the roles of Certification Authorities of Certifying Parties and the Policies requirements governing their actions and relationships with the Governance the Governing Authority, Auditors, and Auditor Accreditors.
4. SHOULD (if applicable) include Policies requirements supporting the development, licensure, and usage of one or more Trust Marks.

...

These are the Requirements for governing the GF as a whole. Controlled Documents in this category:

1. MUST specify the primary Governance Authority or all interdependent Governance Authorities (if any).MUST include Controlled Documents that specify Governance Policies requirements for the primary Governance Governing Authority (or all interdependent Governance Authorities (Governing Authorities, or if applicable the Governing Entity), e.g., Charter, Bylaws, Operating Rules, etc.)
2. SHOULD address any antitrust Antitrust Policies, intellectual property rights Intellectual Property Rights (IPR) Policies, confidentiality Confidentiality Policies, or other Requirements for regulatory compliance policies under which the Trust Community Members agree to operate.
3. SHOULD include any Policies governing Requirements governing enforcement of the GF and how Dispute Resolution will be handled.

Business Requirements

These are the Polices and/or Rules requirements governing the business model(s) and business rules to be followed by the Trust Community. Controlled Documents in this category:

1. SHOULD clearly explain the exchange(s) of value within the Trust Community for which the GF is designed.
2. SHOULD define the Policies and/or Rules governing how and when these exchanges of value take place.
3. SHOULD define the Requirements for the use of any Rules EnginesDecision Support Systems.
4. SHOULD define how all Trust Community Members will be held accountable for their actions in these exchanges.
5. SHOULD define how the Governance the Governing Authority, Governing Entity, and the GF are sustainable under these RulesRequirements.

Technical Requirements

These are the Requirements governing technical interoperability. Controlled Documents in this category:

...

These are the Requirements governing information security, privacy, availability, confidentiality and processing integrity as these terms are defined by thethe Committee on the Sponsoring Organizations of the Treadway Commission - (COSO) Guidance on Internal Control - Integrated Framework. Controlled Documents in this category:

1. MUST specify how Members of the Trust Community will ensure the following categories of Information Trust:
   1. Information security
   2. Information privacy
   3. Information availability
   4. Information confidentiality
   5. Information processing integrity
2. SHOULD specify the relevant Information Trust Policies by reference to:
   1. ToIP Standard Specifications (TSS).
   2. Other regulatory or industry standards.
   3. GF-specific Policies.
   4. GF-compliant Decision Support Systems.
   5. Trust Community Member-specific Policies.GF-compliant Rules Engines

Inclusion, Equitability, and Accessibility Requirements

...

1. MUST specify how Members of the Trust Community will enable and promote inclusion, equitability, and accessibility by reference to:
   1. ToIP Standard Specifications (TSS).
   2. Other regulatory or industry standards/guidelines.
   3. GF-specific Policies.
   4. GF-compliant Decision Support Systems.
   5. Member-specific Policies.
   6. GF-compliant Rules Engines
2. SHOULD specifically address how the GF is designed to help bridge (or eliminate) the digital divide.

...

This category includes any legal agreements or contracts included in the GF. Controlled Documents in this category:

1. MUST include all specified legal agreements or contracts between Members and/or the Governance the Governing Authority.
2. SHOULD reference the Glossary document for all terms not defined withininternally to the agreement or contract.
3. MUST clearly state the Governed Actors Parties to whom these legal agreements apply.
4. MUST define or reference all relevant accountability and enforcement mechanisms.
5. SHOULD reference any other relevant Requirements in the balance of the GF.

...