This page represents the proposed structure of the ToIP Governance Metamodel. The purpose of the metamodel is the home page for the ToIP Governance Metamodel Specification. Please see the Governance Metamodel Companion Guide for a "user's guide" to this specification.  The purpose of this ToIP specification is to provide an overall template for ToIP-compatible governance compatible governance frameworks from which the GSWG will then develop layer-specific templates are derived.  Each layer-specific template will be an instance of the metamodel that adds MUST comply with this specification.  They SHOULD add details such as:

• Layer-specific ToIP roles.
• Layer-specific ToIP processes
• Standard ToIP Roles at that layer (see the GSWG Process and Roles TF)
• Standard ToIP Processes in which actors in those roles are engaged (see the GSWG Process and Roles TF)
• Recommended Requirements for those Processes (see the GSWG Process and Roles TF)
• engaged.
• Layer-specific risks against which a risk assessment Standard Risks against which a Risk Assessment should be performed (see the GSWG Trust Assurance TF) Risk Assessment Worksheet Template).
• Layer-specific Standard elements of a Trust Assurance Framework trust assurance framework to address those risks  risks (see the GSWG Trust Assurance TFand Certification Controlled Document Template).

Notation and Keywords

All terms appearing in First Letter Caps in bold on this page MUST be added to are listed in either the ToIP Glossary tagged for inclusion in the Core Glossary (based on the ToIP Core terms wiki) or the ToIP Governance Glossary. (Note: (based on the GSWG terms wiki.) For more information see the Terms Wiki page of the Concepts and Terminology WG has been briefed on this dependency.).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Primary Document

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

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

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 reference any external websites, white papers, or other helpful background materials.
2. SHOULD have a reference to the ToIP the ToIP Foundation, the ToIP Stackthe ToIP stack, and the specific version of the ToIP Governance Template from which it was derived ToIP governance template upon which the GF is based (if any).
3. MAY include an "Acknowledgements" section to acknowledge the citing contributors to the GF.

...

Terminology and Notation

This section asserts the terminology conventions used in the GF. It:

1. MUST explicitly specify the use of

...

1. the ToIP Governance Requirements Glossary (see below)

...

1. .
2. MUST reference the GF Glossary

...

1.  controlled document for all other terms (see the Controlled Documents section).
2. MAY specify that terms specific to one controlled document are defined in that controlled document.
3. MUST specify that all RFC 2119 keywords used with their RFC 2119 meanings are CAPITALIZED.
4. SHOULD specify any other formatting, layout, or

...

1. notation conventions used in the

...

1. primary document and/or controlled documents.

ToIP Governance Requirements Glossary

...

• Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword.
• Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword.
• Options are Requirements that use a MAY or OPTIONAL keyword.

...

• Rules are Machine-Testable Requirements that are written in a Machine-Readable language and can be processed by a Rules Engine. They are expressed in a structured rules language as specified by the GF.

...

• Policies are Human-Auditable Requirements written using standard conformance terminology. For Policies used in ToIP Governance Frameworks, the standard terminology is  RFC 2119 keywords. Note that all RFC 2119 keywords have weight from an auditing perspective. An implementer MUST explain why a SHOULD or RECOMMENDED requirement was not implemented and SHOULD explain why a MAY requirement was implemented.
• Processes are Human-Auditable Requirements that specify actions and methods to achieve Policy objectives.
• Practices are activities within Processes to achieve Process requirements.

Localization

This section covers the policies governing languages and translations for the GF. It:

1. MUST specify the official language or languages for the GF.
2. SHOULD use an IETF BCP 47 language tag to identify each official language.
3. SHOULD specify and provide links to all official translations of the GF.
4. SHOULD specify the policies and/or rules governing the production of translations

...

1. .

Governing Authority

This section asserts the legal authority for governance of the GF.

...

1. For

...

1. the governing authority (or each interdependent governing authority), this section:
   
   1. MUST state the full legal identity including

...

1. 1. jurisdiction(s).
   2. MUST state the DID.
   3. SHOULD

...

1. 1. include the Legal Entity Identifier (LEI) of the governing authority as defined by the Global Legal Entity Foundation (GLEIF).
   2. MUST provide contact information for

...

1. 1. official communication with the governing authority.
   2. SHOULD provide contact information for official

...

1. 1. persons acting on behalf of the governing authority.
2. For the GF itself, this section:
   1. SHOULD provide the URL for a publicly-accessible

...

1. 1. website dedicated to the GF ("GF website").

...

1. The GF website SHOULD include:

1. 1. HTML versions of all documents in the GF.
   2. PDF versions of all documents in the GF.
   3. Highlighted links to the Governance Requirements

...

1. 1. controlled document(s) that specify how

...

1. 1. the governing authority itself is governed.
   2. If applicable, a primary trust mark displayed prominently on the home page and in the header of every other page.

Administering Authority

...

This section is only REQUIRED if the administering authority for the GF is different from the

...

governing authority. It:

