• 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:

News or events of interest to Governance Stack WG members:

• -

A key requirement for Verifiable Data Registries is an audit trail of all the processing and all the people (producers and governance stewards) who touched the data from the point of data creation/capture through a published dataset. This includes the following requirements:

• Verifiable proof that the data/data set has not been tampered with
• Verifiable proof (and identification) of the person responsible for:
  • Processing the data (including collection, clean-up, aggregation or other analytic processing, testing,...) 
  • Who audited/ensured governance compliance for data collection and processing

Today's discussion is to look at a model of how that could be implemented in exploring the functionality and data (and data structures) required for Verifiable Trust Registries and their listed trusted entities to be trustable in a robust and secure manner.

The presentation today is concerned with Authentic Provenance Chains - a "Trust chain" (which ACDC supports) using cryptographic signing of data (and all objects are data), counter-signed by data processing authority (the representative of the organization/team that processed the data) and  the governance authority (the organization representative responsible for ensuring governance compliance), which is also chained to previous data processing steps and support artifacts (processing scripts applied to the data and testing)

We will look at Verifiable Data Registries - which are registries of objects (which are data), which have been verified and validated by a governed process which performs "due diligence" on the objects and their data and processing lineage - be it with sw/hw, manual processing or some combination.

And Trust Registries are a sub-type - a Trusted SSI Component/Rol Registry, of which the subjects of the first use case are Issuers and Verifiers

The underlying principle for trust chains is the principle of "Authentic Data", where the creator/publisher/owner of the data uses a private key under their control to sign a hash of the data (a crypto-hash), publishing the corresponding public key, which can be used by any consumer of the data, by verifying the crypto-hash of the data (with the public key)

There may be a distinction between a Verifiable Data Registry (Authentic Data Registry?) and a Repository. An V/ADR provides proof of the data's lineage, a Repository may be the database which provides access services for the data (and the two may be combined_.

A core principle of Governance is to prioritize based on risk for an application, service or data source, the organization, its personnel and its financial/legal state/reputation.

The current state of cybersecurity points to a number of key risks to which SSI is (also) vulnerable:

• Message interception and decoding
• Message and service hijacking (imposter, identity theft - personal and organization)
• General impersonation, including falsified credentials/claims, etc.
• Capture and exploitation of data (undetected) 

Some examples pertinent to SSI:

• Use of a compromised identifier by yourself or other parties
• Hijacking PKI management or private key theft
• Accepting VCs from a compromised Issuer 
• Use of compromised (including fictional) data 
• Interacting with compromised trust components (Trust Registry, other ledgers)
• Replacement of cryptographic or other security-related components and services with a compromised version

For example, if you are a root administrator on a server, and a service relies on the server's cryptographic libraries, the admin can swap out the libraries for a compromised set. "Authentic" methods, e.g., crypto-signing an executable and related support files (the libraries), controlled by the actual administrator (or other authority), can provide tamper resistance as the service can verify the library by using the public key of the signing authority by rehashing the executable's signature and verifying w the public key.

Another example: "If you are not the person who is building the compiler, anyone can add a back door and you would never know".

• Review decisions/action items
• Planning for next meeting