Page Comparison

• 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_.

Data can go through a series of processing from collection/input to publishing:

• Collection (manual data entry or collection via devices) - produces a Raw Data Set
• Consistency dataset - where records are checked for valid attribute/property values
• Cleaned dataset - where outliers, duplicates, and values across multiple record types are "nonsense" values
• Published dataset - where data is checked for "correctness" and is "fit for purpose", possibly validated against related datasets

A data trust chain is going to link the published data set to the raw dataset and to the personnel or devices which collected the data.

QuestionNote: what about metadata associated with the dataset and (e.g. OCA model), plus software licensing , and other data administrative artifacts should also be included (e.g., OCA metadata)./linked

What is different about the Chain Element (in Authentic Data Provenance Chain - ADPC) vs ACDC is

• ACDC - is Authentic Chained Data Container
• Data Provenance Chain - is a container only of links to other links in the chain (which may actually be a mesh or tree) and links/references to the data and supporting information. 

The principle here is that Data and supporting documents are not moved to the ADPC but are referenced - where the references are crypto-secured. This allows the same data and artifacts to be included in multiple ADPCs and partitions the chains from the storage management of the referenced data.

Question: - where will ADPCs (the links) be stored, what structure/model?

Structure & other requirements include:

• • Tamper-proof or immutable storage
  • Scalable
  • "Offlineable" - migrate historic changes to cheaper, lower access speed storage, but make easily accessible.
  • Decentralized friendly - replication, distributed for access
  • Authentic:  structure, data and relationships are "authentic" - e.g., signed and hashed
  • As simple as possible
  • Purpose-built
  • Repurpose general SSI/Data/Authentic tools, libraries, etc., that will improve over time.

Suggested approach: a variation of the KEL - KERI Event Log, along with its replication/distribution and secure structure approach

Where ADPCs are stored or managed will be up to the Ecosystem.

Persistence of this type of audit trail can take a page from the capture of aircraft and trail system black box logging or any operational system where accident/incident analysis requires records to be kept for potentially years (in some form, not always full fidelity).

The issue of private/sensitive data that may be on the chain was discussed. 

The onus on proving that a provenance chain exists is something that will be publically required, but that can be a form of zero-knowlege-proof (not necessarily cryptographic).

Privacy of data in an ADPC: Access to, say, the underlying unpublished data and/or names and identifying information of the data processor and data governance representatives should be tightly controlled and only revealed in the case of a review (e.g., accident, incident). That may suggest that there are public and private views of an AD, possibly in two separate but linked chains.

An example of this would be an Issuer (e.g., GLEIF) who must perform due diligence (Know Your Customer) on a person or organization.  In order to issue a verifiable credential,  idealy, the issuers should have a record of all the due diligence information captured and referenced in ADPC links, but that information is available only for an authorized external audit. Otherwise, it is sensitive and private data.

Assumption: the published data, the support docs, signed components - all the artifacts, including the query-able data - will be identified by SAIDs - Self Addressable IDentifiers - meaning a crypto-hash of their content is the identifier.  What has not been solved (that the note taker is aware of) is if the use of SAIDs has some resolving mechanism (as for DIDs) that can locate an object anywhere online just with the content based SAID as an identifier. Not clear how that scales to trillions of online 'things" with SAIDs, DIDs, etc.

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