Code of Conduct

The membership of the ToIP Foundation pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

The Steering Committee is committed to upholding the ToIP Code of Conduct and contributors agree to act according to a standard set of behaviors that contribute to a positive environment.

ToIP Deliverables

Under our Linux Foundation Joint Development Foundation (JDF) charter, each ToIP Foundation Working Group (WG) can produce a variety of deliverable types. This repo covers the lifecycle management process for the work products ("deliverables") of the ToIP Foundation.

Figure 1: The five (5) primary types of ToIP Foundation deliverables

Table 1 summarizes the primary differences between these five types:

| Deliverable Type | Designed to be:| | --- | --- | | Specification | Implemented (in code)| | Glossary | Incorporated (in other documents) | | Recommendation | Followed (in practice) | | Guides | Executed (in operation) | | White Paper | Understood (to support decisions) |

Table 1: The primary differences between the six types of deliverables

Purpose

This repository serves several purposes:

1. Document and maintain the process information for contributing to the ToIP Foundation.
2. Storage and version control for a subset of the Foundation's deliverables.
3. Publication process for our Deliverables Portal, an interactive GitHub Pages website.
4. Manages a list of industry adoption activity.

Contributor's Guide

Contributors of content for the ToIP Deliverables Portal should familiarize themselves with the Authoring Process.

Related Resources

1. ToIP Deliverables Portal - Status
2. ToIP Contributor's Workflow

Management of Deliverables

Publication Categories

Each deliverable produced by the ToIP Foundation may be rendered for publication in a variety of formats. There are two categories:

| Publication Category | Description | Format Options | | --- | --- | --- | | Basic | A work-product delivered in only one format. | Markdown | | Multi-Modal | A work-product delivered in multiple formats. | Markdown, PDF, HTML|

Note: Regardless of publication category, the authoring process may leverage more than one Markdown file to produce the final work-product.

Publication Access

This repo serves as the storage repository for work-products within the Basic publication category. These work-products can be found in the recommendations folder.

Each work-product within the Multi-Modal publication category will have a dedicated repository within the ToIP Github Organization with unique publication process details.

Portal Development

This repo contains the content resources for the generation of documentation associated with the contribution process and state of our deliverables. It contains the tools necessary to generate this documentation in two rendering formats (printed, online). Please refer to our Portal Build Process for more details.

Getting Started with the ToIP Foundation

The ToIP Foundation maintains a variety of active and inactive activities that adhere to a specific process for the maturation and publication of deliverables that are relevant to:

• Work within the same working group
• Work within another working group
• Work within another community or SDO

There are several ways in which you can get acquainted with our work.

Learn

If you are here to explore the work products of the ToIP Foundation, we recommend you refer to the Deliverables Results section of our Deliverables Portal as it provides a current listing of all work product efforts and their statuses.

Contribute

If you have an idea for a new instance of one of our types of deliverables, please consider making a contribution:

• Contribute a Specification
• Contribute a Other Work-Products

Consume

The goal of the ToIP Foundation is to help define a complete architecture for Internet-scale digital trust that combines both cryptographic trust at the machine layer and human trust at the business, legal, and social layers. Our work products with be positioned at various levels of such an architecture and will mature at disparate rates. Please familiar yourself with the lifecycle management process for our deliverables and then when/where appropriate we welcome your feedback on how you plan or have consumed our work. Please keep us informed of your activities by submitted a pull-request against our adoption matrix.

About

License

This repository is licensed under an Apache 2 License. It is protected by a Developer Certificate of Origin on every commit. This means that any contributions you make must be licensed in an Apache-2-compatible way, and must be free from patent encumbrances or additional terms and conditions. By raising a PR, you certify that this is the case for your contribution.

Acknowledgement

This repo was derived from the ToIP Material for MkDocs Repo. It was inspired by the structure and successful experience of the Hyperledger/Aries-RFC Repository, which was in part based on Indy HIPEs, which borrowed it from Rust RFC.

ToIP <TypeIndicator><4digitID>: <DeliverableName>

Update title. For example, BP000: Utility Selection Criteria DELETE THIS COMMENT