1. MUST state the full legal identity of

...

1. the administering authority.
   
   1. SHOULD

...

1. 1. provide the Legal Entity Identifier (LEI) of the administering authority as defined by the Global Legal Entity Foundation (GLEIF).
2. MUST provide contact information for

...

1. official communication with the administering authority.
   1. SHOULD provide contact information for official

...

1. 1. contacts acting on behalf of the administering authority.
2. MUST clearly define the role of the administering authority i.e., what administrative authority the governing authority delegates to the administering authority and what decisions and processes remain the responsibility of the governing authority.

Purpose

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

1. SHOULD be as short and concise as possible—ideally one sentence, or only a few sentencesat most one paragraph.

Scope

This is a statement of what is in and out of scope of for the GF. It:

1. SHOULD clearly state the primary Governed Roles in the Trust Communitygoverned roles in the trust community.

2. SHOULD state any other relevant stakeholders.

3. SHOULD state the primary types of interactions or transactions these Governed Roles will be engaging in. , transactions, or processes in which the actors serving these roles will be engaged.
4. SHOULD state what kind of artifacts will be governed.
5. SHOULD, if applicable, clearly state who and what are is out of scope.

Objectives

This section states the high-level outcomes desired by the Trust Community the trust community through its adoption of the Governance FrameworkGF. It:

1. SHOULD specify tangible, achievable results (e.g. SMART criteria and Fit-for-purpose Purpose criteria).SHOULD specify the intended overall outcomes to be produced by conformance with the Requirements in the GF.
2. MUST only contain outcomes over which the GF has the authority and mechanisms to achieve within its Scopescope.
3. MUST be consistent with its Principlesthe principles of the GF (below).

Principles

This section states the Principles principles by which all members of the Trust Community have agreed the trust community agree to abide. It:

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

General Requirements

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

1. SHOULD include the Requirements that requirements that:
   1. Apply generally  Generally apply to governance of the entire Trust Community;entire trust community.
   2. Apply to the structure of the GF , (e.g., what Controlled Documents must be specified by whom and applied to whomwho is responsible for which controlled documents).
   3. Guide the development of more specific Requirements within the Controlled Documents requirements within the controlled documents.
2. SHOULD NOT include Requirements that requirements that apply only within the context of a specific category addressed by one of the Controlled Documentsthe controlled documents.
3. MUST include Responsible Use Policies any responsible use policies that apply generally to infrastructure governed by the GF.
4. MUST include any Regulatory Compliance Policies that regulatory compliance policies that are not specified within particular Controlled Documents controlled documents.
5. SHOULD include any a Code of Conduct that applies broadly within the ecosystem, if any (if not included in the legal documents) that applies to all trust community members.

Revisions

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

1. MUST include Requirements specifying how requirements specifying:
   1. How any revisions to the GF will be developed, reviewed, and approved.
   MUST include Requirements for how all
   1. How any new versions will be uniquely identified with a DID URL.
2. SHOULD include at least one public review period for any publicly-available GF that will be available to the public.
3. SHOULD NOT include any other types of requirements that pertain to governance of the governing authorit(ies). Those should be defined in controlled documents in the Governance Requirements category.

Extensions

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

1. MUST state whether the GF can be extended.
2. MUST specify the requirements an Extension Governance Framework extension GF must meet in order to be approved.
3. MUST specify the process for an Extension Governance Framework to by which an extension GF can be approved.
4. MUST define an authoritative mechanism requirements for registration, activation, and activation deactivation of an approved Extension Governance Framework extension GF.
5. MUST define the requirements for notification of the Trust Community about an approved Extension Governance Frameworkof trust community members about activation or deactivation of an approved extension GF.

Schedule of Controlled Documents 

This is a listing of all Controlled Documents in If controlled documents are included as part of the GF, this section MUST contain an authoritative list of all controlled documents in the GF. It:

1. MUST include authoritative references to all Controlled Documents all controlled documents in the GF.
2. MUST identify the exact version of each Controlled Document with each controlled document with a unique, permanent DID or DID URL.
3. SHOULD include a Web link to each Controlled Document in the Web version of each controlled documents on the GF website.
4. SHOULD include a brief description of the purpose and scope of each Controlled Document to each controlled document to make it easy for readers to navigate the GF.

Controlled Documents

Each Controlled Document Each controlled document covers a specific area of the GF. The following sections are categories of Controlled Documents where of controlled documents where each category MAY include zero or more Controlled Documentscontain more than one document. Most (but not all) categories are OPTIONAL.

Glossary

The Glossary This category provides a common basis for terminology. It:

1. SHOULD be a single Controlled Document (even if it is organized by categories or other heuristics)single controlled document for each applicable language.
2. SHOULD provide a common reference for all possibly ambiguous terms used throughout the GF.
3. SHOULD reference the ToIP Glossary—or tagged subset(s) of the ToIP Glossary—for all terms defined therethe ToIP Core Glossary, other relevant ToIP glossary or GF-specific glossary for all relevant terms.
4. SHOULD conform to standard requirements for  for a glossary, i.e., list all terms alphabetically (by language) for easy reference.
5. MAY tag terms by category or usage.MAY specify that terms specific to one Controlled Document are defined in that Controlled Document.

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  Controlled documents in this category:

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

