This page is a preliminary draft is the home page of the ToIP Governance Architecture Specification, a Draft Deliverable of the GSWG. It is intended for editing of the content of the specification prior to moving the document into a GitHub repo (where we will convert it into a Markdown document following the process being developed by the Operations Team).  draft deliverable of the ToIP Governance Stack Working Group (GSWG). When this specification becomes a ToIP Approved Deliverable, it will be published as a PDF in the Tools and Specifications section of the ToIP website.

Contributors

To comply with the intellectual property rights protections in the charter of the ToIP Foundation (as required by all Joint Development Foundation projects hosted the Linux Foundation), all contributors to this Pre-Draft Deliverable draft deliverable MUST be current members of the ToIP Foundationand the Governance Stack Working Group (GSWG). The following contributors each certify that they meet this requirement:

• Drummond Reed, Evernym
• Scott Perry, Scott S. Perry CPA PLLC

Terminology

...

and Notation

The keywords In this document, 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 RFC 2119in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

All

...

terms appearing in bold on this page are listed in either the ToIP Core Glossary (based on the ToIP Core terms wiki) or the ToIP Governance Glossary (based on the GSWG terms wiki.) For more information see the Terms Wiki page of the Concepts and Terminology Working Group.

Purpose

The purpose of this Specification ToIP specification is to specify the standard requirements that apply to all ToIP-compatible governance frameworks (GFGFs) regardless of their layer in the ToIP Stackstack. 

Motivations

The overall purpose of the ToIP Governance Stack governance stack is to enable users of the ToIP Technology Stack technology stack to make Transitive Trust decisions based on Governance Frameworks trust decisions (especially those requiring transitive trust) based on GFs that include both Humanhuman-Auditable auditable requirements and Machinemachine-Testable Requirements. While Governance Frameworks testable requirements. While GFs are expected to be specialized for all four layers of the ToIP Stackstack, certain interoperability Requirements requirements apply to all ToIP-Compliant Governance Frameworks compliant GFs regardless of layer. The goal of this specification is to specify all of those interoperability requirements in one place.

ToIP Governance Metamodel Specification

The ToIP Governance Metamodel is a separate specification of the overall GSWG has developed a single metamodel for GF documents called the ToIP governance metamodel. Because it brings together all requirements for the structure and content of all ToIP-Compliant Governance Frameworkscompliant GFs in one place, it is defined in a separate specification. All ToIP-Compliant Governance Frameworks compliant GFs MUST conform to the requirements of the ToIP Governance Metamodel Specification.

Identification Requirements

To support Transitive Trust transitive trust across trust boundaries, ToIP-Compliant Governance Frameworks (GF) need to provide standard, persistent, verifiable identification of themselves, their Governing Authorit(ies), their Controlled Documents, and the ToIP Roles, Credentials, and other components they define.compliant GFs and their components and authorities need to be identified by persistent, verifiable identifiers. 

1. The following MUST have

...

1. public DIDs

...

1. compliant with the ToIP Technology

...

1. Architecture Specification:
   1. Governing
   Authority (GA)
2. Primary Document
3. 1. authorit(ies).
   2. Administering authority (if any).
   3. Primary document.
   4. All governed parties fulfilling roles
   All Participants fulfilling Roles
   1. defined in the GF (e.g.,
   Issuers
   1. issuers,
   Stewards
   1. verifiers,
   Trust Registries
   1. trust registries).
4. The following SHOULD have

...

1. public DIDs or DID URLs compliant with the ToIP Technology

...

1. Architecture Specification:
   1. Each
   Controlled Document
   1. controlled document.
   2. Each
   Policy
   1. policy, rule or other
   reference-able subcomponent of a Controlled Document
   1. normative subcomponent of a controlled document.
2. All

...

1. DIDs and DID URLs specified in this section are subject to the following policies:
   1. The DID for a
   governance framework
   1. GF document MUST remain the same for all versions of the
   same target
   1. document it identifies.
   2. A new versionId parameter value MUST be assigned for every version of the
   target
   1. identified document.
2. The GF MUST include one or more policies specifying the format for version identifier values and the process for assigning them.
   1. These policies
   The GA MUST publish a policy stating the format and assignment policies for its version identifier values.
   1. This policy SHOULD be the same for all versions of all documents in the GF.
   2. It is RECOMMENDED to use sequential integers for every version starting with "1".
   3. The use of minor version numbers (e.g., "1.1", "1.2", "1.3") is NOT RECOMMENDED.
3. A DID URL that includes a resource parameter with a value of true MUST return the target identified document directly.
   1. If this DID URL does not include a versionId parameter value, it MUST return the current version of the target identified document
   2. If this DID URL includes a versionId parameter value, it MUST return the identified version of the target the identified document.
   3. If this DID URL includes a versionId parameter value for a version that does not exist, it MUST return a "Resource Not Found" error.

Verification Requirements

To support Transitive Trustthe verifiability needed for transitive trust, the following verification requirements apply to ToIP-Compliant Governance Frameworks (GF)compliant GFs: 

1. The GA MUST The governing authority SHOULD publish in its current DID Document a Digital Signature current DID document a digital signature over the hash of the current version of its Primary Document primary document.
2. The GA SHOULD issue VCs to all Participants verifying the GF role played by the Participant.
3. The governing authority or administering authority SHOULD:
   1. Register the public DID and all authorized roles for a governed party in a trust registry.
   2. Issue verifiable credentials to all governed parties serving in a role defined by the GF.
   3. Issue those same verifiable credentials to a publicly-available credential registry as specified by the GF.
4. If the GF includes certification policies, the qualified certifying parties SHOULD:
   1. Issue certification credentials to governed parties
   If the GA specifies certification policies, Certification Authorities SHOULD issue Certification VCs to Holders
   1. as directed by the GF.
   The GA or Certification Authorities SHOULD consider publishing either or both:
   1. Certification VCs to a Credential Registry.
   2. Role DIDs to a Trust RegistryIssue those same verifiable credentials to a publicly-available credential registry as specified by the GF.

Transparency Requirements

To support Transitive Trustthe transparency needed for transitive trust, a publicly-available ToIP-Compliant Governance Frameworkcompliant GF: 

1. MUST be published on the Web.
2. MUST publish its DID URL in its DID Documentdocument.
3. MUST publish its Public Keys in its DID Documentpublic keys in its DID document.
4. MUST publish its Public Service Endpoints public service endpoints in its DID Documentdocument.
5. SHOULD be published in translated into all human languages spoken within its Trust Community trust community.
6. SHOULD be accessible under the W3C Accessibility Guidelines.

...

To support the interoperability necessary needed for Transitive Trust transitive trust, a publicly-available ToIP-Compliant Governance Frameworkcompliant GF:

1. MUST specify technical interoperability using ToIP Specifications and ToIP Recommendations specifications and recommendations whenever possible.
2. SHOULD specify any additional technical interoperability requirements using additional publicly available open standard Specifications standard specifications or specification profiles if needed.