• Authors: your name -- email is optional
• Status: PROPOSED
• Since: YYYY-MM-DD (date you submit your PR)
• Status Note: (explanation of current status)
• Supersedes: (link to anything this ToIP Deliverable supersedes)
• Start Date: YYYY-MM-DD (date you started working on this idea)
• Tags: (see Tag Options

Summary

One paragraph explanation of the objective of the subject ToIP deliverable. DELETE THIS COMMENT

Purpose

This repo manages the development and maintenance of the subject ToIP deliverable. It contains the tools necessary to generate multiple renderings formats.

1. Interactive Online Website: GitHub Pages
2. Printable Documents
   • PDF Version
   • HTML Version
   • Standalone Markdown

Contributor's Guide

Documentation and Specification contributors should familiarize themselves with the Authoring Process. Replace <REPO_NAME>

Related Resources

1. ToIP Deliverables Portal - Status
2. ToIP Contributor's Workflow

Requirements

Workflow

ToIP contributors should be able to: 1. Gather: Define, Organize and Assign work towards the development of a ToIP Deliverable based on project outline that aggregates a collection of discrete Markdown files. 2. Author: Use any Markdown editor they desire. 3. Produce: Configure the generation of one or two possible deliverables: General Document, Specification.

Styling

1. Apply a Material style Theme that is ToIP specific
2. Leverage a Color pallet derives from the ToIP Logo Assets.
3. Provide configurable navigator with numeric outlines level 1-3: See Spec-Up as an example style for the development of specifications.
4. Build upon the Material Theme (not insiders) with Search Suggest and/or Highlight - void of Insider Token requirements.
5. One ToIP Theme with config option for header generated numbering (with or without).

Versioning

ToIP members should be able to prime to repos using this repo as a GitHub Template Repository.

Development and Processing

1. Command line tools (make) for generating local test content.
2. Github workflow (actions) for producing GitHub-Pages
3. Layout (outline / organize) multiple markdown files (i.e.: mkdocs.yml)

Rendering Formats

Minimally, this repo MUST allow for the configuration of generating these rendering formats: 1. Single Markdown file (via pandoc or other plugins) 2. Single PDF (via pdf-export or other plugins) 3. Website/GitHub-Pages

Authentic Chained Data Containers

Abstract

Authentic Chained Data Containers (ACDC) Standard Specification provides semantic of authentic provenance chaining of authentic data containers. This semantics include both source provenance and authorization provenance or delegation.

Status

Version 1 Draft 01

Motivation

We need a way to chain authentic data together, allowing its provenance to be traced. This is valuable in many use cases:

• Supply chain, where a valid transfer of custody downstream depends on the validity of all upstream handoffs.
• Delegation, where a delegate's privileges derive from a chain of authorizations that must extend back to a source that is empowered.
• Citation of sources (in art, in journalism, in academia, or in credential issuance), where an author wants to clarify that a particular assertion originates elsewhere. This allows the assertion to acquire (or lose) gravitas independent of the reputation of the author who includes it. It also allows analysis of license compliance.

The last of these examples deserves special comment. There is a tension between the decentralization that we want in a verifiable credential ecosystem, and the way that trust tends to centralize because knowledge and reputation are unevenly distributed. We want anyone to be able to attest to anything they like--but we know that verifiers care very much about the reputation of the parties that make those attestations.

We could say that verifiers will choose which issuers they trust. This is exactly what most practioners of VCs recommend, and it works in early pilots. However, this places a heavy burden on verifiers, over the long haul--verifiers can't afford to vet every potential issuer of credentials they might encounter. The result will be a tendency to accept credentials only from a short list of issuers, which leads back to centralization.

This tendency also creates problems with delegation. If all delegation has to be validated through a few authorities, a lot of the flexibility and power of delegation is frustrated.

We'd like a landscape where a tiny startup can issue an employment credential with holder attributes taken as seriously as one from a massive global conglomerate--and with no special setup by verifiers to trust them equally. And we'd like parents to be able to delegate childcare decisions to a babysitter on the spur of the moment--and have the babysitter be able to prove it when she calls an ambulance.

Scope

This document describes a mechanism whereby assertions about data can be provenanced in a provably authentic chain. Evaluating the integrity of the chain is in scope -- and because such chains leads to one or more root sources, the chain provides the raw material for making judgments about the data's utility or probable veracity. However, evaluating the data's utility or veracity is out of scope.

In other words, this standard concerns itself with proving that party C got its data in a valid way from party B, who in turn got it from party A. The degree to which the origin party, A, is trustworthy in their assertions about reality is not our concern.

Terminology

• SAID - Self-Addressing Identifier - any identifier which is deterministaclly generated out of the content, digest of the content

Specification

Overview

An ACDC may be built up from an authentic data container (ADC) that contains an authentic provenance chain (APC). The term authentic data container (ADC) is an important abstract concept that hopefully may leverage a pre-existing open concrete implementation standard specification. The current targeted concrete implementation specification is the W3C Verifiable Credential (VC) standard. We believe that authentic data containers (ADCs) with authentic provenance chains (APCs) that together compose an authentic chained data container (ACDC) are essential components of verifiable or authentic data supply chains which in turn are essential to what may be called the authentic data economy

TODO: mention about informative example used across whole spec

Security guaranties

Privacy guaranties

Informative Example

``` { "v": "ACDC10JSON00011c_", "d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM", "i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM", "s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A", "a": { "d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY", "i": "did:keri:EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA", "dt": "2021-06-09T17:35:54.169967+00:00", "ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt", "LEI": "254900OPPU84GM83MG36", }, "p": [ { "qualifiedvLEIIssuervLEICredential": { "d": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA", "i": "Et2DOOu4ivLsjpv89vgv6auPntSLx4CvOhGUxMhxPS24" } } ], "r": [ { "usageDisclaimer": "Usage of a valid Legal Entity vLEI Credential does not assert that the Legal Entity is trustworthy, honest, reputable in its business dealings, safe to do business with, or compliant with any laws." }, { "issuanceDisclaimer": "Issuance of a valid Legal Entity vLEI Credential only establishes that the information in the requirements in the Identity Verification section 6.3 of the Credential Governance Framework were met in accordance with the vLEI Ecosystem Governance Framework." } ] }

```

• v version string of ACDC
• d SAID of ACDC.
• i Attributable Source Identifier (Issuer, Testator).
• s Schema SAID
• 'a' Attributes
• p Provenance chain
• r Rules rules/delegation/consent/license/data agreement under which data are shared.

ACDC as Verifiable Labeled Property Graph Fragment

The structure of an ACDC may be modeled as a fragment of a Labeled Property Graph. The p block is an array of edges and the a block is the node. The remainder of the ACDC may be metadata about the node that may also be included as special node properties. Because, the edges in labeled property graphs may also have labeled properties, a more aligned representation would make each source entry a labeled block (or at least as an option). This is illustrated in the following example:

```

{
   d: "did:1209u091u9012d/attestation/1234",  // SAID
   i: "did:1209u091u9012d",
   p: 
   [
        {sourcEdgeLabel: {i: "did:kdjflkeje", tid: "did:jd892j108jd1029", ...}}, // attestation id not in namespace of testator
        {anotherSourceEdgeLabel: {i: "did:9d9j109j1d902dj19/attestation/3242", ...}},  // attestation id in namespace of testator
        {yetAnotherSourceEdgeLabel: {i: "did:h78h8d2h8d2h8hd28d/attestation/1234",...}}  // attestation id in namespace of testator
    ],
    s: {}, || SAID
    a: 
    {
       i: "SAID",
       k: v,
       k1: SAID,  // ref1
     }, || SAID
     r: {}  || SAID
 }

```

Because each ACDC thus composed is verifiable, a verifiable graph may be communicated via verifiable graph fragments. Given any starting node or root node in the graph, one may add onto the graph by communicating graph fragments where each fragment includes a new node and the edge or edges that connect it to one or more pre-existing nodes. The over-the-wire communication of the fragment is secured by the immutability of the ACDC contents (SAIDs) and the signature or committment proofs on the fragment. This drives the structure of any given ACDC to be a graph fragment not a graph in and of itself. The semantics of who issues or testates to a fragment and who the fragment is issued to (if any) may vary. With an issuer and isuee then the fragment may be an authorization or delegation. If the isuee is the node itself then the fragment is just provenanced data in a provenanced graph.

Normative model

OCA Model Version of Field Labels

Versioning

References

• [1] https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/ACDC.web.pdf
• [2] https://github.com/THCLab/keri-python-ffi/tree/supply_chain
• [3] https://hackmd.io/rnY5xiXESWqWBlyDPHDorA?view
• [4] https://github.com/THCLab/keri-python-ffi/tree/supply_chain
• [5] https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/VC_Enhancement_Strategy.md

Apendix

Examples

TODO: provide more examples

Security considerations

Privacy consideration

Benefits

TODO: - focus on generic problem of authentic data - do not relay on any specific network nor implementation

ACDC focus on the base semantic specification to address core properties of authentic data flows. ACDC provides semantic allowing to express: - authenticity for any data flow - self-describing mechanism to understand the context of data - chaining mechanism (including delegation) - increasing interoperability by not relaying on any specific use case and implementation

Motivation/Problem statement

TODO:

• Arguments why existing solutions are not good enough.
• What is the problem

Example of similar construct

TODO:

• VC Data Model
• ZCap-LD
• ...