This is the home page of the ToIP Governance Architecture Specification, a 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 draft deliverable MUST be current members of the ToIP Foundation. The following contributors each certify that they meet this requirement:

...

The keywords "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.

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 ToIP specification is to specify the standard requirements that apply to all ToIP-compatible governance frameworks (GFs) regardless of their layer in the ToIP stack. 

...

To support transitive trust across trust boundaries, ToIP-compliant GFs and their components and authorities need to be identified by persistent, verifiable globally-unique identifiers. 

1. The following MUST have public DIDs compliant with the ToIP Technology Architecture Specification:
   1. Governing authorit(ies).
   2. Administering authority (if any).
   3. Primary document.
   4. All governed parties fulfilling roles defined in the GF (e.g., issuers, verifiers, trust registries).
2. The following SHOULD have public DIDs or DID URLs compliant with the ToIP Technology Architecture Specification:
   1. Each controlled document.
   2. Each policy, rule or other normative subcomponent of a controlled document.
3. All 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 document it identifies.
   2. A new versionId parameter value MUST be assigned for every version of the identified document.
4. 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.
5. A DID URL that includes a resource parameter with a value of true MUST return the 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.

...