§ ToIP Trust Registry Protocol Specification
+Specification Status: v2.0 Draft
+Latest Draft:
+https://github.com/trustoverip/tswg-trust-registry-protocol
+Editors:
+ +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 by the Linux Foundation), all contributors in any capacity to this Draft Deliverable MUST be current members of the ToIP Foundation. The following contributors each certify that they meet this requirement:
+-
+
- Antti +
- Andor +
- Jacques Latour, CIRA +
- Christine Martin, Continuum Loop +
-
+
+
-
+
- Participate: +
- GitHub repo +
- Commit history +
+
§ Status of This Memo
+This document contains a specification for the ToIP Trust Registry Protocol.
+Information about the current status of this document, any errata, and how to provide feedback on it, may be obtained at +https://github.com/trustoverip/tswg-trust-registry-protocol.
+§ Copyright Notice
+This specification is subject to the OWF Contributor License Agreement 1.0 - Copyright available at +https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owf-contributor-license-agreement-1-0-copyright.
+If source code is included in the specification, that code is subject to the Apache 2.0 license unless otherwise marked. In the case of any conflict or confusion within this specification between the OWF Contributor License and the designated source code license, the terms of the OWF Contributor License shall apply.
+These terms are inherited from the Technical Stack Working Group at the Trust over IP Foundation. Working Group Charter
+§ Terms of Use
+These materials are made available under and are subject to the OWF CLA 1.0 - Copyright & Patent license. Any source code is made available under the Apache 2.0 license.
+THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series (“ToIP”), and its members and contributors (each of ToIP, its members and contributors, a “ToIP Party”) expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. +IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+§ RFC 2119
+The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and to ensure maximal efficiency in operation. IETF has been operating since the advent of the Internet using a Request for Comments (RFC) to convey “current best practice” to those organizations seeking its guidance for conformance purposes.
+The IETF uses RFC 2119 to define keywords for use in RFC documents; these keywords are used to signify applicability requirements. ToIP has adapted the IETF RFC 2119 for use in the
The RFC 2119 keyword definitions and interpretation have been adopted. Those users who follow these guidelines SHOULD incorporate the following phrase near the beginning of their document: +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
+RFC 2119 defines these keywords as follows:
+-
+
- MUST: This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification. +
- MUST NOT: This phrase, or the phrase “SHALL NOT”, means that the definition is an absolute prohibition of the specification. +
- SHOULD: This word, or the adjective “RECOMMENDED”, means that there MAY exist valid reasons in particular circumstances to ignore a particular item, but the full implications MUST be understood and carefully weighed before choosing a different course. +
- SHOULD NOT: This phrase, or the phrase “NOT RECOMMENDED” means that there MAY exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications SHOULD be understood, and the case carefully weighed before implementing any behavior described with this label. +
- MAY: This word, or the adjective “OPTIONAL”, means that an item is truly optional. One vendor MAY choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor MAY omit the same item. +
Requirements include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in RFC 2119.
+-
+
- Mandatories 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. +
An implementation which does not include a particular option MUST be prepared to interoperate with other implementations which include the option, recognizing the potential for reduced functionality. As well, implementations which include a particular option MUST be prepared to interoperate with implementations which do not include the option and the subsequent lack of function the feature provides.
+§ Revision History
+The following key revisions have been made to this specification:
+-
+
- JAN2023
+
-
+
- Created a clean repository to accomplish several goals:
+
-
+
- Clearly delineate v1.0 and v2.0 - move from the Trust Registry Task Force repository to Trust Registry Protocol v2 repository. +clean repository. +
- Use Trust Over IP Specification Template - applied the
spec-up
template from the Trust Over IP Specification Template repository.
+
+
+
+ - Created a clean repository to accomplish several goals:
+
§ Introduction
+Fancy introduction!
+§ Scope
+The Trust Registry Protocol serves to provide a simple interface to the plethora of systems that contain answers that are required to make trust decisions.
+The TRP does not:
+-
+
- create a trust registry - it allows (read-only) access to a system-of-record that has the data needed to generate answers that a trust registry provides. +
- create new information - the Create, Update, and Delete of CRUD are not supported. Systems-of-record perform the full CRUD operations. The protocol provides a simple and consistent way of retrieving information from a system. +
- implement governance - the system-of-record that supports the TRP may have technical ways of doing this, supported by manual operations. Regardless, the TRP has no opinion on how governance is implemented - just that the information retrieved complies with the stated EGF. +
- make decisions - the TRP serves up data that are inputs to trust decisions. +
- assign Roles or Rights, though a consuming system may take information that is received via the TRP and assign these. +
§ Purpose
+The purpose of this ToIP specification is to define a standard interoperable protocol for interacting with a global web of peer trust registries, each of which can answer queries about whether a particular party is trusted and authorized, to perform a particular action in a particular digital trust ecosystem (defined under an EGF), as well as which peer trust registries trust each other.
+§ Motivations
+A core role within Layer 4 of the ToIP stack is a trust registry (previously known as a member directory). This is a network service that enables the governing authority for an ecosystem governance framework (EGF) to specify what governed parties are authorized to perform what actions under the EGF. For example:
+-
+
- Which entities are authorized to take what actions under an EGF.
+
-
+
- e.g. is an entity authorized to “issue” a “driver license”; is an entity authorized to “sign” data. +
+ - What other trust registries are recognized by this particular trust registry. +
As with all layers of the ToIP stack, the purpose of a ToIP specification is to enable the technical interoperability necessary to support transitive trust within and between different trust communities implementing the ToIP stack. In this case, the desired interoperability outcome is a common protocol that works between any number of decentralized peer trust registries operated by independent governing authorities representing multiple legal and business jurisdictions. One specific example of this need is the digital trust ecosystem defined by the Interoperability Working Group for Good Health Pass (GHP).
+A Registry of Registries (RoR), is a form of trust registry that primarily serves information about other trust registries.
+-
+
- What other governing authorities are known to the RoR. +
- Which trust registry are known to be authoritative for particular actions. Examples:
+
-
+
- Which trust registry is known to issue university diplomas for a particular jurisdiction? +
+
-
+
- Which trust registry is known to manage a list of professionals (e.g. CPAs, lawyers, engineers) that have particular signing rights (authorizations)? +
-
+
- Which trust registry are known to operate under a given EGF. +
§ Use of the Trust Registry Protocol.
+The TRP is intended to be used in at least two key ways:
+-
+
- Native Support - systems may directly implement access using the TRP. +
- Bridged - systems may create access “bridges” that provide TRP access to their systems. +
.
+§ Object Model
+We provide a high-level object model (NOTE: source of truth is the Swagger as this diagram may be out of date during development)
+ +§ Requirements
+§ Registry Queries [RQ-*]
+The following queries relate to receiving answers related to entities and other trust registries.
+-
+
- [RQ-1] MUST support query operations for the current status of a registered entity. +
- [RQ-2] MUST support querying about —TODO: +
§ Configuration Queries [CQ-*]
+The following queries relate to configuration of systems that will interact with the trust registry.
+-
+
- [CQ-1] MUST provide a list of action namespace that are supported by the responding system. +
- [CQ-2] MUST provide +
- [CQ-2] MUST provide a list of VID Type (i.e. VID Types) that are supported by the responding system. +
- [CQ-3] MUST provide a list of assurance level that are supported by the responding system. + +
§ Metadata Queries [MQ-*]
+-
+
- [MQ-1] MUST provide a list of ecosystem governance frameworks (EGFs) that the system is operating under. This data will be comprised of the following elements:
+
-
+
- [MQ-1-1] MUST provide the VID of the EGF. +
- [MQ-1-2] MAY provide the name of the EGF. +
+
-
+
- [MQ-2] SHOULD provide the legal name and jurisdiction of the governing authority for the trust registry service. +
- [MQ-3] SHOULD provide the legal name and jurisdiction of the administering authority for the trust registry operator (if different from governing authority). +
- [MQ-4] SHOULD provide a textual description of the trust registry mandate. +
§ Governing Authorities [GA-*]
+Governing authorities compliant with this specification:
+-
+
- [GA-1] MUST have exactly one primary trust registry. +
- [GA-2] MAY have one or more secondary trust registries. +
++The primary trust registry plus all secondary trust registries are collectively referred to as the authorized trust registries.
+
-
+
- [GA-3] MUST publish an EGF that meets the requirements of:
+
-
+
- [GA-3-1] This specification. +
- [GA-3-2] The ToIP Governance Architecture Specification. Note that this includes the requirement that the EGF and all governed parties (which includes authorized issuers and authorized verifiers) must be identified with a DID. +
+
TODO: Add normative ref to ToIP Governance Architecture Specification
+-
+
-
+
[GA-4] MUST publish, in the DID document associated with the DID identifying its EGF, a **service property **specifying the service endpoint for its primary trust registry that meets the requirements in the Trust Registry Service Property section. +[GA-5] MUST publish in its EGF a list of any other EGFs governing secondary trust registries. +[GA-6] MUST specify in the EGF any additional requirements for an authorized trust registry. This data will be comprised of the following elements::
+-
+
- [GA-6-1] SHOULD provide Information trust requirements. +
- [GA-6-2] SHOULD provide Technical requirements. +
- [GA-6-3] SHOULD provide Operational requirements. +
- [GA-6-4] MAY provide Legal contracts. +
+ -
+
[GA-7] MUST specify in its EGF (or in any referenced documents) requirements for:
+-
+
- [GA-7-1] MUST provide all authorization values that are used by the trust registry. +
- [GA-7-2] MUST provide all assurance levels, specified with unique names, that are service by the trust registry, and what authorization values they apply to. +
- [GA-7-3] MUST provide a list of all VID Types that are supported by the ecosystem, and serviced by the trust registry. +
- [GA-7-4] SHOULD provide
resources (TODO: TERM IS VAGUE)
that are required by systems integrating into the ecosystem that the system serves.
+ - [GA-7-5]
???any metadata required by implementors (e.g. claim name that is mandatory if pointing a credential back to an EGF.) [this is a weak example]???
+ - [GA-7-6]
???a statement about the basis the trust registry claims to be authoritative???
+ - [GA-7-7]
???means by which others are able to verify the asserted authority???
+
+ -
+
[GA-8] SHOULD specify in the EGF the following requirements for an authorized trust registry and any registered party (i.e., issuer, verifier, or peer trust registry):
+-
+
- [GA-8-1] The requirements to become authorized. +
- [GA-8-2] How to request registration. +
- [GA-8-3] The requirements for assignment of each authorization for a registry entry. +
- [GA-8-4] Any access limitations (e.g. unrestricted public access, authentication-limited access). +
- [GA-8-5] How to request access where unrestricted public access is not available. +
+
§ Trust Registry Service Property [TRSP-*]
+The DID document for the DID that identifies an EGF compliant with this specification MUST include a service property that meets the requirements in section 5.4 of the W3C Decentralized Identifiers (DIDs) 1.0 specification plus the following additional requirements:
+-
+
- The value of the
type
property MUST beTrustRegistry
.
+ - The value of the
serviceEndpoint
property MUST be exactly one HTTPS URI.
+
[TODO:
reconcile above with Profiles concept. ]
[TODO:
The issuer/verifier needs to state their primary trust registry affiliation (a trust relationship) - is this a new section?]
§ Trust Registry Protocol [TRP-*]
+The authoritative technical specifications for the API calls in the ToIP Trust Registry Protocol V1 are specified in Appendix A (OpenAPI YAML file). This section contains a textual description of the requirements.
+Trust registries implementing this protocol:
+-
+
-
+
[TRP-1] MUST maintain the service implementing this protocol at the HTTPS URI specified in the Trust Registry Service Property section.
+
+ -
+
[TRP-2] MUST return responses to queries for the status value of a registry entry that satisfies one or more of the following sets of query parameters:
+
+ -
+
Entity
+
+ -
+
Entity Authorization
+
+ -
+
Registry
+-
+
- i. Entity Authorization: entityDID, authorization +
- ii. Recognized Registry: entityDID +
+
-
+
- MUST return responses using the data model specified in the Data Model section. +
- MUST return exactly one of the following status values for a registry entry satisfying the query parameters:
+
-
+
- i.
Not found
(http 404)
+ - ii.
Current
+ - iii.
Expired
(not renewed after the previous valid registration period)
+ - iv.
Terminated
(voluntary termination by the registered party)
+ - v.
Revoked
(involuntary termination by the governing authority)
+
+ - i.
- For queries returning a status value other than
Not Found
, the response MUST return the following values: +-
+
- i. The parameter values exactly as supplied in the query (so responses can be stateless). +
- ii. The status value. +
- iii. Exactly two datetime values conforming to the following requirements:
+
-
+
- a. The value labels MUST be:
+
-
+
- i.
AuthorizationStartDate
+ - ii.
AuthorizationEndDate
+
+ - i.
- b. The values MUST be formatted to comply with RFC 3339 in the UTC/Z time zone with no offset. +
- c. The
AuthorizationStartDate
MUST be the date that the registered party’s authorization began.
+ - d. The
AuthorizationEndDate
MUST be either: +-
+
- i.
Null
for an entry whose status value isCurrent
at the time of the query.
+ - ii. A specific date value if the registered party’s status value is
Expired
,Terminated
orRevoked.
+
+ - i.
- e. If a registered party has multiple entries (representing an authorization history), the most recent value MUST be returned. +
+ - a. The value labels MUST be:
+
+
§ Anti-Requirements
+[AR-1] SHALL NOT support query operations for the history of a registered entity.
+[AR-2] SHALL NOT include support for a DIDComm interface, only a RESTful (i.e. OpenAPI Specification) interface. When a repeatable trust task specification approach is created, a DIDComm/trust task approach should be considered as a work effort.
+[AR-3]]SHALL NOT support automated rules processing.
+[AR-4] Anyting other than read-only INSERT, UPDATE and DELETE operations. The TRP is a read-only (RETRIEVE in the CRUD sense) protocol.
+§ Normative References
+ +§ Terms & Definitions
+-
+
- assurance levels +
- TODO: +
- +
- an acknowlegement by the responding system that an entity has (or does not have) is authorized to conduct for a particular action at the time of query. +
- +
- The primary trust registry plus all secondary trust registries are collectively referred to as the authorized trust registries. +
- action +
- a discrete property (string) that an entity can be authorized for, in the form of an authorization response. +
- action namespace +
- A well-known string that is used in an EGF to indicate a discrete authorization. Examples (non-exhaustive): “canada:driver-license”, “eu:trusted-list.authorized-timestamp”, “global:tsm” +
- ecosystem governance framework +
- TODO: replace this ChatGPT definiton: refers to a structured set of principles, rules, and mechanisms that guide and regulate the management and decision-making processes within an ecosystem. Ecosystem governance is typically associated with natural or environmental systems, where various stakeholders, such as governments, communities, businesses, and non-governmental organizations, work together to sustainably manage and protect ecosystems. +
- registered entity +
- An entity that is listed in the system (i.e. the trust registry) that is being queried. +
- primary trust registry +
- TODO: +
- secondary trust registry +
- TODO: +
- trust list +
- A one-dimensional trust graph in which an authoritative source publishes a list of entities that are trusted in a specific trust context. A trust list can be considered a simplified form of a trust registry. +
- trust registry +
- A registry that serves as an authoritative source for trust graphs or other governed information describing one or more trust communities. A trust registry is typically authorized by a governance framework. See also: trust list +
- VID Type +
- TODO: +
§ Appendix A: Consolidated Requirements
+For ease of reference, the following table consolidates all normative requirements in this specification. Each requirement is linked to the section in which it appears.
+THE FOLLOWING REQUIREMENTS IN THE TABLE ARE JUST EXAMPLES FOR NOW.
TODO: Finalize table once requirements (earlier).
+Req # | +Description | +Section | +
---|---|---|
+ | Governing Authority Requirements | ++ |
GA-1 | +EGF MUST have exactly one primary trust registry. | +[#governing-authorities-ga-] | +
GA-2 | +EGF MAY have one or more secondary trust registries. | +[[#governing-authorities-ga-] | +
A.3 | +MUST publish an EGF that meets the requirements in: | +|
A.3.1 | +This specification. | +[LINK] | +
A.3.2 | +The ToIP Governance Architecture Specification. Note that this includes the requirement that the EGF and all governed parties (which includes authorized issuers and authorized verifiers) | +[LINK] | +
§ Appendix B: OpenAPI Specification
+The OpenAPI Specification (v3.0.1) is the first “concrete” API specification.
+It is provided as an Open API Specification v3 YAML file.
+ + + +