Authentic Chained Data Container ACDC Verifiable Data Structures (Graphs) that support Authenticatable Attestations & Credentials Samuel M. Smith Ph.D. sam@prosapien.com 2022/09/15
Specification Documentation: ACOC ntenet et (TP -167F) btesiigitub cominsoveriohswg acdcspedicaion ACOC or Muggles pscocs google.comprsentaionldHmOTEZS S AWIEEN UMD AN TodsIdesid gibesesa 0.0 Resources on K and ACOC cpserionefriesourcest GLEIF VLI Credetils CibalLegal Entitydenfer Foundation) (50 L1 specfcaton pshenn it orglenbcintrocucing he verftie kit Community: (meetings, open source code, IETF internet drafts) Acoc working Group ek rstoveri.ongsplen OMEIACDC28Authentc ChanedDatas Cotaineriag TaskiForce Relted et rafts pslgtub.comeboTusthert
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 (property graph 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 Pivate Compact Variant
Basic ACDC JSON Schema
Uncompacted Private Attribute Section
"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 TopLeviks C e et 15335 i g, e L am | Rt nbe s e it o BB LSRG S RS T o o Ui Do i e, 58 17 o S e s ok i i et v b S o e b 13 58 et i 0 5 oterridas e Bt oyttt R ety 1 R o o e T Rt U st s i3 e, T A i 7 i SR o e ATt A 0 T AL NS A ) = e e e S o e ety el i et 1 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 is universally uniquely referenced by its SAID. * Authenticatable decentralizable distributed graph fragment that may be communicated securely. + Graph fragments use SAIDs to (hash-chain) 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= o ettt - G node properiies. " ‘edge properties . -
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 (QV1) 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 [ — L e — Ity GLEF s pste [ e — i v ( [P —— ; SR — [ — —— ‘ on ‘ S — — [ e ———— [ —— L ecS— ) oo | ety o s mmene et 0OR Peon
GLEIF vLEI Authorized Attestation Example Qualified VLEI Issuer (QV1) Credential Legal Entity (LE) Credential Official Organizational Role Authorization (OOR-AuthZ) Credential Official Organizational Role (OOR) Credential Verifiable IXBRL Report Attestation (ViRA) on | oo E— L | m—— R
GLEIF vLEI Credential Example: Schema Edge OOR-Auth
Append-anly verifiable data structures have strong security properties that simplify end-verifiablty & foster decentralization. Append-anly provides permissioress extensibility by downstream issuers, presenters, 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 or schema blessing for a given context or ecosystern. The reach of the regitry 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 xisting rields = J i schema [h ) 1 . (k roxisingilds © Cusom it T e . [P weiens [ e L) et custom itz Bended - e Custom Schema Credendal 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 Zero-Trust End Verifiability via 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
Interoperability Through Layering The ACDC/KERI stack is opinionated about security with very precise strong security properties Fully decentralizable, distributable, zero-trust, end-verifiable mechanisms based on authenticatable extensible verifiable data structures (append-only hash chained signed) Mashups of security features that do not cleanly separate security properties are antithetical to the ACDC/KERI stack. Interoperable security first, then interoperable semantics for upper layers of the application stack. ACDCs could be used as a secure conveyance for other representations that appear as an opaque payload in the ACDC. ACDCs could be a blessed trust spanning layer for W3C VCs for those who want its security properties
ACDC Community Interoperability Ask Enable one-to-one mappings between ACDCs and other data models and representations without forcing ACDCs to use syntax from other data models and representations. ACDCs use JSON-Schema with JSON, CBOR, MGPK, and CESR serializations, compact labels & CESR Primitives. CESR primitives can be mapped one-to-one to JWT primitives. ACDC normative field labels can be mapped one-to-one to their equivalents in other representations. Allow JSON Schema (ACDCs need composition operators from JSON Schema). Not asking to replace JSON-LD but be allowed to co-exist with JSON-LD. JSON is well just JSON. Please no MUST have non-JSON artifacts (@context).
Questions?
Least Disclosure Principle of Least Disclosure ACDCs 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 implicit permissioned correlation.
no contractual restrictions on the use of disclosed data. explicit permissioned correlation.
use as permitted by contract explicit unpermissioned correlation with other second parties o third parties.
malicious use in violation of contract Third-Party (Observer) Exploitation implicit permissioned correlation.
no contractual restrictions on use of observed data. ‘explicit unpermissioned correlation via collusion with second parties.
malicious use in violation of second party contract
Contractually Protected Disclosure
Ricardian Contracts:
Chain-link Confidentiality o
A e AN -
Consent, Waiver, Terms-of-use, Remuneration, etc. — 7 e o8 = o2 = o0t e %o 8 o3
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.
IPEX: Issuance & Presentation Exchange protocol i xchange et providesdisciosre o cne o mere ACOCs bt Disclserand isclse A presentation exchange is the process by which authenticatable information may be exchanged between two parties, namely, the Discloser andDsclose acoc Ty dat s stance cocretly efnedy the ACOC spedfcaton. Discloser: An ACDC ina disclosure is disclosed by the Discloser. Disclosee: An ACDCina disclosure is disclosed to the Disclosee. e An ACDC s issued by the Issuer. The Issuer identifier (AID) appears in the top level of the ACDC. An ACDC s optionally issued to the Issuee. When present, the Issuee identifier (AID) appears at the top level of the attribute section or in the ot 5ttt v fthe st seckon f e ACDC. Each ACOC MUSThve anfserand AY hove s