Page tree
Skip to end of metadata
Go to start of metadata

This page contains the meeting agendas and notes for the ACDC Task Force. Note that for expediency it is a single running page of notes (vs. separate Meeting Notes pages for each meeting as is typical of other ToIP Working Groups and Task Forces). Meetings are in reverse chronological order.



ACDC Sessions

  • Proposed sessions
    • GLEIF vLEI  Business T S1
    • GLEIF vLEI: Demo   T S2 Distributed Multi-Sig Chained Credentials using KERI and ACDC — Phil Feairheller and Kevin Griffin
    • MicroLedger Four Provenance Logs Authentic Data EcoSystem  T S3 Robert Mitwicki
    • What is ACDC? T S4— Samuel Smith
      • KERI and ACDC Technical Session
      • Covers all the contributing specsSamuel Smith
  • Related Sessions
    • Introduction to KERI W Drummond Reed 
    • Practical Introduction to KERI: How Can I Actually Use it Today?W Phil FeairhellerKevin Griffin (Command Line Tools with KeriPy)
    • Systems Design PAC Theorem Privacy Authenticity Confidentiality  Tradespace W Th  Samuel Smith
    • Secure Attribution with KERI: How it Fixes the Broken Internet W Th — Samuel Smith
    • Zero Trust Data Management  BADA RUN vs CRUD: discovery and authorization mechanisms W or ThSamuel Smith



  • We need to complete the final Lead Author assignments in the Deliverables table on the ACDC home page (<5 mins)—Samuel Smith
  • We quickly cleaned up the table so that all specs have lead authors.


Compact Label Normalization

  • Future KERI change to use SAIDs   Revised labels for ACDC that are normalized Samuel Smith
  • See screenshot #1 below.


  • Robert Mitwicki 
  • He gave an explanation of microledgers based on a spec being developed at the Human Colossus Foundation—see screenshots #2 and #3 below.
  • It generalizes the idea of a KEL (key event log).
  • Samuel Smith agreed that the generalization of event logs is a good idea. His only concern is that when it is generalized, it becomes much easier to make security mistakes. That's why the KERI and ACDC specs are much tighter.
  • Robert Mitwicki is planning to give a session at IIW on microledgers.

Screenshots (for notes above)




GLEIF VLEI update  Phil Feairheller

ACDC Sessions

  • Proposed sessions
    • GLEIF vLEI: Distributed Multi-Sig Chained Credentials using KERI and ACDC — Phil Feairheller and Kevin Griffin
    • What is ACDC? — Samuel Smith
      • KERI and ACDC Technical Session
      • Covers all the contributing specs
    • Why ACDC? (And Why Not _____?) — Robert Mitwicki
      • This would include A Feature Comparison Table
    • Secure Attribution with KERI: How it Fixes the Broken Internet — Samuel Smith
    • Practical Introduction to KERI: How Can I Actually Use it Today?
  • Related Sessions
    • GLEIF vLEI  
    • Zero Trust Data Management  BADA RUN vs CRUD: discovery and authorization mechanisms Samuel Smith
    • MicroLedger Robert Mitwicki



Brief update on wiki page reorg—Drummond Reed

  • Meeting page has been broken out into a standalone page (this one)
  • A table of deliverables has been added to the ACDC home page
    • We should be sure this table is complete and kept current

IIW Strategy:  Daniel Hardman

  • Daniel: How many sessions would we like at IIW?
  • Sam: one session per day
  • Daniel: in previous IIWs, Sam had done 2-3 sessions per day
  • Sam: plan on one per day, and then possibly have a second one
  • Robert: have one technical session, and one non-technical session focused on use cases and business cases
    • Data flows, data supply chain, product supply chain
    • For example, GS1 has very specific requirements that the KERI family of specs can meet
  • Daniel: can we develop a spreadsheet showing a classic product comparison table (similar to what the DIF DIDComm WG has created for DIDComm & HTTP(S))
    • Robert liked the idea of the table being something that stresses the business
    • ACTION: Robert Mitwicki will prepare a draft of a feature comparison table before our next meeting.
    • ACTION: Drummond Reed to talk to Brent Zundel about a session about VC V2 at IIW
  • Proposed sessions
    • GLEIF: Distributed Multi-Sig Chained Credentials using KERI and ACDC — Phil Feairheller and Kevin Griffin
    • What is ACDC? — Samuel Smith
      • KERI and ACDC Technical Session
      • Covers all the contributing specs
    • Why ACDC? (And Why Not _____?) — Robert Mitwicki
      • This would include A Feature Comparison Table
    • Secure Attribution with KERI: How it Fixes the Broken Internet — Samuel Smith
    • Practical Introduction to KERI: How Can I Actually Use it Today? - 

