This page is a preliminary draft is the home page of the ToIP Governance Architecture TSS (ToIP Standard Specification), a Draft Deliverable of the GSWG. It is intended for editing of the content of the TSS 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). To simplify editing, one subsection of the TSS, the ToIP governance metamodel, is being drafted on its own wiki page. 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 2119 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

All other terms in First Letter Capitals will be defined in the Governance Glossary to be published by the 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 TSS 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 that are trust decisions (especially those requiring transitive trust) based on GFs that include both human-readable auditable requirements and machine-verifiable. While Governance Frameworks can testable requirements. While GFs are expected to be specialized for all four layers of the ToIP Stackstack, certain interoperability 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 a single specificationone place. 

ToIP Governance

...

The purpose of the ToIP Governance Metamodel is to provide an overall template for ToIP-Compliant Governance Frameworks from which the GSWG will then develop layer-specific templates.

Metamodel Specification

The 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 ToIP-compliant GFs in one place, it is defined in a separate specification. All ToIP-compliant GFs MUST conform to the requirements of the ToIP Governance Metamodel SpecificationThe ToIP Governance Metamodel is currently defined on its own wiki page. The contents of that page will be incorporated into this section of the TSS.

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 Governance 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 globally-unique identifiers. 

1. The following MUST have

...

1. public DIDs

...

1. compliant with the ToIP Technology

...

1. Architecture Specification:
   1. Governing authorit(ies).
   2. Administering authority (if any).
   3. Primary document.
   4. All governed parties fulfilling roles

...

1. Governance Authority (GA)
2. Master Document
3. All Participants fulfilling Roles
   1. defined in the GF (e.g.,
   Issuers
   1. issuers,
   Stewards
   1. verifiers,
   Member Directories
   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 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 document.
   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 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 identified document
   2. If this DID URL includes a versionId parameter value, it MUST return the identified version of 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 publish a Digital Signature over The governing authority SHOULD publish a digital signature in its current DID document over the hash of the current version of its Master Document in its current DID Document.
2. The GA SHOULD issue VCs to all Participants verifying the GF role played by the Participant.
3. primary document.
4. 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 in a publicly-available credential registry as specified by the GF.
5. 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.
   GA SHOULD consider publishing Certification VCs to a Credential Registry and/or a Member Directory
   1. Issue those same verifiable credentials in 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 Webat a publicly-accessible URL.
2. MUST publish its DID URL in its DID Documenthave a DID.
3. MUST publish its Public Keys in its DID Document.
4. MUST publish its Public Service Endpoints in its DID Document.

Equity, Accessibility, and Inclusion Requirements

To support Transitive Trust, a publicly-available ToIP-Compliant Governance Framework:

1. the following in the corresponding DID document:
   1. An alsoKnownAs property whose value is the publicly-accessible URL.
   2. The public key(s) for the DID.
   3. All service endpoints specified in the GF.
2. SHOULD be localized into all human languages required by its trust communitySHOULD be published in all human languages spoken by its Trust Community.
3. SHOULD be accessible under the W3C Accessibility Guidelines.SHOULD include provisions for digital guardianship if applicable to its Trust Community.
4. SHOULD NOT discriminate against legitimate members of its Trust Community.

Technical Interoperability Requirements

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

1. MUST specify technical interoperability interoperability requirements using ToIP Standard Specification (TSS) specifications and recommendations whenever possible.
2. SHOULD specify any additional technical interoperability using a ToIP Interoperability Profile (TIP) whenever a TSS is not yet available requirements using publicly available open standard specifications or specification profiles.