Trust Assurance and Certification

This category specifies Trust Criteria for Governed Parties trust criteria for governed parties be held accountable against Requirements of requirements of the GF. Controlled Documents in documents in this category:

1. SHOULD include a Trust Assurance Framework document that trust assurance framework that defines a scheme in which Governed Parties which governed parties assert compliance with the Policies of policies of the GF and the mechanisms of assurance over those assertions.
2. SHOULD (if applicable) define the roles of Auditors auditors and Auditor Accreditors auditor accreditors and the directives policies governing their actions.
3. SHOULD (if applicable) define the roles of Certifying Parties of certifying parties and the requirements governing policies governing their actions and relationships with the Governing Authority, Auditors, and Auditor Accreditorsthe governing authority, auditors and auditor accreditors.
4. SHOULD (if applicable) include requirements supporting  supporting the development, licensure, and usage of one or more Trust Marks trust marks.

Governance Requirements

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

1. MUST include Controlled Documents that specify Governance governance requirements for the primary Governing Authority (or all interdependent Governing Authorities, or if applicable the Governing Entity), e.g., Charter, Bylaws, Operating Rules, etc., and so on) for:
   1. The governing authority (or all interdependent governing authorities).
   2. The administering authority, if applicable. 
2. SHOULD address any Antitrust Policies, Intellectual Property Rights policies required for antitrust, intellectual property rights (IPR) Policies, Confidentiality Policies, confidentiality, responsible use, or other Requirements requirements for regulatory compliance under which the Trust Community Members agree to operatethat apply to the trust community members.
3. SHOULD include any Requirements requirements governing enforcement of the GF and how Dispute Resolution dispute resolution will be handled.

Business Requirements

These are the requirements governing  governing the business model(s) and business rules to be followed by the Trust Community. Controlled Documents in trust community. Controlled documents in this category:

1. SHOULD clearly explain the any exchange(s) of value within the Trust Community for which between trust community members governed by the GF is designed.
2. SHOULD define the Policies policies and/or Rules governing rules governing how and when these exchanges of value take place.
3. SHOULD define the Requirements for requirements for the use of any Rules Engines or Decision Support Systems decision support systems.
4. SHOULD define how all Trust Community Members trust community members will be held accountable for their actions in these exchanges.
5. SHOULD define how the Governing Authority, Governing Entity, and the governing authority, administering authority, and the GF are sustainable under these Requirements requirements.

Technical Requirements

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

1. MUST specify how Members of the Trust Community how trust community members will interoperate technically using the ToIP Technology Stack by reference to ToIP Standard Specifications (TSS).
2. SHOULD (if necessary) reference one or more specific ToIP Interoperability Profiles (TIPs).
3. the ToIP technology stack by reference to any relevant ToIP specifications and recommendations.
4. SHOULD include any additional specifications and/or specification profiles that are specific to the technical interoperability within this trust community.
5. SHOULD include references one or more glossaries (see Glossary section) as needed.
6. SHOULD reference any test suites or other testing requirementsSHOULD specify any Specifications that are specific to this Trust Community.

Information Trust Requirements

These are the Requirements governing information security, privacy, availability, confidentiality and processing integrity as these terms are defined by the requirements in the five categories of trust service criteria defined by the American Institute of Certified Public Accountants (AICPA) Assurance Services Executive Committee (ASEC). These can be addressed by implementing internal controls as defined by the Committee on the Sponsoring Organizations of the Treadway Commission (COSO) Guidance on Internal Control. Controlled Documents in documents in this category:

1. MUST specify how Members of the Trust Community will ensure the following categories of Information Trustthe baseline requirements for governed parties with regard to:
   1. Information security
   2. Information privacyavailability
   3. Information availabilityprocessing integrity
   4. Information confidentiality
   5. Information processing integrityprivacy
2. SHOULD specify the relevant Information Trust Policies by information trust policies by reference to:
   1. ToIP Standard Specifications (TSS) specifications and recommendations.
   2. Other regulatory or industry standards.
   3. GF-specific Policies policies.
   4. GF-compliant Rules Engines and Decision Support Systems decision support systems.
   5. Trust Community Membercommunity member-specific Policies policies.

Inclusion, Equitability, and Accessibility Requirements

These are the Policies governing the requirements governing how the GF enables fair and equal access to all. Controlled Documents in documents in this category:

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

Legal Agreements

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

1. MUST include all specified legal agreements or contracts between Members and/or the Governing Authoritybetween trust community members.
2. SHOULD reference the Glossary GF glossary document(s) for all terms not defined internally to the legal agreement or contract.
3. MUST clearly state the Governed Parties to governed 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 requirements in the balance of the GF.

...