ACDC Specification Strategy:  Daniel Hardman

  • SAID spec—Sam Smith
  • IXP spec—Phil Feairheller
  • PXP spec—Phil Feairheller
  • PTel spec—Phil Feairheller
  • CESR spec—Sam Smith
  • CESR proof spec—Phil Feairheller
  • AID spec—Sam Smith
  • ACDC spec—Sam Smith
  • SIS spec—Robert Mitwiki
  • ACTION: Drummond Reed to update the ACDC home page deliverable table with these leads

General Discussion:

  • Suggestion is that KERI is too large to be a single spec, so break it into smaller specs.
  • For example, CESR can be broken out into a separate composable serialization spec.
  • And you separate out identifier specs.
  • Once you take the identifier formats and composable streaming format out, then KERI becomes a definition of events.
  • We also talked about the future of the W3C Verifiable Credentials spec—Brent Zundel is working on the charter for the V2 Working Group
    • What is being discussed is the possibility of the new WG taking a "Big Tent" approach
    • In that case, ACDC would be one of the "branches" or "options" or "families" of a W3C VC V2 compliant
    • The big question is whether others that would be in that big tent would be tolerant (or even welcoming) of having the ACDC family under the tent
  • Sam brought up the question of how KERI and ACDC deal with dynamic data
    • DIDs and DID documents try to be dynamic and VCs try to be dynamic, but neither does it with strong security
    • KERI and ACDC have a way of handling dynamic data with a zero-trust security model
    • Robert talked about how KELs can essentially act as microledgers ("single node blockchains") to trace the changes in state to any kind of data set
    • Sam agreed to you need both authentity, monotinicity, and protection from replay event logs
      • DID docs use the CRUD model
      • This requires using the RUN model (Read, Update, Nullify)
  • ACTION: Drummond Reed to ask Elisa to change the ACDC meeting to auto-record


Details of how GLEIF is using ACDC and associated specs. Placeholder spec repositories at

Specs WoT

KeyStorage module Manager and Keeper classes encrypted secrets

vLEI Credentials rely on the following specifications:

  1. JSON Required
  2. JSON Schema Version 2020-12
  3. Composable Event Streaming Representation (CESR) Specification
  4. Attributable Identifiers (Autonomic Identifiers, AIDs,SCIDs) for Issuers and Holders using the did:keri Method (secure attribution)
  5. KERI Decentralized Identifiers (AIDs) did:keri Specification
  6. Self Addressing Identifiers (SAIDs)
  7. Schema Immutability Specification (SIS)
  8. Composable Event Streaming Representation (CESR) Proof Format
  9. ToIP Authentic Chained Data Container (ACDC) Specification
    1. (Informative) JSON required as defined in
      1. Exception @context MUST NOT be included.
  10. Issuance Exchange Protocol Specification for ACDC and KERI (Key Event Receipt Infrastructure)
  11. Presentation Exchange Protocol Specification for ACDC and KERI
    1. WACI PEx
  12. Public Transaction Event Log (PTEL) Specification

Core Components of KERI  Robert Mitwicki

Key Provanance Log -> KEL
Self-Certifying Identifier -> SCI, keri prefix
Self-Addressing Identifier → SAI
General purpose registry -> TEL
Secure communication proctocol CESR/DIDComm?
Self Describing cryptograhic material encoding - CESR/Multicodec/CDE/JOSE/COSE
Key Storage

Relationship between ACDC and W3C VC 2.0 (Daniel Hardman)

   Not RDF Triples

    Compact IoT credentials


           Collaborate  W3C VC  Big Tent

            Go our own way with ToIP/IETF ACDC  

            Suck the Air Strategy ToIP/IETF ACDC


OCA as a SAID based Schema Immutability specification

More details on ToIP glossary wiki facility

HCF working with ESSIF on Rules section of ACDC


Issues with security privacy suggested pull request (Daniel Hardman)

Terminology (Daniel Hardman)

      How to formally manage terminology in Specs:  (Other group)  create terms wiki  Create new page

      Glossary may be auto-generated from the wiki using the TT tool. (python)

Order of creation of SAIDs  (Daniel Hardman)

Degree of Saidification (Sam Smith)

Continue discussion on Schema and SAIDs

IGrant Data Agreement with ACDC (Robert Mitwicki)

GLEIF ACDC vs VC models

LPG model

Calendar of ToIP Meetings


Continue discussion on Schema and SAIDs

LPG model


Alignment with VC data model

Multiple Endorsers

Continue discussion on Schema and SAIDs


Phil talk about JSON Schema and SAID

Change meeting time ?

Proof signature

Alignment with VC data model

Multiple Endorsers


discussed and refined example in  of draft spec.  Decided that certain blocks in VC MUST use SAI (self addressing identifiers) so that can reason about the data using the identifier.

This allows compactness and secure universal verifiability. Either the block is explicitly included or instead of the block a SAID.

The schema is nested with SAI blocks for the corresponding blocks in the VC

schema of data payload

schema of rules


