• Start recording
• Welcome & antitrust notice
• Introduction of new members
• Agenda review

• Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.
• New Members:

Call to review the "Issuer Requirements Notes and Outline (link)

How do Issuers and Trust Registries fit into an ecosystem, and what is/are the definitions of roots-of-trust?

The ETSI Trust List (link), a type of Trust Service Provider that was originally created in the EU in the mid-2000s, is the basis for the current concept of a Trust Registry. This was a stand-alone list which not only operated the machinery of the list but qualified the entities/objects that were included in the list. Effectively this was a "white list" of approved entities/objects.

A Trust List is managed by an EU jurisdiction that sanctions a list as a root of trust for the scope of the entities/objects within the list. The governance authority for the ecosystem is the Jurisdiction - essentially the ecosystem's Administrative root-of-trust.

So how does this model compare & contrast with the GLEIF KERI/ACDC model, which has explicitly signed chains of credentials signed by organizational roles, which are themselves credentialed back to cryptographic and organizational roots of trust that can be verified at run-time (via the ACDC credential-role-signature chains)?

Comment:

GLEIF has a tightly bound use of cryptographic linkage (using ACDC chains) to provide a tight relationship between GLEIF as an organization (and its internal roles (of personnel)) and the relationship between GLEIF's own LEI/vLEI and that of its LEI and vLEI issuing organizations (and their customers - legal organizations) and the vLEIs of the human roles within those chains. This is backed by Governance Documentation (themselves signed by organizational vLEI roles), including authoritative documents delegating authority (e.g., to a vLEI issuer to issue vLEIs to their customers).

However, that is not yet a widely used model. A more common model is a combination of crypto-signatures for components of the system with authoritative documents (including governance) which authorize a component (e.g., an Issuer of a type of VC (workplace safety certificate)). 

Goals include having trust chains verifiable (e.g., Verifier being able to validate that an Issuer has the authority to issue a given VC), which may be done via being contained in a Trust Registry of Issuers or via traceability (GLEIF approach) to a certificate issued by a higher authority (e.g., an ecosystem Issuer qualification authority).

Note: both VCs and entities put into a Trust Registry need to be validated/verified to meet the qualification rules defined:

• For a VC an Issuer needs to verify evidence and attestation from 3rd parties (e.g., a driver's license needs (at minimum) valid personal identification (e.g., citizenship, residency), and a driving test certificate
• For inclusion into a registry of Municipal Planners for the Province of Ontario, some Qualifying Authority needs to establish the rules and delegate them to an organization/role to validate: qualification as a Planner (appropriate degree), plus meeting Ontario jurisdictional standards in municipal (vs other forms of) Planning 

Based on earlier discussions, Issuers and Registries must fit within the application/ecosystem use cases for which there is most likely a top-level governing authority/jurisdiction which will define the requirements of the components and processes (automated and human).

Conclusion - Issuers and Trust Registries are key "points of trust" within the "Trust Fabric" of a solution space, ecosystem or application, which needs a top-level authority as the administrative root of trust and potentially a fully crypto-graphic chain based verifiable root of trust.