Papers

Authentic Chained Data Container ACDC Verifiable Data Structures (Graphs) that support Provenanced Authenticatable Attestations & Entitlements Samuel M. Smith Ph.D. sam@prosapien.com 2022/09/15

Specification Documentation: ACOC ntenet rat (TP -167F) btasiigitub cominstoveriohsvg acdcspedicaion ACOC or Muggles tpscocs google.comprsentaionldmOFEZS S AMEEN UM DM SN SIdesid gaciberesa_o_o Resources on K and ACOC cpserinefri-esourcest GLEIF VLI Crdetil CibalLegal EntiydenferFoundation) (50 L1 specfcaton psbevn it orglenbcintrocucing he verftie kit Community: (meetings, open source code, IETF internet drafts) Acoc working aroup ek rustoveri.onespley HOMEIACDC28Authentc ChanedData Cotaineriag Taskiorce Relted et Drafts pslgitub.comebo Tustiert

Important ACDC Features

AACDC is based on KERI so one gets all the features of KERI for free. Leverage SAIDs (Self-Addressing Identifiers) and AIDs (Autonomic Identifiers)

Based on white magic (dumb) crypto: digests, and digital signatures. Leverages CESR (Composable Event Streaming Representation) to resolve the text vs binary tension. JSON Schema (Type-is-schema, schema are immutable) Chaining (labeled property graph fragment model) Graduated Disclosure (compact, partial, private, selective) Contractually Protected Disclosure (chain-link confidentiality, contingent disclosure)

Protection against data exploitation from both statistical correlation and cryptographic correlation Decentralized extensibility model Zero-trust End-Verifiable

Basic ACDCs Private Compact Variant JSON. (even more compact CBOR, MGPK, CESR also supported)

Basic ACDC JSON Schema Non-Compesed JSON Schema

Uncompacted Private Attribute Section e ottt Attribute Section as Composed JSON Schema

"dn: "ESrZwLIrSBITV_NHWYL1kErndy22gveyd-9XgoeLxUdY", "boss": "d": "EFy2PqveY4-9XgOcLxldYerzwLIrdBETV Niw¥llkFrn®, "an: “ETL3MORH3ACdoFOLe7liheqeywlenstItOIYPVAUGDZA”, "s": “EFOLe7liheqcywJoni ttQIYPVAUEDZAT 1 MORKIACS”,

Nested Edge Section with Operators

ACDC Normative Field Labels e cecrpion TopLeviiks C e et 153, i gt e e L ami | Rt ot R B LSRG S RS T o o Ui Dot i 5 dm 7,58 11 o 7 e S e s ook i et e e b v e S o e b 013 58 e i i el 5 oterrides e Bt oyttt NS e by 1 3 o T Tt U st s i3 e, 8 i e i e R o e ATt A 0 TR LS S A 71 = e e S o e ety ol i et e i s D e [P

Big Picture: What is an ACDC? + Decentralizable distributed verifiable data structure that is structurally constrained by immutable but composable JSON Schema. « Each ACDC s universally uniquely referenced by its SAID. + Authenticatable decentralizable distributed graph fragment that may be communicated securely. + Graph fragments use SAIDs to hash-chain themselves together without any expansion needed. + The composition of graph fragments is an authenticatable verifiable graph data structure, i.e. a chained set of ACDCs (zero-trust end-verifiable security model) « Verifiable data structures all the way down Graph Fragment L, edge(s) H - s | e L~ il o [ - G ~ node properties. " ‘edge properties . -

ACDC is a Hash Tree The different variants of an ACDC form a hash tree (using SAIDs) that is analogous to a Merkle Tree in that the root hash provides an integrity proof of the tree. Signing the top-level SAID of the compact version of the ACDC is equivalent to signing the root hash. Different variants of an ACDC (SADs with SAIDs) correspond to different branches of the hash tree. The process of verifying that a SAD via its SAID of a section is included in a schema authorized variant down from the top- level SAID i a type of proof of inclusion. This allows a single signature to provide proof of Issuance of the presentation of any schema authorized variants of the acoc.

Chained ACDCs (graphs) Enable Provenanced chains-of-custody of decentralizable authenticatable data attestations Traceable data for data supply chains Provenanced chains-of-authority for decentralizable authenticatable credentials Verifiable delegated entitlements or authorizations by 71 . L i, 0 L - I ‘ = N ( o — - "

GLEIF vLEI Credential Example Qualified VLEI Issuer (QVI) Credential Qualified vLEI Issuer (QVI) Credential Legal Entity (LE) Credential Legal Entity (LE) Credential Engagement Context Role (ECR) Credential Official Organizational Role Authorization (OOR-AuthZ) Credential . Official Organizational Role (OOR) Credential o Issued-to VI authorzed regresentative. Issued-by GLEIF authorized represantative ] O ssuotio 0 avtorzad epresenathe: e Issuerto LE autharized representatve. Issuac-oy Q1 authorized rearessniative. — £ Issuaco LE authorized represaniative ( Issued-by LE authorzed represntative. e T oor | Smtng st L el [ Anyone in the chain-of-authority can revoke the credential issued-by 4{ o ‘ [T e — them. This breaks the chain and thereby may invalidate any L | test4o OOR Person authorizations or attestations that are chained from their credential.

GLEIF vLEI Authorized Attestation Example Qualified VLEI Issuer (QVI) Credential Legal Entity (LE) Credential Official Organizational Role Authorization (OOR-Authz) Credential Official Organizational Role (OOR) Credential ‘ g SR et e oo ot Verifiable IXBRL Report Attestation (ViRA) L [R— Lt et mbmirnsin oot ‘ o [ | oy O auborzas rprseraie o008 lsuecis OOR Person them. This breaks the chain and thereby may invalidate any B authorzationsoratestatons tha e chaned from thfr credenil.

GLEIF vLEI Credential Example: Schema Edge OOR-Auth

Append-only verifiable data structures have strong security properties that simplify end-verifiablty & foster decentralization. Append-anly provides permissioress extensibility by downstream issuers, resenters, andfor verifiers Each ACDC has a universally-unique content based identifier with a universally-unique content based schema identifie. Fully decentralized name spacing. Custom fields are appended via chaining via one or more custom ACDCs defined by custom schema (type-isschema). No need for centralized permissioned name:space regstries to resolve name:space collsions. The purposes of a registry now become merely schema discovery o schema blessing for a given context or ecosyste. The reach of the registry i tuned to the reach of desired interoperabilty by the ecosystem participants. Human meaningful labels on SAIDs are local context only. Versioning is simplified because edges stil vertty if new schema are backwards compatible. (persistent data structure model) e [ e xistiog rields = J i schema [h ) 1 . (k roxisingilds © Custom it T e . [P weiens [ e L) et custom iz Bended - e Custom Schema Credental Chain o ]+ — [T

ACDC Summary Push the functionality envelope of “verifiable credentials” using minimally sufficient means tooling. Future looking features: SAIDS (agile self-referential content identifiers) Graduated Disclosure Contractually Protected Disclosure Chaining and Delegation Permissionless Extensibility Fully Decentralizable Zero-Trust via End-Verifiable Data Structures Multiple Serializations Scalability (text and binary streaming support) via CESR self-framing composable primitives and groups of primitives Minimally Sufficient Means Dumb Crypto (Digests and Digital Signatures) JSON and JSON Schema (composability features) Extensible Layered Model

KERI VDRs vs. Shared Ledger VDRs Most DID methods use a shared ledger (commonly referred to as a blockchain) for their VDR Typically, i order to interoperateall participants must use the same shared ledger or support multiple different DID methods, There are currently over 70 DID methods, Instead GLEIF has chosen to use: KERI based DID methods, KERI stands for Key Event Recelpt Infastructure. KERI based VDRs are ledger independent, .. not locked to a given ledger This provides a path for greater interaperabilty witho forcing particpants n the vLEl ecosystem to use the same shared ledger. AKERI VDR s called a key event log (KEL). It is 2 ryptographically verifiable signed hash chained data structure, a specialcass of verifable data Structure. Each KERI based identifer has s own decicatec KEL. The purpose of the KEL is to provide proof of the establishment of control authority over an dentifie. This provides cryptographically verifisble proo of the current set of autharitative keys for the dentifer. KERI dentifers are long cryptographic pseudo random strings of characters. They are sef <ertiying and self managing; AKER identifer s abstractly called an Autonomic Identifer (AID) because it is sef-certifying and self managing, A KERI DID is one concrete implementation of KERI AID. The same KERI prefix may control multile different DIDs s long as they share the same prefix. Fun Saqunce i i did:keri:prefix([:options] [/path] [?query] [#fragment] g Even aton vert. . } [ did:keri:ENGFEHS_cfDg8rilz-GDYDaCKVn6c10JaTZXXVXSHPRY neratn Evet alston Sert oston v Inerctin vt Roteon v nerin £t i vt

KERI Identifier KEL VDR Controls Verifiable Credential Registry TEL VDR AKERI KEL for a given identifier provides proof of authoritative key state at each event, The events are ordered. This ordering may be used to order transactions on some other VDR such as a Verifiable Credential Registry by attaching anchoring seals to KEL events: Seals include cryptographic digest of external transaction data. A seal binds the key-state of the anchoring event to the transaction event data anchored by the seal. The set of transaction events that determine the external registry state form a log called a Transaction Event Log (TEL) Transactions are signed with the authoritative keys determined by the key state n the KEL with the transaction seal. The transactions likewise contain a reference seal back to the key event authorizing the transaction. ‘This setup enables a KEL to control a TEL for any purpose. This includes what are commonly called “smart contracts”. ‘The TEL provides a cryptographic proof of registry state by reference to the corresponding controlling KEL. Any validator may therefore cryptographically verify the authoritative state of the regstry. Inthe case of the VLEI the associated TEL controls a vLE issuance and revocation regstry. e Ky Evrt Lo oKL Sy O b Tt n ity TEL. Ly o fo T Rogsry Tarsacn Evrt o Tarsscin ot e ol ton BT o G T K sm [T [0 e | Owwmn | Sme Sd [ Twdn ot S | opewin | S T en s | [ Tmwes (2 S | Opemn | Sme 3K S o T 3 S | Opewin | sub S | T e 4 S | Opean | s | S | T o5 S | openton | Sub

Registry with Separable VC Issuance-Revocation TELs Each VC may be uniquely identified with a SAID. Each VC also has a uniquely identified issuer using a KERI AID. This combination enables a separable registry of VC issuance-revocation state. The state may employ a cryptographic aggregation (such as an accumulator) for enhanced privacy ertr Koy EvortLog e Contor dortiod Vel rodant Rgity Koy Tansaton o Tarecion EariLogs S sae S e e o] ke Traracien Evors Soparslo V5 Tansaction vt Log ™ S Opoaors VCSas T on [ soa T} Jo[ soa | how o |, Soa | T 7] Sl | ode oman Tzl e | s | T Separsla VTt v Lo BRI ™ Semk Cpmtos VCSe Jo] s | bee hens |, e R ey [l s | e Renes Se |- Tonsacin Soparsla V& Tasadtion v Log ™ S Opeons VCSe (o] s e e | b sl e ook

Least Disclosure Principle of Least Disclosure AACDCs are designed to satisfy the principle of least disclosure. The system should disclose only the minimum amount of information about a given party needed to facilitate a transaction and no more. Partial Disclosure Compactness Chain-link Confidentiality Selective Disclosure Unbundling Bulk-issuance Mechanisms: Compact via SAID over content Blinded via SAID over content with embedded UUID (salty-nonce) Unbundled via Aggregate of bundle of blinded content Uncorrelatable via bulk issued blinded content

Three Party Exploitation Model

First-Party = Discloser of data. Second-Party = Disclosee of data received from First Party (Discloser) Third-Party = Observer of data disclosed by First Party (Discloser) to Second Party (Disclosee). Second-Party (Disclosee) Exploitation it permsioned coneaton

no contractual restrictions on the use of disclosed data. cxplist permissoned coneaion

{5025 parmitod oy contct explicit unpermissioned correlation with other second parties or third parties. Third-Party (Observer) Exploitation implt permssioned condaton

P conrasualrosctons o s of coserod et explicit unpermissioned correlation via collusion with second parties.

Palius ss i ideion of socon pary conract

Contractually Protected Disclosure Ricardian Contracts: Chain-link Confidentiality o oo s s e Consent, Waiver, Terms-of-use, Remuneration, etc. — 2 — oo — 028 = o3 ~o %o 8 °3

Chain-Link Confidentiality A chain-link confidentiality regime contractually links the disclosure of information to obligations to protect that information as the information moves downstream. The system focuses on the relationships not only between the discloser of information and the initial recipient but also between the initial recipient and subsequent recipients. Through the use of contracts, this approach links recipients of information as in a chain, with each subsequent recipient bound by the same obligation to protect the information. These chain contracts contain at least three kinds of terms: 1) obligations and restrictions on the use of the disclosed information; 2) requirements to bind future recipients to the same obligations and restrictions; and 3) requirements to perpetuate the contractual chain. This approach creates a system for the permissible dissemination of information. It protects Disclosers by ensuring that the recipient’s obligation to safeguard information is extended to third parties.

Contractual Exchange Discloser provides a non-repudiable Offer with verifiable metadata (sufficient partial disclosure) which includes any terms or restrictions on use. Disclosee verifies Offer against composed schema and metadata adherence to desired data. Disclosee provides non-repudiable Accept of terms that are contingent on compliant disclosure. Discloser provides non-repudiable Disclosure with sufficient compliant detail. Disclosee verifies Disclosure using decomposed schema and adherence of disclosed data to Offer. Disclosee may now engage in permissioned use and carries liability as a deterrent against unpermissioned use.