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

The ETSI Trust List (2000s roots) is defined in the EU as “a” root of trust. How is this different from the common/base anchor for an ecosystem? Does the ETSI definition have an “anchor”. Contrast this with the GLEIF model which has a cryptographic root of trust (GLEIF’s own LEI) and discusses an authoritative root of trust, which is governance-based.

GLEIF approach to root of trust

• The GLEIF Governance Framework as the manager and oversear of the global LEI (and vLEI) system
• An LEI is not a technical credential and it is created by one or more human processes, using manual and digitally assisted verification techniques of claims and the data behind the claims, subject to classification using (guessing) credential specific “levels of assurance” which aggregate into a pass/fail against criterion and possibly earling an overall “level of assurance.
• Once an LEI is granted, then packaging of the organizational vLEI, plus public and private role vLEIs can take place, which are derived and linked to the LEI via the organizational vLEI.

Trust Registry and root of trust

Use Cases

• Organization A creates a trust registry of vendors (a list of LEI/vLEIs). A person P claiming to be from Organization X submits a submission to Organization A. Is A expecting to be contacted by someone from X? If X is not on in the vendor registry, then the submission is refused or is channelled to an investigation. 

Organizations have private data, for which protections are different than personal data Organizations (and organizational roles) that interact are simpler to deal with than private individuals as personal privacy data matters are largely absent. That is not to say that organizations also don’t have technical or organization information they wish to protect, but those are not typically included in transactions.

Corporate roles & personal data disclosure - GLEIF organizational roles are assigned to employees, but the credentials and personal data are structured so that employees, acting in a role (including as a general employee vs, say, a purchasing agent) are not required to disclose personal information (including name) to complete transactions on behalf of the organization.

This model (of private individuals, organizations and individuals as roles within organizations) are also incorporated in the DIACC an Pan Canadian Trust Framework (PCTF)

Organizations act as Parties through Roles - Tim Bouma “It (an organization) doesn't actually walk up to a desk or do something. Basically, an individual does something.”

NJT_post_meeting - In addition to suggesting that general and adhoc intereractions for formal organizations are performed via human Roles, it suggests that automated services (e.g. bill payment or accounts receiving) most likely also need an Organizational Role to act as a Party (e.g. Processing Role), including operating an organizational wallet, accessing and processing data (including personal data).

Using the GLEIF’s approach to authority chaining, a Processing Role (as an identity) will need to be issued (configured and provisioned) by a human Role (responsible for the Processing Role’s behavior) to behave as an operator of an Organizational Wallet for trust establishment and transactions. 

Issuers and Trust Registries need a higher Authority “certify” their scope/context/etc. - Example: Issuer authorized to issue Driver’s License in BC, Canada). This may take the form of a VC issued by a “higher level ecosystem” entity or listed in a high -level ecosystem registry. This “higher” entity must be reachable to verify (e.g. offline or preferably at run-time) the “authority status” (valid, expired, revoked) for Trust Registries, Verifier, etc. Details TBD.

Terms definition problem: Anchor or Root of Trust and related terms need resolving - the GLEIF definition of “trust anchor” and “root of trust” have well defined meanings. However, generally any governed component or service (including Trust Registries) are also referred to as a “root of trust”. 

NJ_post_meeting - It is suggested that there is chain of trusted services, components and authorities. There is a wide range of how those chains may be defined and how they are captured (“paper” or ACDC chains). It is suggested that this needs to be defined as part of the ToIP Governance and overall dual stack model.

The real world already has equivalents of the LEI qualification process, chains of trust, grants of right to issue, and registries of trusted organizations and services. The vLEI (cryptographic SSI identifier) process creation, governance and use are new. How do we bridge existing trust structures to SSI and ToIP models (e.g. GLEIF++)? ETSI trust lists are implemented as Public Key Directories (on DNS?). ICAO as an example. How do we move to a LEI/vLEI integrated governance and component model?

The ICAO (passport) model (see transcript for details) today is the current state of non-SSI trust, where you download a list of public keys which has “has all the national & subnational entities that can issue passports and their corresponding public keys”, and that’s the list of approved passport Issuers.

First gen ToIP TRs (and VC Issuers) will have to be a simple step up from current practice. So what is a step up from that simple public key list to a decentralized DID based registry which can show links to governance in a run-time provable way? That’s most likely all that ICAO and other similar organizations are willing to support for the first generation of general Trust Registries.

Much of the GLEIF due diligence on organizations and that are performed by LEI (qualified by GLEIF) Issuers are defined by outside regulators. 

Issuers are not concerned with Presentation (they just issue). A mechanism may be required for an Issuer to (verifiably) delegate to a presentation (selective disclosure) component.

The Issuer is concerned with the Issuance. “Manufacturing” the credential can be via a delegated component (e.g. Bank of Canada issues $$$, Canada Bank Note actually prints the $$$). Same for a passport - the physical creation of a passport is via a delegated service.

Example of different manifestations of a credential - a physical dollar (public) vs. a dollar in a bank account (private) - is that of concern to an Issuer?

Scott will be announcing work done with the Velocity network (that has done a deep dive on Issusers). 

Example of Driver’s licenses which have the authority to be used to board an aircraft (at an airport) is an extension (additional governance requirement) for alternate purposes for a credential, which likely needs additional governance/authority sign off (e.g., Washington State Enhanced Drivers license, presumably has authority signoff for flight boarding via the US Transportation Agency/ICAO).