Write spec outline

Abstract Model

Two concrete implementations. One VC Linked-Data with with security caveats, the Other JSON and immutable JSON-Schema

Example Spec Outline










Versioning Guidelines





     Verifiable Credentials



Security & Privacy Considerations




     Terms defined by this specification


     Informative References

High-Level Summary




Problem Statement




Semantic inference and reasoning under uncertainty

Work Item for next week write spec outline


OCA (Overlays Capture Architecture)  Robert Mitwicki    (input and semantic WG at ToIP)  standard


OCA Article:
OCA editor:
OCA spec draft:

JSON-LD Security EndState Sam

Proposal Identifiers  Sam

MetaDiscussion Daniel



Continue Discussion

Notes about ADC and its structure:


Data Item Model

Authentic Data Item = Attestation 

     Data Controller ID:   DID namespace controller

           Attestation ID: (in order to reason with data)(IETF RATS Alignment) ID of the Attributable Item Attestion.

             Derived DID from DID namespace

              Derived from Data Item Content (such as attestations)

                 Verifiable Registry of Data Item

       Data Attributes:{NonAuthentic Attributes}

        Data Controller Signature on Data Item: (nonredudiable, integral) 

Data Mesh Meetup


MKDocs GitHub

Delegation chain separate from identity chain

hiding part of the chain

privacy in both direction walking back up to the root and privacy walking down from the  root


Followup on getting repo setup in MkDocs

Use Cases Selected:

Supply Chain (Mitwicki)

GLEIF (Smith and Reed)

Delegation (Hardman)

Data Source Provenance (Hardman and Smith)

IoT  (Hardjono)

Next task

Create proposals for chaining semantics with syntax.  (assume Verifiable Credential Based)

Express each use case in each chaining proposal.

Iterate on proposals.

Open Question:

Syntax should at least support Trees and DAGs  (Directed Acyclic Graphs) not merely linear chain

Should syntax also support cyclical graphs.


Finalize choice of MkDocs vs SpecUp: Decided on MKDocs:

   Action Item: Sam work with TOIP to setup GitHub repo with MkDocs

EiDas Links: (See 2021-02-01)  Robert Mitwicki.  Discussion of SSI etc in EiDAS

Relation to Legal Framework for Digital Signatures




       Advanced Electronic Signature  Qualified Electronic Signature  Notaries  with Certificate = Handwrittern Signature

Review Use Cases:

Semantic Containers: Pauls Knowles Semantic Container.  Nested Forms. Consent.

Distinguish between different types of containers as part of specification for ACDC


Action Item Robert Mitwicki add information on EIDAS  regulation  allows for linking.

Discussed CCG Meeting on ZCap vs VC Authorization

Discussed Use Cases  

MkDocs vs Spec Up  (Tables?)

Action Item Sam review and present at next meeting


Use Case Summaries

GLEIF vLEI  (Sam Smith ProSapien)

Supply Chain (Robert Mitwiki Human Colossus )

Global ID for life (IdNum - Robert) 

Digital Immunization Passport (Robert) 

Authorizations for Encrypted Backups (Charles Cunningham Eugeniu Rusu Jolocom)

Guardianship Chain of Credentials (Evernym  Daniel and Drummond)

Delegating Access to Rented Car (Evernym)

Provenancing Inherited Attributes (Daniel Hardman Evernym ProSapien)

Delegation of Certification Authority PKI Certificate Like Chaining  (Ned Smith Intel)

Object Capabilities Like Authorizations (See authorizations for encrypted backups) 

Critical Supply Chain Provenancing (Carsten Stoecker Spherity)

Open Accredited Market Participation Energy Market  (Jolocom)

Provenance Virtuous Supply Chains Conscious Consumers Demand Pull  

Data Supply Chain Provenance

Data Supply Chain Consent Provenance Consented Data Privacy  (Samuel Smith ProSapien)

Content Distrubution Networks (copyright, acknowledgement, usage, attribution)  (Thomas Hardjano MIT)

IoT Onboarding Devices (Ned Smith Intel, Thomas Hardjano MIT)

Attestation Chaining

Anonymized Data Chains -

Representing business processes/entity lifecycles with SSI - Representing Lifecycles of Entities using States + SSI.pdf

Attribution Chaining Semantic Super Semantic

     Secure Attribution of statement to controller of a decentralized identifier

     A securely attributed chaining statement links two securely attributed statements together

     A chaining statement is a special case statement whose semantics are to securely linked by attribution.

     This chaining may be applied recursively.

     The chained statements that are not chaining statements may convey sub-semantics such as authorization, delegation, attestation, provenance, etc.

     Attribution Verification Types:  Nonrepudiable Signatures. ZKPs. Anonymized Data.

Certificate Result Certification 

    Certifying the result of a decision  

    Verifiable Algorithm

    CoSWID Tags  IETF

  • No labels