< draft-ssmith-acdc-00.txt		draft-ssmith-acdc-01.txt >
	TODO Working Group S. Smith		TODO Working Group S. Smith
	Internet-Draft ProSapien LLC		Internet-Draft ProSapien LLC
	Intended status: Informational 5 April 2022		Intended status: Informational 25 April 2022
	Expires: 7 October 2022		Expires: 27 October 2022
	Authentic Chained Data Containers (ACDC)		Authentic Chained Data Containers (ACDC)
	draft-ssmith-acdc-00		draft-ssmith-acdc-01
	Abstract		Abstract
	An authentic chained data container (ACDC) [ACDC_ID][ACDC_WP][VCEnh]		An authentic chained data container (ACDC) [ACDC_ID][ACDC_WP][VCEnh]
	is an IETF [IETF] internet draft focused specification being		is an IETF [IETF] internet draft focused specification being
	incubated at the ToIP (Trust over IP) foundation [TOIP][ACDC_TF]. An		incubated at the ToIP (Trust over IP) foundation [TOIP][ACDC_TF]. An
	ACDC is a variant of the W3C Verifiable Credential (VC) specification		ACDC is a variant of the W3C Verifiable Credential (VC) specification
	[W3C_VC]. The W3C VC specification depends on the W3C DID		[W3C_VC]. The W3C VC specification depends on the W3C DID
	(Decentralized IDentifier) specification [W3C_DID]. A major use case		(Decentralized IDentifier) specification [W3C_DID]. A major use case
	for the ACDC specification is to provide GLEIF vLEIs (verifiable		for the ACDC specification is to provide GLEIF vLEIs (verifiable
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	specification. These include CESR [CESR_ID], SAID [SAID_ID], PTEL		specification. These include CESR [CESR_ID], SAID [SAID_ID], PTEL
	[PTEL_ID], CESR-Proof [Proof_ID], IPEX [IPEX_ID], did:keri [DIDK_ID],		[PTEL_ID], CESR-Proof [Proof_ID], IPEX [IPEX_ID], did:keri [DIDK_ID],
	and OOBI [OOBI_ID]. Some of the major distinguishing features of		and OOBI [OOBI_ID]. Some of the major distinguishing features of
	ACDCs include normative support for chaining, use of composable JSON		ACDCs include normative support for chaining, use of composable JSON
	Schema [JSch][JSchCp], multiple serialization formats, namely, JSON		Schema [JSch][JSchCp], multiple serialization formats, namely, JSON
	[JSON][RFC4627], CBOR [CBOR][RFC8949], MGPK [MGPK], and CESR		[JSON][RFC4627], CBOR [CBOR][RFC8949], MGPK [MGPK], and CESR
	[CESR_ID], support for Ricardian contracts [RC], support for chain-		[CESR_ID], support for Ricardian contracts [RC], support for chain-
	link confidentiality [CLC], a well defined security model derived		link confidentiality [CLC], a well defined security model derived
	from KERI [KERI][KERI_ID], _compact_ formats for resource constrained		from KERI [KERI][KERI_ID], _compact_ formats for resource constrained
	applications, simple _partial disclosure_ mechanisms and simple		applications, simple _partial disclosure_ mechanisms and simple
	_selective disclosure_ mechanisms.		_selective disclosure_ mechanisms. ACDCs provision data using a
			synergy of provenance, protection, and performance.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 7 October 2022.
			This Internet-Draft will expire on 27 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. ACDC Fields . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. ACDC Fields . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Field Label Table . . . . . . . . . . . . . . . . . . . . 6		2.1. Field Label Table . . . . . . . . . . . . . . . . . . . . 6
	2.2. Compact Labels . . . . . . . . . . . . . . . . . . . . . 7		2.2. Compact Labels . . . . . . . . . . . . . . . . . . . . . 8
	2.3. Version String Field . . . . . . . . . . . . . . . . . . 7		2.3. Version String Field . . . . . . . . . . . . . . . . . . 8
	2.4. AID (Autonomic IDentifier) Fields . . . . . . . . . . . . 8		2.4. AID (Autonomic IDentifier) Fields . . . . . . . . . . . . 9
	2.4.1. Namespaced AIDs . . . . . . . . . . . . . . . . . . . 8		2.4.1. Namespaced AIDs . . . . . . . . . . . . . . . . . . . 9
	2.5. SAID (Self-Addressing IDentifier) Fields . . . . . . . . 9		2.5. SAID (Self-Addressing IDentifier) Fields . . . . . . . . 10
	2.6. Selectively Disclosable Attribute Aggregate Field . . . . 9		2.6. Selectively Disclosable Attribute Aggregate Field . . . . 10
	2.7. UUID (Universally Unique IDentifier) Fields . . . . . . . 10		2.7. UUID (Universally Unique IDentifier) Fields . . . . . . . 11
	2.8. Full, Partial, and Selective Disclosure . . . . . . . . . 10		2.8. Graduated Disclosure and Contractually Protected
	3. Schema Section . . . . . . . . . . . . . . . . . . . . . . . 11		Disclosure . . . . . . . . . . . . . . . . . . . . . . . 11
	3.1. Schema is Type . . . . . . . . . . . . . . . . . . . . . 12		2.8.1. Types of Graduated Disclosure . . . . . . . . . . . . 13
	3.2. Schema ID Field Label . . . . . . . . . . . . . . . . . . 12		3. Schema Section . . . . . . . . . . . . . . . . . . . . . . . 14
	3.3. Static Schema . . . . . . . . . . . . . . . . . . . . . . 13		3.1. Type-is-Schema . . . . . . . . . . . . . . . . . . . . . 14
	3.4. Schema Dialect . . . . . . . . . . . . . . . . . . . . . 15		3.2. Schema ID Field Label . . . . . . . . . . . . . . . . . . 15
	3.5. Schema Availablity . . . . . . . . . . . . . . . . . . . 16		3.3. Static (Immutable) Schema . . . . . . . . . . . . . . . . 15
	3.6. Composable JSON Schema . . . . . . . . . . . . . . . . . 16		3.4. Schema Dialect . . . . . . . . . . . . . . . . . . . . . 18
	4. ACDC Variants . . . . . . . . . . . . . . . . . . . . . . . . 18		3.5. Schema Availablity . . . . . . . . . . . . . . . . . . . 18
	4.1. Public ACDC . . . . . . . . . . . . . . . . . . . . . . . 18		3.6. Composable JSON Schema . . . . . . . . . . . . . . . . . 19
	4.2. Private ACDC . . . . . . . . . . . . . . . . . . . . . . 18		4. ACDC Variants . . . . . . . . . . . . . . . . . . . . . . . . 21
	4.3. Metadata ACDC . . . . . . . . . . . . . . . . . . . . . . 19		4.1. Public ACDC . . . . . . . . . . . . . . . . . . . . . . . 21
	5. Unpermissioned Exploitation of Data . . . . . . . . . . . . . 20		4.2. Private ACDC . . . . . . . . . . . . . . . . . . . . . . 21
	5.1. Principle of Least Disclosure . . . . . . . . . . . . . . 20		4.3. Metadata ACDC . . . . . . . . . . . . . . . . . . . . . . 22
	5.2. Three Party Exploitation Model . . . . . . . . . . . . . 21		5. Unpermissioned Exploitation of Data . . . . . . . . . . . . . 23
	5.2.1. Second-Party (Disclosee) Exploitation . . . . . . . . 21		5.1. Graduated Disclosure and the Principle of Least
	5.2.2. Third-Party (Observer) Exploitation . . . . . . . . . 21		Disclosure . . . . . . . . . . . . . . . . . . . . . . . 23
	5.3. Chain-link Confidentiality Exchange . . . . . . . . . . . 22		5.2. Exploitation Protection Mechanisms . . . . . . . . . . . 23
	6. Compact ACDC . . . . . . . . . . . . . . . . . . . . . . . . 22		5.3. Three Party Exploitation Model . . . . . . . . . . . . . 24
	6.1. Compact Public ACDC . . . . . . . . . . . . . . . . . . . 22		5.3.1. Second-Party (Disclosee) Exploitation . . . . . . . . 24
	6.2. Compact Private ACDC . . . . . . . . . . . . . . . . . . 23		5.3.2. Third-Party (Observer) Exploitation . . . . . . . . . 24
	6.2.1. Compact Private ACDC Schema . . . . . . . . . . . . . 23		5.4. Chain-link Confidentiality Exchange . . . . . . . . . . . 25
	7. Attribute Section . . . . . . . . . . . . . . . . . . . . . . 24		6. Compact ACDC . . . . . . . . . . . . . . . . . . . . . . . . 25
	7.1. Public-Attribute ACDC . . . . . . . . . . . . . . . . . . 25		6.1. Compact Public ACDC . . . . . . . . . . . . . . . . . . . 25
	7.2. Public Uncompacted Attribute Section Schema . . . . . . . 26		6.2. Compact Private ACDC . . . . . . . . . . . . . . . . . . 26
			6.2.1. Compact Private ACDC Schema . . . . . . . . . . . . . 26
			7. Attribute Section . . . . . . . . . . . . . . . . . . . . . . 27
			7.1. Public-Attribute ACDC . . . . . . . . . . . . . . . . . . 28
			7.2. Public Uncompacted Attribute Section Schema . . . . . . . 29
	7.3. Composed Schema for both Public Compact and Uncompacted		7.3. Composed Schema for both Public Compact and Uncompacted
	Attribute Section Variants . . . . . . . . . . . . . . . 27		Attribute Section Variants . . . . . . . . . . . . . . . 30
	7.4. Private-Attribute ACDC . . . . . . . . . . . . . . . . . 29		7.4. Private-Attribute ACDC . . . . . . . . . . . . . . . . . 32
	7.4.1. Composed Schema for Both Compact and Uncompacted		7.4.1. Composed Schema for Both Compact and Uncompacted
	Private-Attribute ACDC . . . . . . . . . . . . . . . 30		Private-Attribute ACDC . . . . . . . . . . . . . . . 33
	7.5. Untargeted ACDC . . . . . . . . . . . . . . . . . . . . . 31		7.5. Untargeted ACDC . . . . . . . . . . . . . . . . . . . . . 34
	7.6. Targeted ACDC . . . . . . . . . . . . . . . . . . . . . . 32		7.6. Targeted ACDC . . . . . . . . . . . . . . . . . . . . . . 35
	8. Edge Section . . . . . . . . . . . . . . . . . . . . . . . . 33		8. Edge Section . . . . . . . . . . . . . . . . . . . . . . . . 36
	8.1. Globally Distributed Secure Graph Fragments . . . . . . . 35		8.1. Globally Distributed Secure Graph Fragments . . . . . . . 38
	8.2. Compact Edge . . . . . . . . . . . . . . . . . . . . . . 35		8.2. Compact Edge . . . . . . . . . . . . . . . . . . . . . . 38
	8.3. Private Edge . . . . . . . . . . . . . . . . . . . . . . 36		8.3. Private Edge . . . . . . . . . . . . . . . . . . . . . . 39
	8.4. Simple Compact Edge . . . . . . . . . . . . . . . . . . . 36		8.4. Simple Compact Edge . . . . . . . . . . . . . . . . . . . 39
	8.5. Node Discovery . . . . . . . . . . . . . . . . . . . . . 37		8.5. Operations on Edges and Edge-Groups . . . . . . . . . . . 40
	9. Rule Section . . . . . . . . . . . . . . . . . . . . . . . . 37		8.5.1. Label Types . . . . . . . . . . . . . . . . . . . . . 40
	9.1. Compact Clauses . . . . . . . . . . . . . . . . . . . . . 39		8.5.2. Block Types . . . . . . . . . . . . . . . . . . . . . 40
	9.2. Private Clause . . . . . . . . . . . . . . . . . . . . . 39		8.5.3. Operator, o, Field . . . . . . . . . . . . . . . . . 41
	9.3. Simple Compact Clause . . . . . . . . . . . . . . . . . . 40		8.5.4. Weight, w, field. . . . . . . . . . . . . . . . . . . 41
	9.4. Clause Discovery . . . . . . . . . . . . . . . . . . . . 40		8.5.5. Special Unary Operators . . . . . . . . . . . . . . . 42
	10. Informative Example of an ACDC . . . . . . . . . . . . . . . 41		8.5.6. Defaults for missing operators . . . . . . . . . . . 42
	10.1. Public Compact Variant . . . . . . . . . . . . . . . . . 41		8.5.7. Examples . . . . . . . . . . . . . . . . . . . . . . 43
	10.2. Public Uncompacted Variant . . . . . . . . . . . . . . . 41		8.5.8. Explicit AND . . . . . . . . . . . . . . . . . . . . 43
	10.3. Composed Schema that Supports both Public Compact and		8.5.9. Unary I2I . . . . . . . . . . . . . . . . . . . . . . 44
	Uncompacted Variants . . . . . . . . . . . . . . . . . . 42		8.5.10. Unary NI2I . . . . . . . . . . . . . . . . . . . . . 44
	11. Selective Disclosure . . . . . . . . . . . . . . . . . . . . 48		8.5.11. Nested Edge-Group . . . . . . . . . . . . . . . . . . 44
	11.1. Selectively Disclosable Attribute ACDC . . . . . . . . . 50		8.5.12. vLEI ECR issued by QVI example . . . . . . . . . . . 45
	11.1.1. Blinded Attribute Array . . . . . . . . . . . . . . 51		8.5.13. Commentary . . . . . . . . . . . . . . . . . . . . . 46
	11.1.2. Composed Schema for Selectively Disclosable Attribute		8.6. Node Discovery . . . . . . . . . . . . . . . . . . . . . 47
	Section . . . . . . . . . . . . . . . . . . . . . . . 52		9. Rule Section . . . . . . . . . . . . . . . . . . . . . . . . 47
	11.1.3. Inclusion Proof via Aggregated List Digest . . . . . 55		9.1. Compact Clauses . . . . . . . . . . . . . . . . . . . . . 49
	11.1.4. Inclusion Proof via Merkle Tree Root Digest . . . . 58		9.2. Private Clause . . . . . . . . . . . . . . . . . . . . . 49
	11.1.5. Hierarchical Derivation at Issuance of Selectively		9.3. Simple Compact Clause . . . . . . . . . . . . . . . . . . 50
	Disclosable Attribute ACDCs . . . . . . . . . . . . . 58		9.4. Clause Discovery . . . . . . . . . . . . . . . . . . . . 50
	11.2. Bulk-Issued Private ACDCs . . . . . . . . . . . . . . . 59		10. Disclosure-Specific (Bespoke) Issued ACDCs . . . . . . . . . 51
	11.3. Basic Bulk Issuance . . . . . . . . . . . . . . . . . . 61		10.1. Example Bespoke Issued ACDC . . . . . . . . . . . . . . 51
	11.3.1. Inclusion Proof via Merkle Tree . . . . . . . . . . 66
	11.3.2. Bulk Issuance of Private ACDCs with Unique Issuee		11. Informative Examples . . . . . . . . . . . . . . . . . . . . 52
	AIDs . . . . . . . . . . . . . . . . . . . . . . . . 67		11.1. Public ACDC with Compact and Uncompated Variants . . . . 52
	11.4. Independent TEL Bulk-Issued ACDCs . . . . . . . . . . . 67		11.1.1. Public Uncompacted Variant . . . . . . . . . . . . . 53
	12. Appendix: Cryptographic Strength and Security . . . . . . . . 68		11.1.2. Composed Schema that Supports both Public Compact and
	12.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 69		Uncompacted Variants . . . . . . . . . . . . . . . . 54
	12.2. Information Theoretic Security and Perfect Security . . 70		12. Selective Disclosure . . . . . . . . . . . . . . . . . . . . 60
	13. Conventions and Definitions . . . . . . . . . . . . . . . . . 70		12.1. Selectively Disclosable Attribute ACDC . . . . . . . . . 62
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 70		12.1.1. Blinded Attribute Array . . . . . . . . . . . . . . 63
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70		12.1.2. Composed Schema for Selectively Disclosable Attribute
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 70		Section . . . . . . . . . . . . . . . . . . . . . . . 64
	16.1. Normative References . . . . . . . . . . . . . . . . . . 70		12.1.3. Inclusion Proof via Aggregated List Digest . . . . . 67
	16.2. Informative References . . . . . . . . . . . . . . . . . 72		12.1.4. Inclusion Proof via Merkle Tree Root Digest . . . . 70
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 76		12.1.5. Hierarchical Derivation at Issuance of Selectively
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 76		Disclosable Attribute ACDCs . . . . . . . . . . . . . 70
			12.2. Bulk-Issued Private ACDCs . . . . . . . . . . . . . . . 71
			12.3. Basic Bulk Issuance . . . . . . . . . . . . . . . . . . 73
			12.3.1. Inclusion Proof via Merkle Tree . . . . . . . . . . 78
			12.3.2. Bulk Issuance of Private ACDCs with Unique Issuee
			AIDs . . . . . . . . . . . . . . . . . . . . . . . . 79
			12.4. Independent TEL Bulk-Issued ACDCs . . . . . . . . . . . 79
			13. Appendix: Performance and Scalability . . . . . . . . . . . . 81
			14. Appendix: Cryptographic Strength and Security . . . . . . . . 81
			14.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 81
			14.2. Information Theoretic Security and Perfect Security . . 82
			15. Conventions and Definitions . . . . . . . . . . . . . . . . . 83
			16. Security Considerations . . . . . . . . . . . . . . . . . . . 83
			17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
			18. References . . . . . . . . . . . . . . . . . . . . . . . . . 83
			18.1. Normative References . . . . . . . . . . . . . . . . . . 83
			18.2. Informative References . . . . . . . . . . . . . . . . . 85
			Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 89
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 89
	1. Introduction		1. Introduction
	The primary purpose of the ACDC protocol is to provide granular		One primary purpose of the ACDC protocol is to provide granular
	provenanced proof-of-authorship (authenticity) of their contained		provenanced proof-of-authorship (authenticity) of their contained
	data via a tree or chain of linked ACDCs (technically a directed		data via a tree or chain of linked ACDCs (technically a directed
	acyclic graph or DAG). Similar to the concept of a chain-of-custody,		acyclic graph or DAG). Similar to the concept of a chain-of-custody,
	ACDCs provide a verifiable chain of proof-of-authorship of the		ACDCs provide a verifiable chain of proof-of-authorship of the
	contained data. With a little additional syntactic sugar, this		contained data. With a little additional syntactic sugar, this
	primary facility of chained (treed) proof-of-authorship		primary facility of chained (treed) proof-of-authorship
	(authenticity) is extensible to a chained (treed) verifiable		(authenticity) is extensible to a chained (treed) verifiable
	authentic proof-of-authority (proof-of-authorship-of-authority). A		authentic proof-of-authority (proof-of-authorship-of-authority). A
	proof-of-authority may be used to provide verifiable authorizations		proof-of-authority may be used to provide verifiable authorizations
	or permissions or rights or credentials. A chained (treed) proof-of-		or permissions or rights or credentials. A chained (treed) proof-of-
	authority enables delegation of authority and delegated		authority enables delegation of authority and delegated
	authorizations.		authorizations. These proofs of authorship and/or authority provide
			provenance of an ACDC itself and by association any data that is so
			conveyed.
	The dictionary definition of *_credential_* is _evidence of		The dictionary definition of *_credential_* is _evidence of
	authority, status, rights, entitlement to privileges, or the like_.		authority, status, rights, entitlement to privileges, or the like_.
	Appropriately structured ACDCs may be used as credentials when their		Appropriately structured ACDCs may be used as credentials when their
	semantics provide verifiable evidence of authority. Chained ACDCs		semantics provide verifiable evidence of authority. Chained ACDCs
	may provide delegated credentials.		may provide delegated credentials.
	Chains of ACDCs that merely provide proof-of-authorship		Chains of ACDCs that merely provide proof-of-authorship
	(authenticity) of data may be appended to chains of ACDCs that		(authenticity) of data may be appended to chains of ACDCs that
	provide proof-of-authority (delegation) to enable verifiable		provide proof-of-authority (delegation) to enable verifiable
	skipping to change at page 6, line 51 ¶		skipping to change at page 7, line 37 ¶
	+-------+------------+-----------------------------------------+		+-------+------------+-----------------------------------------+
	| r | Rule | Either the SAID a block of rules or the |		| r | Rule | Either the SAID a block of rules or the |
	| | | block itself. |		| | | block itself. |
	+-------+------------+-----------------------------------------+		+-------+------------+-----------------------------------------+
	| n | Node | SAID of another ACDC as the terminating |		| n | Node | SAID of another ACDC as the terminating |
	| | | point of a directed edge that connects |		| | | point of a directed edge that connects |
	| | | the encapsulating ACDC node to the |		| | | the encapsulating ACDC node to the |
	| | | specified ACDC node as a fragment of a |		| | | specified ACDC node as a fragment of a |
	| | | distributed property graph (PG). |		| | | distributed property graph (PG). |
	+-------+------------+-----------------------------------------+		+-------+------------+-----------------------------------------+
			| o | Operator | Either unary operator on edge or m-ary |
			| | | operator on edge-group in edge section. |
			| | | Enables expressing of edge logic on |
			| | | edge subgraph. |
			+-------+------------+-----------------------------------------+
			| w | Weight | Edge weight property that enables |
			| | | default property for directed weighted |
			| | | edges and operators on directed |
			| | | weighted edges. |
			+-------+------------+-----------------------------------------+
	| l | Legal | Text of Ricardian contract clause. |		| l | Legal | Text of Ricardian contract clause. |
	| | Language | |		| | Language | |
	+-------+------------+-----------------------------------------+		+-------+------------+-----------------------------------------+
	Table 1		Table 1
	2.2. Compact Labels		2.2. Compact Labels
	The primary field labels are compact in that they use only one or two		The primary field labels are compact in that they use only one or two
	characters. ACDCs are meant to support resource-constrained		characters. ACDCs are meant to support resource-constrained
	skipping to change at page 10, line 31 ¶		skipping to change at page 11, line 31 ¶
	of the SAID. Thus an adversary could successfully discover via brute		of the SAID. Thus an adversary could successfully discover via brute
	force the exact block by creating digests of all the elements of the		force the exact block by creating digests of all the elements of the
	power set which may be small enough to be computationally feasible		power set which may be small enough to be computationally feasible
	instead of inverting the SAID itself. Sufficient entropy in the u		instead of inverting the SAID itself. Sufficient entropy in the u
	field ensures that the cardinality of the power set allowed by the		field ensures that the cardinality of the power set allowed by the
	schema is at least as great as the entropy of the SAID digest		schema is at least as great as the entropy of the SAID digest
	algorithm itself.		algorithm itself.
	A UUID, u field may optionally appear in any block (field map) at any		A UUID, u field may optionally appear in any block (field map) at any
	level of an ACDC. Whenever a block in an ACDC includes a UUID, u,		level of an ACDC. Whenever a block in an ACDC includes a UUID, u,
	field then it's associated SAID, d, field makes a blinded commitment		field then its associated SAID, d, field makes a blinded commitment
	to the contents of that block. The UUID, u, field is the blinding		to the contents of that block. The UUID, u, field is the blinding
	factor. This makes that block securely partially-disclosable or even		factor. This makes that block securely partially disclosable or even
	selectively-disclosable notwithstanding disclosure of the associated		selectively disclosable notwithstanding disclosure of the associated
	schema of the block. The block contents can only be discovered given		schema of the block. The block contents can only be discovered given
	disclosure of the included UUID field. Likewise when a UUID, u,		disclosure of the included UUID field. Likewise when a UUID, u,
	field appears at the top level of an ACDC then that top-level SAID,		field appears at the top level of an ACDC then that top-level SAID,
	d, field makes a blinded commitment to the contents of the whole ACDC		d, field makes a blinded commitment to the contents of the whole ACDC
	itself. Thus the whole ACDC, not merely some block within the ACDC,		itself. Thus the whole ACDC, not merely some block within the ACDC,
	may be disclosed in a privacy-preserving (correlation minimizing)		may be disclosed in a privacy-preserving (correlation minimizing)
	manner.		manner.
	2.8. Full, Partial, and Selective Disclosure		2.8. Graduated Disclosure and Contractually Protected Disclosure
			ACDC leverages several closely related mechanisms for what can be
			called *_graduated disclosure_*. _Graduated disclosure_ enables
			adherence to the principle of least disclosure which is expressed as
			follows:
			The system should disclose only the minimum amount of information
			about a given party needed to facilitate a transaction and no
			more. [IDSys]
			To clarify, _graduated disclosure_ enables a potential Discloser to
			follow the principle of _least disclosure_ by providing the least
			amount of information i.e. partial, incomplete, or uncorrelatable
			information needed to further a transaction.
			The important insight is that one type of transaction enabled by
			least disclosure is a transaction that specifically enables further
			disclosure. In other words, disclose enough to enable more
			disclosure which in turn may enable even more disclosure. This is
			the essence of _graduated disclosure_. This progression of successive
			least graduated disclosures to enable a transaction that itself
			enables a farther least graduated disclosure forms a recursive loop
			of least disclosure enabled transactions. In other words, the
			principle of least disclosure may be applied recursively.
			A type of transaction that leverages _graduated disclosure_ to enable
			further disclosure we call a *_contractually protected disclosure_*
			transaction. In a contractually protected disclosure, the potential
			Discloser first makes an offer using the least (partial) disclosure
			of some information about other information to be disclosed (full
			disclosure) contingent on the potential Disclosee first agreeing to
			the contractual terms provided in the offer. The contractual terms
			could, for example, limit the disclosure to third parties of the yet
			to be disclosed information. But those contractual terms may also
			include provisions that protect against liability or other concerns
			not merely disclosure to third parties.
			One special case of a _contractually protected disclosure_ is a
			*_chain-link confidential disclosure_* [CLC].
			Another special case of _contractually protected disclosure_ is a
			*_contingent-disclosure_*. In a _contingent disclosure_ some
			contingency is specified in the rule section that places an
			obligation by some party to make a disclosure when the contingency is
			satisfied. This might be recourse given the breach of some other
			term of the contract. When that contingency is met then the
			contingent disclosure MUST be made by the party whose responsibility
			it is to satisfy that disclosure obligation. The responsible party
			may be the Discloser of the ACDC or it may be some other party such
			as an escrow agent. The contingent disclosure clause may reference a
			cryptographic commitment to a private ACDC or private attribute ACDC
			(partial disclosure) that satisfies via its full disclosure the
			contingent disclosure requirement. Contingent disclosure may be used
			to limit the actual disclosure of personally identifying information
			(PII) to a just-in-time, need-to-know basis (i.e upon the
			contingency) and not a priori. As long as the Discloser and
			Disclosee trust the escrow agent and the verifiability of the
			committment, there is no need to disclose PII about the discloser in
			order to enable a transaction, but merely an agreement to the terms
			of the contingency. This enables something called *_latent
			accountability_*. Recourse via PII is latent in the contingent
			disclosure but is not ever realized (actualized) until recourse is
			truly needed. The minimizes inadvertent leakage while protecting the
			Disclosee.
			2.8.1. Types of Graduated Disclosure
			ACDCs employ three specific closely related types of _graduated
			disclosure_. These are *_compact disclosure_*, *_partial
			disclosure_*, and *_selective disclosure_*. The mechanism for
			_compact disclosure_ is a cryptographic digest of the content
			expressed in the form of a SAID of that content. Both partial and
			selective disclosure rely on the compact disclosure of content that
			is also cryptographically blinded or hidden. Content in terms of an
			ACDC means a block (field map or field map array).
	The difference between *_partial disclosure_* and *_selective		The difference between *_partial disclosure_* and *_selective
	disclosure_* of a given field map is determined by the		disclosure_* of a given block is determined by the correlatability of
	correlatability of the disclosed field(s) after *_full disclosure_*		the disclosed field(s) after *_full disclosure_* of the detailed
	of the detailed field value with respect to its enclosing block (map		field value with respect to its enclosing block (field map or field
	or array of fields). A _partially disclosable_ field becomes		map array). A _partially disclosable_ field becomes correlatable
	correlatable after _full disclosure_. Whereas a _selectively		after _full disclosure_. Whereas a _selectively disclosable_ field
	disclosable_ field may be excluded from the _full disclosure_ of any		may be excluded from the _full disclosure_ of any other _selectively
	other _selectively disclosable_ fields in the _selectively		disclosable_ fields in the _selectively disclosable_ block (usually a
	disclosable_ block (array). After such _selective disclosure_, the		field map array). After such _selective disclosure_, the selectively
	selectively disclosed fields are not correlatable to the so-far		disclosed fields are not correlatable to the so-far undisclosed but
	undisclosed but selectively disclosable fields in that block.		selectively disclosable fields in that block (field map array).
	When used in the context of _selective disclosure_, _full disclosure_		When used in the context of _selective disclosure_, _full disclosure_
	means detailed disclosure of the selectively disclosed attributes not		means detailed disclosure of the selectively disclosed attributes not
	detailed disclosure of all selectively disclosable attributes.		detailed disclosure of all selectively disclosable attributes.
	Whereas when used in the context of _partial disclosure_, _full		Whereas when used in the context of _partial disclosure_, _full
	disclosure_ means detailed disclosure of the field map that was so		disclosure_ means detailed disclosure of the field map that was so
	far only partially disclosed.		far only partially disclosed.
	_Partial disclosure_ is an essential mechanism needed to support both		_Partial disclosure_ is an essential mechanism needed to support both
	performant exchange of information and chain-link confidentiality on		performant exchange of information and contractually protected
	exchanged information [CLC]. The exchange of only the SAID of a		disclosure such as chain-link confidentiality on exchanged
	given field map is a type of _partial disclosure_. Another type of		information [CLC]. The exchange of only the SAID of a given field
	_partial disclosure_ is the disclosure of validatable metadata about		map is a type of _partial disclosure_. Another type of _partial
	a detailed field map e.g. the schema of a field map.		disclosure_ is the disclosure of validatable metadata about a
			detailed field map e.g. the schema of a field map.
	The SAID of a field map provides a _compact_ cryptographically		The SAID of a field map provides a _compact_ cryptographically
	equivalent commitment to the yet to be undisclosed field map details.		equivalent commitment to the yet to be undisclosed field map details.
	A later exchange of the uncompacted field map detail provides _full		A later exchange of the uncompacted field map detail provides _full
	disclosure_. Any later _full disclosure_ is verifiable to an earlier		disclosure_. Any later _full disclosure_ is verifiable to an earlier
	_partial disclosure_. Partial disclosure via compact SAIDs enables		_partial disclosure_. Partial disclosure via compact SAIDs enables
	the scalable repeated verifiable exchange of SAID references to		the scalable repeated verifiable exchange of SAID references to
	cached full disclosures. Multiple SAID references to cached fully		cached full disclosures. Multiple SAID references to cached fully
	disclosed field maps may be transmitted compactly without redundant		disclosed field maps may be transmitted compactly without redundant
	retransmission of the full details each time a new reference is		retransmission of the full details each time a new reference is
	transmitted. Likewise, _partial disclosure_ via SAIDs also supports		transmitted. Likewise, _partial disclosure_ via SAIDs also supports
	the bow-tie model of Ricardian contracts [RC]. Similarly, the schema		the bow-tie model of Ricardian contracts [RC]. Similarly, the schema
	of a field map is metadata about the structure of the field map this		of a field map is metadata about the structure of the field map this
	is validatable given the full disclosure of the field map. The		is validatable given the full disclosure of the field map. The
	details of_compact_ and/or confidential exchange mechanisms that		details of_compact_ and/or confidential exchange mechanisms that
	leverage partial disclosure are explained later.		leverage partial disclosure are explained later. When the field map
			includes sufficient cryptographic entropy such as through a UUID
			field (salty nonce), then the SAID of that field map effectively
			blinds the contents of the field map. This enables the field map
			contents identified by its SAID and characterized by its schema (i.e.
			partial disclosure) to remain private until later full disclosure.
	_Selective disclosure_, on the other hand, is an essential mechanism		_Selective disclosure_, on the other hand, is an essential mechanism
	needed to unbundle in a correlation minimizing way a single		needed to unbundle in a correlation minimizing way a single
	commitment by an Issuer to a bundle of fields (i.e. a nested array or		commitment by an Issuer to a bundle of fields (i.e. a nested array or
	list or tuple of fields) as a whole. This allows separating a "stew"		list or tuple of fields) as a whole. This allows separating a "stew"
	(bundle) of "ingredients" (attributes) into its constituent		(bundle) of "ingredients" (attributes) into its constituent
	"ingredients" (attributes) without correlating the constituents via		"ingredients" (attributes) without correlating the constituents via
	the Issuer's commitment to the "stew" (bundle) as a whole.		the Issuer's commitment to the "stew" (bundle) as a whole.
	3. Schema Section		3. Schema Section
	3.1. Schema is Type
			3.1. Type-is-Schema
	Notable is the fact that there are no top-level type fields in an		Notable is the fact that there are no top-level type fields in an
	ACDC. This is because the schema, s, field itself is the type field.		ACDC. This is because the schema, s, field itself is the type field
	ACDCs follow the design principle of separation of concerns between a		for the ACDC and its parts. ACDCs follow the design principle of
	data container's actual payload information and the type information		separation of concerns between a data container's actual payload
	of that container's payload. In this sense, type information is		information and the type information of that container's payload. In
	metadata, not data. The schema dialect is JSON Schema 2020-12		this sense, type information is metadata, not data. The schema
	[JSch][JSch_202012]. JSON Schema support for composable schema (sub-		dialect used by ACDCs is JSON Schema 2020-12 [JSch][JSch_202012].
	schema), conditional schema (sub-schema), and regular expressions in		JSON Schema supports composable schema (sub-schema), conditional
	schema enable a validator to ask and answer complex questions about		schema (sub-schema), and regular expressions in the schema.
	the type of even optional payload elements while maintaining		Composability enables a validator to ask and answer complex questions
			about the type of even optional payload elements while maintaining
	isolation between payload information and type (structure)		isolation between payload information and type (structure)
	information about the payload [JSchCp][JSchRE][JSchId][JSchCx].		information about the payload [JSchCp][JSchRE][JSchId][JSchCx]. A
	ACDC's use of JSON Schema MUST be in accordance with the ACDC defined		static but composed schema allows a verifiably immutable set of
	profile as defined herein. The exceptions are defined below.		variants. Although the set is immutable, the variants enable
			graduated but secure disclosure. ACDC's use of JSON Schema MUST be
			in accordance with the ACDC defined profile as defined herein. The
			exceptions are defined below.
	3.2. Schema ID Field Label		3.2. Schema ID Field Label
	The usual field label for SAID fields in ACDCs is d. In the case of		The usual field label for SAID fields in ACDCs is d. In the case of
	the schema section, however, the field label for the SAID of the		the schema section, however, the field label for the SAID of the
	schema section is $id. This repurposes the schema id field label,		schema section is $id. This repurposes the schema id field label,
	$id as defined by JSON Schema [JSchId][JSchCx]. The top-level id,		$id as defined by JSON Schema [JSchId][JSchCx]. The top-level id,
	$id, field value in a JSON Schema provides a unique identifier of the		$id, field value in a JSON Schema provides a unique identifier of the
	schema instance. In a usual (non-ACDC) schema the value of the id,		schema instance. In a usual (non-ACDC) schema the value of the id,
	$id, field is expressed as a URI. This is called the _Base URI_ of		$id, field is expressed as a URI. This is called the _Base URI_ of
	skipping to change at page 13, line 5 ¶		skipping to change at page 15, line 34 ¶
	its SAIDified, id, $id, field value.		its SAIDified, id, $id, field value.
	When an id, '$id', field appears in a sub-schema it indicates a		When an id, '$id', field appears in a sub-schema it indicates a
	bundled sub-schema called a schema resource [JSchId][JSchCx]. The		bundled sub-schema called a schema resource [JSchId][JSchCx]. The
	value of the id, '$id', field in any ACDC bundled sub-schema resource		value of the id, '$id', field in any ACDC bundled sub-schema resource
	MUST include the SAID of that sub-schema using one of the formats		MUST include the SAID of that sub-schema using one of the formats
	described below. The sub-schema so bundled MUST be verifiable		described below. The sub-schema so bundled MUST be verifiable
	against its referenced and embedded SAID value. This ensures secure		against its referenced and embedded SAID value. This ensures secure
	bundling.		bundling.
	3.3. Static Schema		3.3. Static (Immutable) Schema
	For security reasons, the full schema of an ACDC must be completely		For security reasons, the full schema of an ACDC must be completely
	self-contained and statically fixed (immutable) for that ACDC. By		self-contained and statically fixed (immutable) for that ACDC. By
	this, we mean that no dynamic schema references or dynamic schema		this, we mean that no dynamic schema references or dynamic schema
	generation mechanisms are allowed.		generation mechanisms are allowed.
	Should an adversary successfully attack the source that provides the		Should an adversary successfully attack the source that provides the
	dynamic schema resource and change the result provided by that		dynamic schema resource and change the result provided by that
	reference, then the schema validation on any ACDC that uses that		reference, then the schema validation on any ACDC that uses that
	dynamic schema reference may fail. Such an attack effectively		dynamic schema reference may fail. Such an attack effectively
	skipping to change at page 13, line 39 ¶		skipping to change at page 16, line 25 ¶
	To elaborate, the serialization of a static schema may be self-		To elaborate, the serialization of a static schema may be self-
	contained. A compact commitment to the detailed static schema may be		contained. A compact commitment to the detailed static schema may be
	provided by its SAID. In other words, the SAID of a static schema is		provided by its SAID. In other words, the SAID of a static schema is
	a verifiable cryptographic identifier for its SAD. Therefore all		a verifiable cryptographic identifier for its SAD. Therefore all
	ACDC compliant schema must be SADs. In other words, they MUST		ACDC compliant schema must be SADs. In other words, they MUST
	therefore be _SAIDified_. The associated detailed static schema		therefore be _SAIDified_. The associated detailed static schema
	(uncompacted SAD) is cryptographically bound and verifiable to its		(uncompacted SAD) is cryptographically bound and verifiable to its
	SAID.		SAID.
	The JSON Schema specification allows complex schema references that		The JSON Schema specification allows complex schema references that
	may include non-local URI references [JSchId][JSchCx]. These		may include non-local URI references
	references may use the $id or $ref keywords. A relative URI		[JSchId][JSchCx][RFC3986][RFC8820]. These references may use the $id
	reference provided by a $ref keyword is resolved against the _Base		or $ref keywords. A relative URI reference provided by a $ref
	URI_ provided by the top-level $id field. When this top-level _Base		keyword is resolved against the _Base URI_ provided by the top-level
	URI_ is non-local then all relative $ref references are therefore		$id field. When this top-level _Base URI_ is non-local then all
	also non-local. A non-local URI reference provided by a $ref keyword		relative $ref references are therefore also non-local. A non-local
	may be resolved without reference to the _Base URI_.		URI reference provided by a $ref keyword may be resolved without
			reference to the _Base URI_.
	In general, schema indicated by non-local URI references ($id or		In general, schema indicated by non-local URI references ($id or
	$ref) MUST NOT be used because they are not cryptographically end-		$ref) MUST NOT be used because they are not cryptographically end-
	verifiable. The value of the underlying schema resource so		verifiable. The value of the underlying schema resource so
	referenced may change (mutate). To restate, a non-local URI schema		referenced may change (mutate). To restate, a non-local URI schema
	resource is not end-verifiable to its URI reference because there is		resource is not end-verifiable to its URI reference because there is
	no cryptographic binding between URI and resource.		no cryptographic binding between URI and resource [RFC3986][RFC8820].
	This does not preclude the use of remotely cached SAIDified schema		This does not preclude the use of remotely cached SAIDified schema
	resources because those resources are end-verifiable to their		resources because those resources are end-verifiable to their
	embedded SAID references. Said another way, a SAIDified schema		embedded SAID references. Said another way, a SAIDified schema
	resource is itself a SAD (Self-Address Data) referenced by its SAID.		resource is itself a SAD (Self-Address Data) referenced by its SAID.
	A URI that includes a SAID may be used to securely reference a remote		A URI that includes a SAID may be used to securely reference a remote
	or distributed SAIDified schema resource because that resource is		or distributed SAIDified schema resource because that resource is
	fixed (immutable, nonmalleable) and verifiable to both the SAID in		fixed (immutable, nonmalleable) and verifiable to both the SAID in
	the reference and the embedded SAID in the resource so referenced.		the reference and the embedded SAID in the resource so referenced.
	To elaborate, a non-local URI reference that includes an embedded		To elaborate, a non-local URI reference that includes an embedded
	skipping to change at page 14, line 38 ¶		skipping to change at page 17, line 25 ¶
	resource that safely returns a verifiable SAD. For example		resource that safely returns a verifiable SAD. For example
	sad:SAID where _SAID_ is replaced with the actual SAID of a SAD		sad:SAID where _SAID_ is replaced with the actual SAID of a SAD
	that provides a verifiable non-local reference to JSON Schema as		that provides a verifiable non-local reference to JSON Schema as
	indicated by the mime-type of schema+json.		indicated by the mime-type of schema+json.
	* The IETF KERI OOBI internet draft specification provides a URL		* The IETF KERI OOBI internet draft specification provides a URL
	syntax that references a SAD resource by its SAID at the service		syntax that references a SAD resource by its SAID at the service
	endpoint indicated by that URL [OOBI_ID]. Such remote OOBI URLs		endpoint indicated by that URL [OOBI_ID]. Such remote OOBI URLs
	are also safe because the provided SAD resource is verifiable		are also safe because the provided SAD resource is verifiable
	against the SAID in the OOBI URL. Therefore OOBI URLs are also		against the SAID in the OOBI URL. Therefore OOBI URLs are also
	acceptable non-local URI references for JSON Schema.		acceptable non-local URI references for JSON Schema
			[OOBI_ID][RFC3986][RFC8820].
	* The did: URI scheme may be used safely to prefix non-local URI		* The did: URI scheme may be used safely to prefix non-local URI
	references that act to namespace SAIDs expressed as DID URIs or		references that act to namespace SAIDs expressed as DID URIs or
	DID URLs. DID resolvers resolve DID URLs for a given DID method		DID URLs. DID resolvers resolve DID URLs for a given DID method
	such as did:keri [DIDK_ID] and may return DID docs or DID doc		such as did:keri [DIDK_ID] and may return DID docs or DID doc
	metadata with SAIDified schema or service endpoints that return		metadata with SAIDified schema or service endpoints that return
	SAIDified schema. A verifiable non-local reference in the form of		SAIDified schema or OOBIs that return SAIDified schema
	DID URL that includes the schema SAID is resolved safely when it		[RFC3986][RFC8820][OOBI_ID]. A verifiable non-local reference in
	dereferences to the SAD of that SAID. For example, the resolution		the form of DID URL that includes the schema SAID is resolved
	result returns an ACDC JSON Schema whose id, $id, field includes		safely when it dereferences to the SAD of that SAID. For example,
	the SAID and returns a resource with JSON Schema mime-type of		the resolution result returns an ACDC JSON Schema whose id, $id,
	schema+json.		field includes the SAID and returns a resource with JSON Schema
			mime-type of schema+json.
	To clarify, ACDCs MUST NOT use complex JSON Schema references which		To clarify, ACDCs MUST NOT use complex JSON Schema references which
	allow *dynamically generated *schema resources to be obtained from		allow *dynamically generated *schema resources to be obtained from
	online JSON Schema Libraries [JSchId][JSchCx]. The latter approach		online JSON Schema Libraries [JSchId][JSchCx]. The latter approach
	may be difficult or impossible to secure because a cryptographic		may be difficult or impossible to secure because a cryptographic
	commitment to the base schema that includes complex schema (non-		commitment to the base schema that includes complex schema (non-
	relative URI-based) references only commits to the non-relative URI		relative URI-based) references only commits to the non-relative URI
	reference and not to the actual schema resource which may change (is		reference and not to the actual schema resource which may change (is
	dynamic, mutable, malleable). To restate, this approach is insecure		dynamic, mutable, malleable). To restate, this approach is insecure
	because a cryptographic commitment to a complex (non-relative URI-		because a cryptographic commitment to a complex (non-relative URI-
	based) reference is NOT equivalent to a commitment to the detailed		based) reference is NOT equivalent to a commitment to the detailed
	associated schema resource so referenced if it may change.		associated schema resource so referenced if it may change.
	ACDCs MUST use static JSON Schema (i.e. _SAIDifiable_ schema). These		ACDCs MUST use static JSON Schema (i.e. _SAIDifiable_ schema). These
	may include internal relative references to other parts of a fully		may include internal relative references to other parts of a fully
	self-contained static (_SAIDified_) schema or references to static		self-contained static (_SAIDified_) schema or references to static
	(_SAIDified_) external schema parts. As indicated above, these		(_SAIDified_) external schema parts. As indicated above, these
	references may be bare SAIDs, DID URIs or URLs (did: scheme), SAD		references may be bare SAIDs, DID URIs or URLs (did: scheme), SAD
	URIs (sad: scheme), or OOBI URLs. Recall that a commitment to a SAID		URIs (sad: scheme), or OOBI URLs [OOBI_ID]. Recall that a commitment
	with sufficient collision resistance makes an equivalent secure		to a SAID with sufficient collision resistance makes an equivalent
	commitment to its encapsulating block SAD. Thus static schema may be		secure commitment to its encapsulating block SAD. Thus static schema
	either fully self-contained or distributed in parts but the value of		may be either fully self-contained or distributed in parts but the
	any reference to a part must be verifiably static (immutable,		value of any reference to a part must be verifiably static
	nonmalleable) by virtue of either being relative to the self-		(immutable, nonmalleable) by virtue of either being relative to the
	contained whole or being referenced by its SAID. The static schema		self-contained whole or being referenced by its SAID. The static
	in whole or in parts may be attached to the ACDC itself or provided		schema in whole or in parts may be attached to the ACDC itself or
	via a highly available cache or data store. To restate, this		provided via a highly available cache or data store. To restate,
	approach is securely end-verifiable (zero-trust) because a		this approach is securely end-verifiable (zero-trust) because a
	cryptographic commitment to the SAID of a SAIDified schema is		cryptographic commitment to the SAID of a SAIDified schema is
	equivalent to a commitment to the detailed associated schema itself		equivalent to a commitment to the detailed associated schema itself
	(SAD).		(SAD).
	3.4. Schema Dialect		3.4. Schema Dialect
	The schema dialect for ACDC 1.0 is JSON Schema 2020-12 and is		The schema dialect for ACDC 1.0 is JSON Schema 2020-12 and is
	indicated by the identifier "https://json-schema.org/draft/2020-12/		indicated by the identifier "https://json-schema.org/draft/2020-12/
	schema" [JSch][JSch_202012]. This is indicated in a JSON Schema via		schema" [JSch][JSch_202012]. This is indicated in a JSON Schema via
	the value of the top-level $schema field. Although the value of		the value of the top-level $schema field. Although the value of
	skipping to change at page 16, line 36 ¶		skipping to change at page 19, line 24 ¶
	compacted/uncompacted attribute, edge, and rule sections in a		compacted/uncompacted attribute, edge, and rule sections in a
	provided ACDC. When compact, any one of these sections may be		provided ACDC. When compact, any one of these sections may be
	represented merely by its SAID [JSch][JSchCp]. When used for the		represented merely by its SAID [JSch][JSchCp]. When used for the
	top-level attribute, a, edge, e, or rule, r, section field values,		top-level attribute, a, edge, e, or rule, r, section field values,
	the oneOf sub-schema composition operator provides both compact and		the oneOf sub-schema composition operator provides both compact and
	uncompacted variants. The provided ACDC MUST validate against an		uncompacted variants. The provided ACDC MUST validate against an
	allowed combination of the composed variants, either the compact SAID		allowed combination of the composed variants, either the compact SAID
	of a block or the full detailed (uncompacted) block for each section.		of a block or the full detailed (uncompacted) block for each section.
	The validator determines what decomposed variants the provided ACDC		The validator determines what decomposed variants the provided ACDC
	MUST also validate against. Decomposed variants may be dependent on		MUST also validate against. Decomposed variants may be dependent on
	the type of disclosure, partial, full, or selective.		the type of graduated disclosure, partial, full, or selective.
			Essentially a composable schema is a verifiable bundle of metadata
			(composed) about content that then can be verifiably unbundled
			(decomposed) later. The Issuer makes a single verifiable commitment
			to the bundle (composed schema) and a recipient may then safely
			unbundle (decompose) the schema to validate any of the graduated
			disclosures variants allowed by the composition.
	Unlike the other compactifiable sections, it is impossible to define		Unlike the other compactifiable sections, it is impossible to define
	recursively the exact detailed schema as a variant of a oneOf		recursively the exact detailed schema as a variant of a oneOf
	composition operator contained in itself. Nonetheless, the provided		composition operator contained in itself. Nonetheless, the provided
	schema, whether self-contained, attached, or cached MUST validate as		schema, whether self-contained, attached, or cached MUST validate as
	a SAD against its provided SAID. It MUST also validate against one		a SAD against its provided SAID. It MUST also validate against one
	of its specified oneOf variants.		of its specified oneOf variants.
	The compliance of the provided non-schema attribute, a, edge, e, and		The compliance of the provided non-schema attribute, a, edge, e, and
	rule, r, sections MUST be enforced by validating against the composed		rule, r, sections MUST be enforced by validating against the composed
	skipping to change at page 20, line 31 ¶		skipping to change at page 23, line 24 ¶
	An important design goal of ACDCs is they support the sharing of		An important design goal of ACDCs is they support the sharing of
	provably authentic data while also protecting against the un-		provably authentic data while also protecting against the un-
	permissioned exploitation of that data. Often the term _privacy		permissioned exploitation of that data. Often the term _privacy
	protection_ is used to describe similar properties. But a narrow		protection_ is used to describe similar properties. But a narrow
	focus on "privacy protection" may lead to problematic design trade-		focus on "privacy protection" may lead to problematic design trade-
	offs. With ACDCs, the primary design goal is not _data privacy		offs. With ACDCs, the primary design goal is not _data privacy
	protection_ per se but the more general goal of protection from the		protection_ per se but the more general goal of protection from the
	*_un-permissioned exploitation of data_*. In this light, a _given		*_un-permissioned exploitation of data_*. In this light, a _given
	privacy protection_ mechanism may be employed to help protect against		privacy protection_ mechanism may be employed to help protect against
	_unpermissioned exploitation of data_ but only when it serves that		_unpermissioned exploitation of data_ but only when it serves that
	more general-purpose and not as an end in and of itself. There are		more general-purpose and not as an end in and of itself.
	three primary mechanisms ACDCs use to protect against _unpermissioned
	exploitation of data_. These are:
	* Chain-link Confidentiality [CLC]
	* Partial Disclosure
	* Selective Disclosure
	5.1. Principle of Least Disclosure		5.1. Graduated Disclosure and the Principle of Least Disclosure
	ACDCs are designed to satisfy the principle of least disclosure.		As described previously, ACDCs employ _graduated disclosure_
			mechanisms that satisfy the principle of least disclosure. Requoted
			here the principle of least disclosure is as follows:
	The system should disclose only the minimum amount of information		The system should disclose only the minimum amount of information
	about a given party needed to facilitate a transaction and no		about a given party needed to facilitate a transaction and no
	more. [IDSys]		more. [IDSys]
			For example, compact disclosure, partial disclosure, and selective
			disclosure are all graduated disclosure mechanisms. Contractually
			protected disclosure leverages graduated disclosure so that
			contractual protections can be put into place using the least
			disclosure necessary to that end. This minimizes the leakage of
			information that can be correlated. One type of contractually
			protected disclosure is chain-link confidentiality [CLC].
			5.2. Exploitation Protection Mechanisms
			ACDCS employ several mechanisms to protect against _unpermissioned
			exploitation of data_. These are:
			* Chain-link Confidentiality [CLC]
			* Partial Disclosure
			* Selective Disclosure
	For example, the _partial disclosure_ of portions of an ACDC to		For example, the _partial disclosure_ of portions of an ACDC to
	enable chain-link confidentiality of the subsequent full disclosure		enable chain-link confidentiality of the subsequent full disclosure
	is an application of the principle of least disclosure. Likewise,		is an application of the principle of least disclosure. Likewise,
	unbundling only the necessary attributes from a bundled commitment		unbundling only the necessary attributes from a bundled commitment
	using _selective disclosure_ to enable a correlation minimizing		using _selective disclosure_ to enable a correlation minimizing
	disclosure from that bundle is an application of the principle of		disclosure from that bundle is an application of the principle of
	least disclosure.		least disclosure.
	5.2. Three Party Exploitation Model		5.3. Three Party Exploitation Model
	Unpermission exploitation is characterized using a three-party model.		Unpermission exploitation is characterized using a three-party model.
	The three parties are as follows:		The three parties are as follows:
	* First-Party = _Discloser_ of data.		* First-Party = _Discloser_ of data.
	* Second-Party = _Disclosee_ of data received from First Party		* Second-Party = _Disclosee_ of data received from First Party
	(_Discloser_).		(_Discloser_).
	* Third-Party = _Observer_ of data disclosed by First Party		* Third-Party = _Observer_ of data disclosed by First Party
	(_Discloser_) to Second Party (_Disclosee_).		(_Discloser_) to Second Party (_Disclosee_).
	5.2.1. Second-Party (Disclosee) Exploitation		5.3.1. Second-Party (Disclosee) Exploitation
	* implicit permissioned correlation.		* implicit permissioned correlation.
	- no contractual restrictions on the use of disclosed data.		- no contractual restrictions on the use of disclosed data.
	* explicit permissioned correlation.		* explicit permissioned correlation.
	- use as permitted by contract		- use as permitted by contract
	* explicit unpermissioned correlation with other second parties or		* explicit unpermissioned correlation with other second parties or
	third parties.		third parties.
	- malicious use in violation of contract		- malicious use in violation of contract
	5.2.2. Third-Party (Observer) Exploitation		5.3.2. Third-Party (Observer) Exploitation
	* implicit permissioned correlation.		* implicit permissioned correlation.
	- no contractual restrictions on use of observed data.		- no contractual restrictions on use of observed data.
	* explicit unpermissioned correlation via collusion with second		* explicit unpermissioned correlation via collusion with second
	parties.		parties.
	- malicious use in violation of second party contract		- malicious use in violation of second party contract
	5.3. Chain-link Confidentiality Exchange		5.4. Chain-link Confidentiality Exchange
	Chain-link confidentiality imposes contractual restrictions and		Chain-link confidentiality imposes contractual restrictions and
	liability on any Disclosee (Second-Party) [CLC]. The exchange		liability on any Disclosee (Second-Party) [CLC]. The exchange
	provides a fair contract consummation mechanism. The steps in a		provides a fair contract consummation mechanism. The essential steps
	chain-link confidentiality exchange are as follows:		in a chain-link confidentiality exchange are shown below. Other
			steps may be included in a more comprehensive exchange protocol.
	* _Discloser_ provides a non-repudiable _Offer_ with verifiable		* _Discloser_ provides a non-repudiable _Offer_ with verifiable
	metadata (sufficient partial disclosure) which includes any terms		metadata (sufficient partial disclosure) which includes any terms
	or restrictions on use.		or restrictions on use.
	* _Disclosee_ verifies _Offer_ against composed schema and metadata		* _Disclosee_ verifies _Offer_ against composed schema and metadata
	adherence to desired data.		adherence to desired data.
	* _Disclosee_ provides non-repudiable _Accept_ of terms that are		* _Disclosee_ provides non-repudiable _Accept_ of terms that are
	contingent on compliant disclosure.		contingent on compliant disclosure.
	skipping to change at page 23, line 27 ¶		skipping to change at page 26, line 27 ¶
	"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",		"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
	"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"		"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
	}		}
	6.2.1. Compact Private ACDC Schema		6.2.1. Compact Private ACDC Schema
	The schema for the compact private ACDC example above is provided		The schema for the compact private ACDC example above is provided
	below.		below.
	{		{
	"$id": "EN8i2i5ye0-xGS95pm5cg1j0GmFkarJe0zzsSrrf4XJY",		"$id": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
	"$schema": "https://json-schema.org/draft/2020-12/schema",		"$schema": "https://json-schema.org/draft/2020-12/schema",
	"title": "Compact Private ACDC",		"title": "Compact Private ACDC",
	"description": "Example JSON Schema for a Compact Private ACDC.",		"description": "Example JSON Schema for a Compact Private ACDC.",
	"credentialType": "CompactPrivateACDCExample",		"credentialType": "CompactPrivateACDCExample",
	"type": "object",		"type": "object",
	"required":		"required":
	[		[
	"v",		"v",
	"d",		"d",
	"u",		"u",
	skipping to change at page 34, line 22 ¶		skipping to change at page 37, line 22 ¶
	}		}
	}		}
	The edge section's top-level SAID, d, field is the SAID of the edge		The edge section's top-level SAID, d, field is the SAID of the edge
	block and is the same SAID used as the compacted value of the ACDC's		block and is the same SAID used as the compacted value of the ACDC's
	top-level edge, e, field. Each edge in the edge section gets its		top-level edge, e, field. Each edge in the edge section gets its
	field with its own local label. In the example above, the edge label		field with its own local label. In the example above, the edge label
	is "boss". Note that each edge does NOT include a type field. The		is "boss". Note that each edge does NOT include a type field. The
	type of each edge is provided by the schema vis-a-vis the label of		type of each edge is provided by the schema vis-a-vis the label of
	that edge. This is in accordance with the design principle of ACDCs		that edge. This is in accordance with the design principle of ACDCs
	that may be succinctly expressed as "schema is type". This approach		that may be succinctly expressed as "type-is-schema". This approach
	varies somewhat from many property graphs which often do not have a		varies somewhat from many property graphs which often do not have a
	schema [PGM][Dots][KG]. Because ACDCs have a schema for other		schema [PGM][Dots][KG]. Because ACDCs have a schema for other
	reasons, however, they leverage that schema to provide edge types		reasons, however, they leverage that schema to provide edge types
	with a cleaner separation of concerns.		with a cleaner separation of concerns.
	Each edge sub-block has one required node, n, field. The value of		Each edge sub-block has one required node, n, field. The value of
	the node, n, field is the SAID of the ACDC to which the edge		the node, n, field is the SAID of the ACDC to which the edge
	connects.		connects.
	A main distinguishing feature of a _property graph_ (PG) is that both		A main distinguishing feature of a _property graph_ (PG) is that both
	skipping to change at page 35, line 12 ¶		skipping to change at page 38, line 12 ¶
	}		}
	}		}
	8.1. Globally Distributed Secure Graph Fragments		8.1. Globally Distributed Secure Graph Fragments
	Abstractly, an ACDC with one or more edges may be a fragment of a		Abstractly, an ACDC with one or more edges may be a fragment of a
	distributed property graph. However, the local label does not enable		distributed property graph. However, the local label does not enable
	the direct unique global resolution of a given edge including its		the direct unique global resolution of a given edge including its
	properties other than a trivial edge with only one property, its		properties other than a trivial edge with only one property, its
	node, n field. To enable an edge with additional properties to be		node, n field. To enable an edge with additional properties to be
	globally uniquely resolvable, that edge's block may have a SAID, d,		globally uniquely resolvable, that edge's block MUST have a SAID, d,
	field. Because a SAID is a cryptographic digest it will universally		field. Because a SAID is a cryptographic digest it will universally
	and uniquely identify an edge with a given set of properties [Hash].		and uniquely identify an edge with a given set of properties [Hash].
	This allows ACDCs to be used as secure fragments of a globally		This allows ACDCs to be used as secure fragments of a globally
	distributed property graph (PG). This enables a property graph to		distributed property graph (PG). This enables a property graph to
	serve as a global knowledge graph in a secure manner that crosses		serve as a global knowledge graph in a secure manner that crosses
	trust domains [PGM][Dots][KG]. This is shown below.		trust domains [PGM][Dots][KG]. This is shown below.
	{		{
	"e":		"e":
	{		{
	skipping to change at page 37, line 13 ¶		skipping to change at page 40, line 13 ¶
	shown above. This alternate compact form is shown below.		shown above. This alternate compact form is shown below.
	{		{
	"e":		"e":
	{		{
	"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",		"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
	"boss": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"		"boss": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
	}		}
	}		}
	8.5. Node Discovery		8.5. Operations on Edges and Edge-Groups
			When the top-level edge section, e, field includes more than one edge
			there is a need or opportunity to define the logic for evaluating
			those edges with respect to validating the ACDC itself with respect
			to the validity of the other ACDCs it is connected two. More than
			one edge creates a provenance tree not simply a provenance chain.
			The obvious default for a chain is that all links in the chain must
			be valid in order for the chain itself to be valid, or more precisely
			for the tail of the chain to be valid. If any links between the head
			and the tail are broken (invalid) then the tail is not valid. This
			default logic may not be so useful in all cases when a given ACDC is
			the tail of multiple parallel chains (i.e. a branching node in a tree
			of chains). Therefore provided herein is the syntax for exactly
			specifying the operations to perform on each edge and groups of edges
			in its edge section.
			8.5.1. Label Types
			There are three types of labels:
			* Reserved Field Labels (Metadata). d for SAID of block o for
			operator n for Node SAID (another ACDC) w for weight
			* Edge Field Map Labels (Single Edges) any value except reserved
			values above
			* Edge-Group Field Map Labels (Aggregates of Edges) any value except
			reserved values above
			8.5.2. Block Types
			There are two types of field-maps or blocks that may appear as values
			of fields within an edge section, e, field either at the top level or
			nested:
			* Edge-Group. An _*edge-group*_ MUST NOT have a node, n, metadata
			field. Its non-metadata field values may include other (sub)
			edge-group blocks, edge blocks or other properties.
			* Edge. An _*edge*_ MUST have a node, n, metadata field. Its non-
			metadata field values MUST NOT include edge-group blocks or other
			edge blocks but may include other types of properties. From a
			graph perspective, _edge_ blocks terminate at their node, n, field
			and are not themselves nestable. An _edge_ block is a leaf with
			respect to any nested _edge-group_ blocks in which the edge
			appears. It is therefore also a leaf with respect to its
			enclosing top-level edge section, e, field. The ACDC node that an
			edge points to may have its own edge-groups or edges in that
			node's own top-level edge section.
			The top-level edge section, e, field value is always an _edge-group_
			block.
			With respect to the granularity of a property graph consisting of
			ACDCs as nodes, nested edge-groups within a given top-level edge
			field, e, field of a given ACDC constitute a sub-graph whose nodes
			are edge-groups not ACDCs. One of the attractive features of
			property graphs (PGs) is their support for different edge and node
			types which enables nested sub-graphs such as is being employed here
			to support the expression of complex logical or aggregative
			operations on groups of edges (as subnodes) within the top-level edge
			section, e, field of an ACDC (as supernode).
			8.5.3. Operator, o, Field
			The meaning of the operator, o, metadata field label depends on which
			type of block it appears in.
			* When appearing in an edge-group block then the operator, o, field
			value is an aggregating (m-ary) operator, such as, OR, AND, AVG,
			NAND, NOR etc. Its operator applies to all the edges or edge-
			groups that appear in that edge-group block.
			* When appearing in an edge block then the operator, o, field value
			is a unary operator like NOT. When more than one unary operator
			applies to a given edge then the value of the operator, o, field
			is a list of those unary operators.
			8.5.4. Weight, w, field.
			Many aggregating operators used for automated reasoning such as
			weighted average, WAVG, or ranking aggregation, depends on each edge
			having a weight. To simplify the semantics for such operators, the
			weight, w, field is the reserved field label for weighting. Other
			fields could provide other types of weights but having a default
			simplifies the default definitions of those weighted operators.
			8.5.5. Special Unary Operators
			Two special unary operators are defined for ACDCs. These are,
			Issuee-To-Issuer, I2I, constraint operator and Not-Issuee-To-Issuer,
			NI2I, constraint operator
			Many ACDC chains use targeted ACDCs (i.e. have Issuees). A chain of
			Issuer-To-Issuee-To-Issuer targeted ACDCs in which each Issuee
			becomes the Issuer of the next ACDC in the chain can be used to
			provide a chain-of-authority. A common use case of a chain-of-
			authority is a delegation chain for authorization.
			The I2I unary operator when present means that the Issuee of the node
			that the edge points to MUST be the Issuer of the current ACDC in
			which the edge resides. This also means therefore that the ACDC node
			pointed to by the edge must also be a targeted ACDC.
			The NI2I unary operator when present removes or nullifies any
			requirement expressed by the dual I2I operator described above. In
			other words, any requirement that the Issuee of the node the edge
			points to MUST be the Issuer of the current ACDC in which the edge
			resides is not applicable. To clarify, when operative (present), the
			NI2I operator means that a targeted ACDC as a node of the associated
			edge may still be valid even when the Issuee of that node's ACDC is
			not the Issuer of the ACDC in which the edge appears. Furthermore,
			the ACDC node pointed to by the edge may or may not be a targeted
			ACDC.
			If both the I2I and NI2I operators appear in an operator, o, field
			list then the last one appearing in the list is the operative one.
			8.5.6. Defaults for missing operators
			When the operator, o, field is missing in an edge-group block. The
			default value for the operator, o, field is AND.
			When the operator, o, field is missing or empty in an edge block, or
			is present but does not include either the I2I or NI2I operators
			Then,
			If the node pointed to by the edge is a targeted ACDC i.e. has an
			Issuee, by default it is assumed that the I2I operator is appended to
			the operator, o, field's effective list value.
			If the node pointed to by the edge-block is a non-targeted ACDC i.e.
			does not have an Issuee, by default, it is assumed that the NI2I
			operator is appended to the operator, o, field's effective list
			value.
			8.5.7. Examples
			8.5.7.1. Defaults
			{
			"e":
			{
			"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
			"boss":
			{
			"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
			"power": "high"
			},
			"baby":
			{
			"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
			"power": "low"
			}
			}
			}
			8.5.8. Explicit AND
			{
			"e":
			{
			"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
			"o": "AND",
			"boss":
			{
			"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
			"power": "high"
			},
			"baby":
			{
			"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
			"o": "NOT",
			"power": "low"
			}
			}
			}
			8.5.9. Unary I2I
			{
			"e":
			{
			"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
			"o": "AND",
			"boss":
			{
			"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
			"power": "high"
			},
			"baby":
			{
			"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
			"o": "I2I",
			"power": "low"
			}
			}
			}
			8.5.10. Unary NI2I
			{
			"e":
			{
			"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
			"o": "OR",
			"boss":
			{
			"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
			"o": "NI2I",
			"power": "high"
			},
			"baby":
			{
			"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
			"o": "I2I",
			"power": "low"
			}
			}
			}
			8.5.11. Nested Edge-Group
			{
			"e":
			{
			"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
			"o": "AND",
			"boss":
			{
			"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
			"o": ["NI2I", "NOT"],
			"power": "high"
			},
			"baby":
			{
			"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
			"o": "I2I",
			"power": "low"
			},
			"food":
			{
			"o": "OR",
			"power": "med",
			"plum":
			{
			"n": "EQIYPvAu6DZAIl3AORH3dCdoFOLe71iheqcywJcnjtJt",
			"o": "NI2I"
			},
			"pear":
			{
			"n": "EJtQIYPvAu6DZAIl3AORH3dCdoFOLe71iheqcywJcnjt",
			"o": "NI2I"
			}
			}
			}
			}
			8.5.12. vLEI ECR issued by QVI example
			When an ECR vLEI is issued by the QVI it is not chained, Issuer-to-
			Issuee, via the LE credential. A more accurate way of expressing the
			chaining would be to use the AND operator to include both the LE and
			QVI credentials as edges in the ECR and also to apply the unary NI2I
			to the LE credential instead of only chaining the ECR to the LE and
			not chaining to ECR to the QVI at all.
			In the following example: The top-level edge-block uses the default
			of AND and the qvi edge uses the default of I2I because it points to
			a targeted ACDC. The le edge, on the other hand, points to a
			targeted ACDC. It uses the unary operator, NI2I in its operator, o,
			field so that it will be accepted it even though its targeted Issuee
			is not the Issuer of the current credential.
			{
			"e":
			{
			"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
			"qvi":
			{
			"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
			}
			"le":
			{
			"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
			"o": "NI2I",
			}
			}
			}
			8.5.13. Commentary
			This provides a simple but highly expressive syntax for applying
			(m-ary) aggregating operators to nestable groups of edges and unary
			operators to edges individually within those groups. This is a
			general approach with high expressive power. It satisfies many
			business logic requirements similar to that of SGL.
			Certainly, an even more expressive syntax could be developed. The
			proposed syntax, however, is simple, compact, has intelligent
			defaults, and is sufficiently general in scope to satisfy all the
			currently contemplated use cases.
			The intelligent defaults for the operator, o, field, including the
			default application of the I2I or NI2I unary operator, means that in
			most current use cases the operator, o, field does not even need to
			be present.
			8.6. Node Discovery
	In general, the discovery of the details of an ACDC referenced as a		In general, the discovery of the details of an ACDC referenced as a
	node, n field value, in an edge sub-block begins with the node SAID		node, n field value, in an edge sub-block begins with the node SAID
	or the SAID of the associated edge sub-block. Because a SAID is a		or the SAID of the associated edge sub-block. Because a SAID is a
	cryptographic digest with high collision resistance it provides a		cryptographic digest with high collision resistance it provides a
	universally unique identifier to the referenced ACDC as a node. The		universally unique identifier to the referenced ACDC as a node. The
	Discovery of a service endpoint URL that provides database access to		Discovery of a service endpoint URL that provides database access to
	a copy of the ACDC may be bootstrapped via an OOBI (Out-Of-Band-		a copy of the ACDC may be bootstrapped via an OOBI (Out-Of-Band-
	Introduction) that links the service endpoint URL to the SAID of the		Introduction) that links the service endpoint URL to the SAID of the
	ACDC [OOBI_ID]. Alternatively, the _Issuer_ may provide as an		ACDC [OOBI_ID]. Alternatively, the _Issuer_ may provide as an
	skipping to change at page 38, line 30 ¶		skipping to change at page 48, line 23 ¶
	rule section, r, field that appears at the top level of the ACDC.		rule section, r, field that appears at the top level of the ACDC.
	Each clause in the rule section gets its own field. Each clause also		Each clause in the rule section gets its own field. Each clause also
	has its own local label.		has its own local label.
	The legal, l, field in each block provides the associated legal		The legal, l, field in each block provides the associated legal
	language.		language.
	Note there are no type fields in the rule section. The type of a		Note there are no type fields in the rule section. The type of a
	contract and the type of each clause is provided by the schema vis-		contract and the type of each clause is provided by the schema vis-
	a-vis the label of that clause. This follows the ACDC design		a-vis the label of that clause. This follows the ACDC design
	principle that may be succinctly expressed as "schema is type".		principle that may be succinctly expressed as "type-is-schema".
	Each rule section clause may also have its own clause SAID, d, field.		Each rule section clause may also have its own clause SAID, d, field.
	Clause SAIDs enable reference to individual clauses, not merely the		Clause SAIDs enable reference to individual clauses, not merely the
	whole contract as given by the rule section's top-level SAID, d,		whole contract as given by the rule section's top-level SAID, d,
	field.		field.
	An example rule section with clause SAIDs is provided below.		An example rule section with clause SAIDs is provided below.
	{		{
	"r":		"r":
	skipping to change at page 41, line 5 ¶		skipping to change at page 50, line 35 ¶
	9.4. Clause Discovery		9.4. Clause Discovery
	In compact form, the discovery of either the rule section as a whole		In compact form, the discovery of either the rule section as a whole
	or a given clause begins with the provided SAID. Because the SAID,		or a given clause begins with the provided SAID. Because the SAID,
	d, field of any block is a cryptographic digest with high collision		d, field of any block is a cryptographic digest with high collision
	resistance it provides a universally unique identifier to the		resistance it provides a universally unique identifier to the
	referenced block details (whole rule section or individual clause).		referenced block details (whole rule section or individual clause).
	The discovery of a service endpoint URL that provides database access		The discovery of a service endpoint URL that provides database access
	to a copy of the rule section or to any of its clauses may be		to a copy of the rule section or to any of its clauses may be
	bootstrapped via an OOBI (Out-Of-Band-Introduction) that links the		bootstrapped via an OOBI (Out-Of-Band-Introduction) that links the
	service endpoint URL to the SAID of the respective block.		service endpoint URL to the SAID of the respective block [OOBI_ID].
	Alternatively, the issuer may provide as an attachment at issuance a		Alternatively, the issuer may provide as an attachment at issuance a
	copy of the referenced contract associated with the whole rule		copy of the referenced contract associated with the whole rule
	section or any clause. In either case, after a successful issuance		section or any clause. In either case, after a successful issuance
	exchange, the Issuee or holder of any ACDC will have either a copy or		exchange, the Issuee or holder of any ACDC will have either a copy or
	a means of obtaining a copy of any referenced contracts in whole or		a means of obtaining a copy of any referenced contracts in whole or
	in part of all ACDCs so issued. That Issuee or recipient will then		in part of all ACDCs so issued. That Issuee or recipient will then
	have everything it needs to subsequently make a successful		have everything it needs to subsequently make a successful
	presentation or disclosure to a Disclosee. This is the essence of		presentation or disclosure to a Disclosee. This is the essence of
	percolated discovery.		percolated discovery.
	10. Informative Example of an ACDC		10. Disclosure-Specific (Bespoke) Issued ACDCs
	10.1. Public Compact Variant		The ACDC chaining enables disclosure-specific issuance of bespoke
			ACDCs. A given Discloser of an ACDC issued by some Issuer may want
			to augment the disclosure with additional contractual obligations or
			additional information sourced by the Discloser where those
			augmentations are specific to a given context such as a specific
			Disclosee. Instead of complicating the presentation exchange to
			accommodate such disclosure-specific augmentations, a given Disloser
			issues its own bespoke ACDC that includes the other ACDC of the other
			Issuer by reference via an edge in the bespoke ACDC. This means that
			the normal validation logic and tooling for a chained ACDC can be
			applied without complicating the presentation exchange logic.
			Furthermore, attributes in other ACDCs pointed to by edges in the
			bespoke ACDC may be addressed by attributes in the bespoke ACDC using
			JSON Pointer or CESR-Proof SAD Path references that are relative to
			the node SAID in the edge [RFC6901][Proof_ID].
			For example, this approach enables the bespoke ACDC to identify
			(name) the Disclosee directly as the Issuee of the bespoke ACDC.
			This enables contractual legal language in the rule section of the
			bespoke ACDC that reference the Issuee of that ACDC as a named party.
			Signing the agreement to the offer of that bespoke ACDC consummates a
			contract between named Issuer and named Issuee. This approach means
			that custom or bespoke presentations do not need additional
			complexity or extensions. Extensibility comes from reusing the
			tooling for issuing ACDCs to issue a bespoke or disclosure-specific
			ACDC. When the only purpose of the bespoke ACDC is to augment the
			contractual obligations associated with the disclosure then the
			attribute section, a, field value of the bespoke ACD may be empty or
			it may include properties whose only purpose is to support the
			bespoke contractual language.
			Similarly, this approach effectively enables a type of _rich
			presentation_ or combined disclosure where multiple ACDCs may be
			referenced by edges in the bespoke ACDC that each contributes some
			attribute(s) to the effective set of attributes referenced in the
			bespoke ACDC. The bespoke ACDC enables the equivalent of a _rich
			presentation_ without requiring any new tooling [Abuse].
			10.1. Example Bespoke Issued ACDC
			Consider the following disclosure-specific ACDC. The Issuer is the
			Discloser, the Issuee is the Disclosee. The rule section includes a
			context-specific (anti) assimilation clause that limits the use of
			the information to a single one-time usage purpose, that is in this
			case, admittance to a restaurant. The ACDC includes an edge that
			references some other ACDC that may for example be a coupon or gift
			card. The attribute section includes the date and place of
			admittance.
			{
			"v": "ACDC10JSON00011c_",
			"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
			"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
			"s": "EGGeIZ8a8FWS7a646jrVPTzlSkUPqs4reAXRZOkogZ2A",
			"a":
			{
			"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
			"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
			"date": "2022-08-22T17:50:09.988921+00:00",
			"place": "GoodFood Restaurant, 953 East Sheridan Ave, Cody WY 82414 USA"
			},
			"e":
			{
			"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
			"other":
			{
			"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
			"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
			}
			},
			"r":
			{
			"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
			"Assimilation":
			{
			"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
			"l": "Issuee hereby explicitly and unambiguously agrees to NOT assimilate, aggregate, correlate, or otherwise use in combination with other information available to the Issuee, the information, in whole or in part, referenced by this container or any containers recursively referenced by the edge section, for any purpose other than that expressly permitted by the Purpose clause."
			},
			"Purpose":
			{
			"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
			"l": "One-time admittance of Issuer by Issuee to eat at place on date as specified in attribute section."
			}
			}
			}
			11. Informative Examples
			11.1. Public ACDC with Compact and Uncompated Variants
			### Public Compact Variant
	{		{
	"v": "ACDC10JSON00011c_",		"v": "ACDC10JSON00011c_",
	"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",		"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
	"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",		"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
	"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",		"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
	"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",		"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
	"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",		"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
	"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",		"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
	"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"		"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
	}		}
	10.2. Public Uncompacted Variant		11.1.1. Public Uncompacted Variant
	{		{
	"v": "ACDC10JSON00011c_",		"v": "ACDC10JSON00011c_",
	"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",		"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
	"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",		"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
	"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",		"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
	"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",		"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
	"a":		"a":
	{		{
	"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",		"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
	"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",		"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
	skipping to change at page 42, line 43 ¶		skipping to change at page 54, line 43 ¶
	"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"		"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
	},		},
	"liabilityDisclaimer":		"liabilityDisclaimer":
	{		{
	"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",		"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
	"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "		"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
	}		}
	}		}
	}		}
	10.3. Composed Schema that Supports both Public Compact and Uncompacted		11.1.2. Composed Schema that Supports both Public Compact and
	Variants		Uncompacted Variants
	{		{
	"$id": "EN8i2i5ye0-xGS95pm5cg1j0GmFkarJe0zzsSrrf4XJY",		"$id": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
	"$schema": "https://json-schema.org/draft/2020-12/schema",		"$schema": "https://json-schema.org/draft/2020-12/schema",
	"title": "Public ACDC",		"title": "Public ACDC",
	"description": "Example JSON Schema Public ACDC.",		"description": "Example JSON Schema Public ACDC.",
	"credentialType": "PublicACDCExample",		"credentialType": "PublicACDCExample",
	"type": "object",		"type": "object",
	"required":		"required":
	[		[
	"v",		"v",
	"d",		"d",
	"i",		"i",
	skipping to change at page 44, line 50 ¶		skipping to change at page 56, line 50 ¶
	"type": "integer"		"type": "integer"
	},		},
	"name":		"name":
	{		{
	"description": "test taker full name",		"description": "test taker full name",
	"type": "string"		"type": "string"
	}		}
	},		},
	"additionalProperties": false,		"additionalProperties": false,
	}		}
	],		]
	},		},
	"e":		"e":
	{		{
	"description": "edge section",		"description": "edge section",
	"oneOf":		"oneOf":
	[		[
	{		{
	"description": "edge section SAID",		"description": "edge section SAID",
	"type": "string"		"type": "string"
	skipping to change at page 46, line 11 ¶		skipping to change at page 58, line 11 ¶
	"w":		"w":
	{		{
	"description": "edge weight",		"description": "edge weight",
	"type": "string"		"type": "string"
	},		},
	"additionalProperties": false		"additionalProperties": false
	},		},
	},		},
	"additionalProperties": false		"additionalProperties": false
	}		}
	],		]
	},		},
	"r":		"r":
	{		{
	"description": "rule section",		"description": "rule section",
	"oneOf":		"oneOf":
	[		[
	{		{
	"description": "rule section SAID",		"description": "rule section SAID",
	"type": "string"		"type": "string"
	},		},
	skipping to change at page 48, line 5 ¶		skipping to change at page 60, line 5 ¶
	}		}
	},		},
	"additionalProperties": false		"additionalProperties": false
	}		}
	]		]
	}		}
	},		},
	"additionalProperties": false		"additionalProperties": false
	}		}
	11. Selective Disclosure		12. Selective Disclosure
	As explained previously, the primary difference between _partial		As explained previously, the primary difference between _partial
	disclosure_ and _selective disclosure_ is determined by the		disclosure_ and _selective disclosure_ is determined by the
	correlatability with respect to its encompassing block after _full		correlatability with respect to its encompassing block after _full
	disclosure_ of the detailed field value. A _partially disclosable_		disclosure_ of the detailed field value. A _partially disclosable_
	field becomes correlatable to its encompassing block after its _full		field becomes correlatable to its encompassing block after its _full
	disclosure_. Whereas a _selectively disclosable_ field may be		disclosure_. Whereas a _selectively disclosable_ field may be
	excluded from the _full disclosure_ of any other selectively		excluded from the _full disclosure_ of any other selectively
	disclosable fields in its encompassing block. After selective		disclosable fields in its encompassing block. After selective
	disclosure, the selectively disclosed fields are not correlatable to		disclosure, the selectively disclosed fields are not correlatable to
	skipping to change at page 50, line 16 ¶		skipping to change at page 62, line 16 ¶
	chain-link confidentiality provides comprehensive correlation		chain-link confidentiality provides comprehensive correlation
	minimization because a discloser may use a non-disclosing metadata		minimization because a discloser may use a non-disclosing metadata
	ACDC prior to acceptance by the disclosee of the terms of the chain-		ACDC prior to acceptance by the disclosee of the terms of the chain-
	link confidentiality expressed in the rule section [CLC]. Thus only		link confidentiality expressed in the rule section [CLC]. Thus only
	malicious disclosees who violate chain-link confidentiality may		malicious disclosees who violate chain-link confidentiality may
	correlate between independent disclosures of the value details of		correlate between independent disclosures of the value details of
	distinct members in the list of aggregated blinded commitments.		distinct members in the list of aggregated blinded commitments.
	Nonetheless, they are not able to discover any as of yet undisclosed		Nonetheless, they are not able to discover any as of yet undisclosed
	(unblinded) value details.		(unblinded) value details.
	11.1. Selectively Disclosable Attribute ACDC		12.1. Selectively Disclosable Attribute ACDC
	In a *_selectively disclosable attribute_* ACDC, the set of		In a *_selectively disclosable attribute_* ACDC, the set of
	attributes is provided as an array of blinded blocks. Each attribute		attributes is provided as an array of blinded blocks. Each attribute
	in the set has its own dedicated blinded block. Each block has its		in the set has its own dedicated blinded block. Each block has its
	own SAID, d, field and UUID, u, field in addition to its attribute		own SAID, d, field and UUID, u, field in addition to its attribute
	field or fields. When an attribute block has more than one attribute		field or fields. When an attribute block has more than one attribute
	field then the set of fields in that block are not independently		field then the set of fields in that block are not independently
	selectively disclosable but MUST be disclosed together as a set.		selectively disclosable but MUST be disclosed together as a set.
	Notable is that the field labels of the selectively disclosable		Notable is that the field labels of the selectively disclosable
	attributes are also blinded because they only appear within the		attributes are also blinded because they only appear within the
	skipping to change at page 51, line 45 ¶		skipping to change at page 63, line 45 ¶
	"score": 96		"score": 96
	},		},
	{		{
	"d": "E9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PYgveY4-",		"d": "E9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PYgveY4-",
	"u": "0AghkDaG7OY1wjaDAE0qHcgN",		"u": "0AghkDaG7OY1wjaDAE0qHcgN",
	"name": "Jane Doe"		"name": "Jane Doe"
	}		}
	]		]
	}		}
	11.1.1. Blinded Attribute Array		12.1.1. Blinded Attribute Array
	Given that each attribute block's UUID, u, field has sufficient		Given that each attribute block's UUID, u, field has sufficient
	cryptographic entropy, then each attribute block's SAID, d, field		cryptographic entropy, then each attribute block's SAID, d, field
	provides a secure cryptographic digest of its contents that		provides a secure cryptographic digest of its contents that
	effectively blinds the attribute value from discovery given only its		effectively blinds the attribute value from discovery given only its
	Schema and SAID. To clarify, the adversary despite being given both		Schema and SAID. To clarify, the adversary despite being given both
	the schema of the attribute block and its SAID, d, field, is not able		the schema of the attribute block and its SAID, d, field, is not able
	to discover the remaining contents of the attribute block in a		to discover the remaining contents of the attribute block in a
	computationally feasible manner such as a rainbow table attack		computationally feasible manner such as a rainbow table attack
	[RB][DRB]. Therefore the UUID, u, field of each attribute block		[RB][DRB]. Therefore the UUID, u, field of each attribute block
	skipping to change at page 52, line 25 ¶		skipping to change at page 64, line 25 ¶
	represent the SAID, d, field of the attribute at zero-based index		represent the SAID, d, field of the attribute at zero-based index
	_i_. More precisely the set of attributes is expressed as the ordered		_i_. More precisely the set of attributes is expressed as the ordered
	set,		set,
	_{a_i for all i in {0, ..., N-1}}_.		_{a_i for all i in {0, ..., N-1}}_.
	The ordered set of _a_i_ may be also expressed as a list, that is,		The ordered set of _a_i_ may be also expressed as a list, that is,
	_[a_0, a_1, ...., a_(N-1)]_.		_[a_0, a_1, ...., a_(N-1)]_.
	11.1.2. Composed Schema for Selectively Disclosable Attribute Section		12.1.2. Composed Schema for Selectively Disclosable Attribute Section
	Because the selectively-disclosable attributes are provided by an		Because the selectively-disclosable attributes are provided by an
	array (list), the uncompacted variant in the schema uses an array of		array (list), the uncompacted variant in the schema uses an array of
	items and the anyOf composition operator to allow one or more of the		items and the anyOf composition operator to allow one or more of the
	items to be disclosed without requiring all to be disclosed. Thus		items to be disclosed without requiring all to be disclosed. Thus
	both the oneOf and anyOf composition operators are used. The oneOf		both the oneOf and anyOf composition operators are used. The oneOf
	is used to provide compact partial disclosure of the aggregate, _A_,		is used to provide compact partial disclosure of the aggregate, _A_,
	as the value of the top-level selectively-disclosable attribute		as the value of the top-level selectively-disclosable attribute
	section, A, field in its compact variant and the nested anyOf		section, A, field in its compact variant and the nested anyOf
	operator is used to enable selective disclosure in the uncompacted		operator is used to enable selective disclosure in the uncompacted
	selectively-disclosable variant.		selectively-disclosable variant.
	{		{
	"A":		"A":
	{		{
	"description": "attribute section",		"description": "selectively disclosable attribute aggregate section",
	"oneOf":		"oneOf":
	[		[
	{		{
	"description": "attribute section SAID",		"description": "attribute aggregate",
	"type": "string"		"type": "string"
	},		},
	{		{
	"description": "attribute details",		"description": "selectively disclosable attribute details",
	"type": "array",		"type": "array",
	"uniqueItems": true,		"uniqueItems": true,
	"items":		"items":
	{		{
	"anyOf":		"anyOf":
	[		[
	{		{
	"description": "issuer attribute",		"description": "issuer attribute",
	"type": "object",		"type": "object",
	"properties":		"properties":
	skipping to change at page 55, line 11 ¶		skipping to change at page 67, line 11 ¶
	}		}
	]		]
	}		}
	}		}
	]		]
	"additionalProperties": false		"additionalProperties": false
	}		}
	}		}
	11.1.3. Inclusion Proof via Aggregated List Digest		12.1.3. Inclusion Proof via Aggregated List Digest
	All the _a_i_ in the list are aggregated into a single aggregate		All the _a_i_ in the list are aggregated into a single aggregate
	digest denoted _A_ by computing the digest of their ordered		digest denoted _A_ by computing the digest of their ordered
	concatenation. This is expressed as follows:		concatenation. This is expressed as follows:
	_A = H(C(a_i for all i in {0, ..., N-1}))_ where _H_ is the digest		_A = H(C(a_i for all i in {0, ..., N-1}))_ where _H_ is the digest
	(hash) operator and _C_ is the concatentation operator.		(hash) operator and _C_ is the concatentation operator.
	To be explicit, using the targeted example above, let _a_0_ denote		To be explicit, using the targeted example above, let _a_0_ denote
	the SAID of the _Issuee_ attribute, _a_1_ denote the SAID of the		the SAID of the _Issuee_ attribute, _a_1_ denote the SAID of the
	skipping to change at page 58, line 5 ¶		skipping to change at page 70, line 5 ¶
	A private selectively disclosable ACDC provides significant		A private selectively disclosable ACDC provides significant
	correlation minimization because a presenter may use a metadata ACDC		correlation minimization because a presenter may use a metadata ACDC
	prior to acceptance by the disclosee of the terms of the chain-link		prior to acceptance by the disclosee of the terms of the chain-link
	confidentiality expressed in the rule section [CLC]. Thus only		confidentiality expressed in the rule section [CLC]. Thus only
	malicious disclosees who violate chain-link confidentiality may		malicious disclosees who violate chain-link confidentiality may
	correlate between presentations of a given private selectively		correlate between presentations of a given private selectively
	disclosable ACDC. Nonetheless, they are not able to discover any		disclosable ACDC. Nonetheless, they are not able to discover any
	undisclosed attributes.		undisclosed attributes.
	11.1.4. Inclusion Proof via Merkle Tree Root Digest		12.1.4. Inclusion Proof via Merkle Tree Root Digest
	The inclusion proof via aggregated list may be somewhat verbose when		The inclusion proof via aggregated list may be somewhat verbose when
	there are a large number of attribute blocks in the selectively		there are a large number of attribute blocks in the selectively
	disclosable attribute section. A more efficient approach is to		disclosable attribute section. A more efficient approach is to
	create a Merkle tree of the attribute block digests and let the		create a Merkle tree of the attribute block digests and let the
	aggregate, _A_, be the Merkle tree root digest [Mrkl]. Specifically,		aggregate, _A_, be the Merkle tree root digest [Mrkl]. Specifically,
	set the value of the top-level selectively-disclosable attribute		set the value of the top-level selectively-disclosable attribute
	section, A, field to the aggregate, _A_ whose value is the Merkle		section, A, field to the aggregate, _A_ whose value is the Merkle
	tree root digest [Mrkl].		tree root digest [Mrkl].
	The Merkle tree needs to have appropriate second-pre-image attack		The Merkle tree needs to have appropriate second-pre-image attack
	protection of interior branch nodes [TwoPI][MTSec]. The discloser		protection of interior branch nodes [TwoPI][MTSec]. The discloser
	then only needs to provide a subset of digests from the Merkle tree		then only needs to provide a subset of digests from the Merkle tree
	to prove that a given digest, _a_j_ contributed to the Merkle tree		to prove that a given digest, _a_j_ contributed to the Merkle tree
	root digest, _A_. For ACDCs with a small number of attributes the		root digest, _A_. For ACDCs with a small number of attributes the
	added complexity of the Merkle tree approach may not be worth the		added complexity of the Merkle tree approach may not be worth the
	savings in verbosity.		savings in verbosity.
	11.1.5. Hierarchical Derivation at Issuance of Selectively Disclosable		12.1.5. Hierarchical Derivation at Issuance of Selectively Disclosable
	Attribute ACDCs		Attribute ACDCs
	The amount of data transferred between the Issuer and Issuee (or		The amount of data transferred between the Issuer and Issuee (or
	recipient in the case of an untargeted ACDC) at issuance of a		recipient in the case of an untargeted ACDC) at issuance of a
	selectively disclosable attribute ACDC may be minimized by using a		selectively disclosable attribute ACDC may be minimized by using a
	hierarchical deterministic derivation function to derive the value of		hierarchical deterministic derivation function to derive the value of
	the UUDI, u, fields from a shared secret salt [Salt].		the UUDI, u, fields from a shared secret salt [Salt].
	There are several ways that the Issuer may securely share that secret		There are several ways that the Issuer may securely share that secret
	salt. Given that an Ed25519 key pair(s) controls each of the Issuer		salt. Given that an Ed25519 key pair(s) controls each of the Issuer
	and Issuee AIDs, (or recipient AID in the case of an untargeted ACDC)		and Issuee AIDs, (or recipient AID in the case of an untargeted ACDC)
	a corresponding X15519 asymmetric encryption key pair(s) may be		a corresponding X15519 asymmetric encryption key pair(s) may be
	derived from each controlling Ed25519 key pair(s) [EdSC][PSEd][TMEd].		derived from each controlling Ed25519 key pair(s)
	An X25519 public key may be derived from an Ed25519 public key.		[EdSC][PSEd][TMEd][SKEM]. An X25519 public key may be securely
	Likewise, an X25519 private key may be derived from an Ed25519		derived from an Ed25519 public key [KeyEx][SKEM]. Likewise, an
	private key [KeyEx].		X25519 private key may be securely derived from an Ed25519 private
			key [KeyEx][SKEM].
	In an interactive approach, the Issuer derives a public asymmetric		In an interactive approach, the Issuer derives a public asymmetric
	X25519 encryption key from the Issuee's published Ed25519 public key		X25519 encryption key from the Issuee's published Ed25519 public key
	and the Issuee derives a public asymmetric X25519 encryption key from		and the Issuee derives a public asymmetric X25519 encryption key from
	the Issuer's published Ed25519 public key. The two then interact via		the Issuer's published Ed25519 public key. The two then interact via
	a Diffie-Hellman (DH) key exchange to create a shared symmetric		a Diffie-Hellman (DH) key exchange to create a shared symmetric
	encryption key [KeyEx][DHKE]. The shared symmetric encryption key		encryption key [KeyEx][DHKE]. The shared symmetric encryption key
	may be used to encrypt the secret salt or the shared symmetric		may be used to encrypt the secret salt or the shared symmetric
	encryption key itself may be used has high entropy cryptographic		encryption key itself may be used has high entropy cryptographic
	material from which the secret salt may be derived.		material from which the secret salt may be derived.
	skipping to change at page 59, line 37 ¶		skipping to change at page 71, line 37 ¶
	attributes array is the string "0/0". Likewise, the next attribute's		attributes array is the string "0/0". Likewise, the next attribute's
	derivation path is the string "0/1" and so forth.		derivation path is the string "0/1" and so forth.
	In addition to the shared salt and ACDC template, the Issuer also		In addition to the shared salt and ACDC template, the Issuer also
	provides its signature(s) on its own generated compact version ACDC.		provides its signature(s) on its own generated compact version ACDC.
	The Issuer may also provide references to the anchoring issuance		The Issuer may also provide references to the anchoring issuance
	proof seals. Everything else an Issuee (recipient) needs to make a		proof seals. Everything else an Issuee (recipient) needs to make a
	verifiable presentation/disclosure can be computed at the time of		verifiable presentation/disclosure can be computed at the time of
	presentation/disclosure by the Issuee.		presentation/disclosure by the Issuee.
	11.2. Bulk-Issued Private ACDCs		12.2. Bulk-Issued Private ACDCs
	The purpose of bulk issuance is to enable the Issuee to use unique		The purpose of bulk issuance is to enable the Issuee to use unique
	ACDC more efficiently SAIDs to isolate and minimize correlation		ACDC more efficiently SAIDs to isolate and minimize correlation
	across different usage contexts of essentially the same ACDC while		across different usage contexts of essentially the same ACDC while
	allowing public commitments to the ACDC SAIDs. A private ACDC may be		allowing public commitments to the ACDC SAIDs. A private ACDC may be
	issued in bulk as a set. In its basic form, the only difference		issued in bulk as a set. In its basic form, the only difference
	between each ACDC is the top-level SAID, _d_, and UUID, _u_ field		between each ACDC is the top-level SAID, _d_, and UUID, _u_ field
	values. To elaborate, bulk issuance enables the use of un-		values. To elaborate, bulk issuance enables the use of un-
	correlatable copies while minimizing the associated data transfer and		correlatable copies while minimizing the associated data transfer and
	storage requirements. Essentially each copy (member) of a bulk		storage requirements. Essentially each copy (member) of a bulk
	skipping to change at page 61, line 19 ¶		skipping to change at page 73, line 19 ¶
	It is important to note that any group of colluding malicious		It is important to note that any group of colluding malicious
	verifiers may always make a statistical correlation between		verifiers may always make a statistical correlation between
	presentations despite technical barriers to cryptographically		presentations despite technical barriers to cryptographically
	provable correlation. In general, there is no cryptographic		provable correlation. In general, there is no cryptographic
	mechanism that precludes statistical correlation among a set of		mechanism that precludes statistical correlation among a set of
	colluding verifiers because they may make cryptographically		colluding verifiers because they may make cryptographically
	unverifiable or unprovable assertions about information presented to		unverifiable or unprovable assertions about information presented to
	them that may be proven as likely true using merely statistical		them that may be proven as likely true using merely statistical
	correlation techniques.		correlation techniques.
	11.3. Basic Bulk Issuance		12.3. Basic Bulk Issuance
	The amount of data transferred between the Issuer and Issuee (or		The amount of data transferred between the Issuer and Issuee (or
	recipient of an untargeted ACDC) at issuance of a set of bulk issued		recipient of an untargeted ACDC) at issuance of a set of bulk issued
	ACDCs may be minimized by using a hierarchical deterministic		ACDCs may be minimized by using a hierarchical deterministic
	derivation function to derive the value of the UUID, u, fields from a		derivation function to derive the value of the UUID, u, fields from a
	shared secret salt [Salt].		shared secret salt [Salt].
	As described above, there are several ways that the Issuer may		As described above, there are several ways that the Issuer may
	securely share a secret salt. Given that the Issuer and Issuee (or		securely share a secret salt. Given that the Issuer and Issuee (or
	recipient when untargeted) AIDs are each controlled by an Ed25519 key		recipient when untargeted) AIDs are each controlled by an Ed25519 key
	pair(s), a corresponding X15519 asymmetric encryption key pair(s) may		pair(s), a corresponding X15519 asymmetric encryption key pair(s) may
	be derived from the controlling Ed25519 key pair(s)		be derived from the controlling Ed25519 key pair(s)
	[EdSC][PSEd][TMEd]. An X25519 public key may be derived from an		[EdSC][PSEd][TMEd]. An X25519 public key may be securely derived
	Ed25519 public key. Likewise, an X25519 private key may be derived		from an Ed25519 public key [KeyEx][SKEM]. Likewise, an X25519
	from an Ed25519 private key [KeyEx].		private key may be securely derived from an Ed25519 private key
			[KeyEx][SKEM].
	In an interactive approach, the Issuer derives a public asymmetric		In an interactive approach, the Issuer derives a public asymmetric
	X25519 encryption key from the Issuee's published Ed25519 public key		X25519 encryption key from the Issuee's published Ed25519 public key
	and the Issuee derives a public asymmetric X25519 encryption key from		and the Issuee derives a public asymmetric X25519 encryption key from
	the Issuer's published Ed25519 public key. The two then interact via		the Issuer's published Ed25519 public key. The two then interact via
	a Diffie-Hellman (DH) key exchange to create a shared symmetric		a Diffie-Hellman (DH) key exchange to create a shared symmetric
	encryption key [KeyEx][DHKE]. The shared symmetric encryption key		encryption key [KeyEx][DHKE]. The shared symmetric encryption key
	may be used to encrypt the secret salt or the shared symmetric		may be used to encrypt the secret salt or the shared symmetric
	encryption key itself may be used has high entropy cryptographic		encryption key itself may be used has high entropy cryptographic
	material from which the secret salt may be derived.		material from which the secret salt may be derived.
	skipping to change at page 66, line 41 ¶		skipping to change at page 78, line 41 ¶
	only way to successfully publish such a seal is in a subsequent		only way to successfully publish such a seal is in a subsequent
	interaction event in a KEL that has not yet changed its key state via		interaction event in a KEL that has not yet changed its key state via
	a rotation event. Whereas any KEL that has changed its key state via		a rotation event. Whereas any KEL that has changed its key state via
	a rotation must be forked before the rotation. This makes the		a rotation must be forked before the rotation. This makes the
	forgery attempt either both detectable and recoverable via rotation		forgery attempt either both detectable and recoverable via rotation
	in any KEL that has not yet changed its key state or detectable as		in any KEL that has not yet changed its key state or detectable as
	duplicity in any KEL that has changed its key state. In any event,		duplicity in any KEL that has changed its key state. In any event,
	the issuance proof seal makes any later attempt at forgery using		the issuance proof seal makes any later attempt at forgery using
	compromised keys detectable.		compromised keys detectable.
	11.3.1. Inclusion Proof via Merkle Tree		12.3.1. Inclusion Proof via Merkle Tree
	The inclusion proof via aggregated list may be somewhat verbose when		The inclusion proof via aggregated list may be somewhat verbose when
	there are a very large number of bulk issued ACDCs in a given set. A		there are a very large number of bulk issued ACDCs in a given set. A
	more efficient approach is to create a Merkle tree of the blinded		more efficient approach is to create a Merkle tree of the blinded
	SAID digests, _b_k_ and set the aggregate _B_ value as the Merkle		SAID digests, _b_k_ and set the aggregate _B_ value as the Merkle
	tree root [Mrkl].		tree root [Mrkl].
	The Merkle tree needs to have appropriate second-pre-image attack		The Merkle tree needs to have appropriate second-pre-image attack
	protection of interior branch nodes [TwoPI][MTSec]. The discloser		protection of interior branch nodes [TwoPI][MTSec]. The discloser
	then only needs to provide a subset of digests from the Merkle tree		then only needs to provide a subset of digests from the Merkle tree
	to prove that a given digest, _b_k_ contributed to the Merkle tree		to prove that a given digest, _b_k_ contributed to the Merkle tree
	root digest. For a small numbered bulk issued set of ACDCs, the		root digest. For a small numbered bulk issued set of ACDCs, the
	added complexity of the Merkle tree approach may not be worth the		added complexity of the Merkle tree approach may not be worth the
	savings in verbosity.		savings in verbosity.
	11.3.2. Bulk Issuance of Private ACDCs with Unique Issuee AIDs		12.3.2. Bulk Issuance of Private ACDCs with Unique Issuee AIDs
	One potential point of provable but un-permissioned correlation among		One potential point of provable but un-permissioned correlation among
	any group of colluding malicious _Disclosees_ (Second-Party		any group of colluding malicious _Disclosees_ (Second-Party
	verifiers) may arise when the same Issuee AID is used for		verifiers) may arise when the same Issuee AID is used for
	presentation/disclosure to all _Disclosees_ in that group. Recall		presentation/disclosure to all _Disclosees_ in that group. Recall
	that the contents of private ACDCs are not disclosed except to		that the contents of private ACDCs are not disclosed except to
	permissioned _Disclosees_ (Second-Parties), thus a common _Issuee_		permissioned _Disclosees_ (Second-Parties), thus a common _Issuee_
	AID would only be a point of correlation for a group of colluding		AID would only be a point of correlation for a group of colluding
	malicious verifiers. But in some cases removing this un-permissioned		malicious verifiers. But in some cases removing this un-permissioned
	point of correlation may be desirable.		point of correlation may be desirable.
	skipping to change at page 67, line 42 ¶		skipping to change at page 79, line 42 ¶
	generate the UUID to be included in the inception event that		generate the UUID to be included in the inception event that
	generates the Issuee AID for the ACDC at index _k_. This can be		generates the Issuee AID for the ACDC at index _k_. This can be
	generated on-demand by the _Issuee_. Each unique _Issuee_ AID would		generated on-demand by the _Issuee_. Each unique _Issuee_ AID would
	also need its own KEL. But generation and publication of the		also need its own KEL. But generation and publication of the
	associated KEL can be delayed until the bulk-issued ACDC is actually		associated KEL can be delayed until the bulk-issued ACDC is actually
	used. This approach completely isolates a given _Issuee_ AID to a		used. This approach completely isolates a given _Issuee_ AID to a
	given context with respect to the use of a bulk-issued private ACDC.		given context with respect to the use of a bulk-issued private ACDC.
	This protects against even the un-permissioned correlation among a		This protects against even the un-permissioned correlation among a
	group of malicious Disclosees (Second Parties) via the Issuee AID.		group of malicious Disclosees (Second Parties) via the Issuee AID.
	11.4. Independent TEL Bulk-Issued ACDCs		12.4. Independent TEL Bulk-Issued ACDCs
	Recall that the purpose of using the aggregate _B_ for a bulk-issued		Recall that the purpose of using the aggregate _B_ for a bulk-issued
	set from which the TEL identifier is derived is to enable a set of		set from which the TEL identifier is derived is to enable a set of
	bulk issued ACDCs to share a single public TEL that provides dynamic		bulk issued ACDCs to share a single public TEL that provides dynamic
	revocation but without enabling un-permissioned correlation to any		revocation but without enabling un-permissioned correlation to any
	other members of the bulk set by virtue of the shared TEL. This		other members of the bulk set by virtue of the shared TEL. This
	enables the issuance/revocation/transfer state of all copies of a set		enables the issuance/revocation/transfer state of all copies of a set
	of bulk-issued ACDCs to be provided by a single TEL which minimizes		of bulk-issued ACDCs to be provided by a single TEL which minimizes
	the storage and compute requirements on the TEL registry while		the storage and compute requirements on the TEL registry while
	providing selective disclosure to prevent un-permissioned correlation		providing selective disclosure to prevent un-permissioned correlation
	skipping to change at page 68, line 47 ¶		skipping to change at page 81, line 5 ¶
	Nonetheless, using unique Issuee AIDs may further reduce correlation		Nonetheless, using unique Issuee AIDs may further reduce correlation
	by malicious Disclosees (Second-Party verifiers) beyond using		by malicious Disclosees (Second-Party verifiers) beyond using
	independent TELs.		independent TELs.
	To summarize the main benefit of this approach, in spite of its		To summarize the main benefit of this approach, in spite of its
	storage and compute burden, is that in some applications chain-link		storage and compute burden, is that in some applications chain-link
	confidentiality does not sufficiently deter un-permissioned malicious		confidentiality does not sufficiently deter un-permissioned malicious
	collusion. Therefore completely independent bulk-issued ACDCs may be		collusion. Therefore completely independent bulk-issued ACDCs may be
	used.		used.
	12. Appendix: Cryptographic Strength and Security		13. Appendix: Performance and Scalability
	12.1. Cryptographic Strength
			The compact disclosure and distribute property graph fragment
			mechanisms in ACDC can be leveraged to enable high performance at
			scale. Simply using SAIDs and signed SAIDs of ACDCs in whole or in
			part enables compact but securely attributed and verifiable
			references to ACDCs to be employed anywhere performance is an issue.
			Only the SAID and its signature need be transmitted to verify secure
			attribution of the data represented by the SAID. Later receipt of
			the data may be verified against the SAID. The signature does not
			need to be re-verified because a signature on a SAID is making a
			unique (to within the cryptographic strength of the SAID) commitment
			to the data represented by the SAID. The actual detailed ACDC in
			whole or in part may then be cached or provided on-demand or just-in-
			time.
			Hierarchical decomposition of data into a distributed verifiable
			property graph, where each ACDC is a distributed graph fragment,
			enables performant reuse of data or more compactly performant reuse
			of SAIDs and their signatures. The metadata and attribute sections
			of each ACDC provide a node in the graph and the edge section of each
			ACDC provides the edges to that node. Higher-up nodes in the graph
			with many lower-level nodes need only be transmitted, verified, and
			cached once per every node or leaf in the branch not redundantly re-
			transmitted and re-verified for each node or leaf as is the case for
			document-based verifiable credentials where the whole equivalent of
			the branched (graph) structure must be contained in one document.
			This truly enables the bow-tie model popularized by Ricardian
			contracts, not merely for contracts, but for all data authenticated,
			authorized, referenced, or conveyed by ACDCs.
			14. Appendix: Cryptographic Strength and Security
			14.1. Cryptographic Strength
	For crypto-systems with _perfect-security_, the critical design		For crypto-systems with _perfect-security_, the critical design
	parameter is the number of bits of entropy needed to resist any		parameter is the number of bits of entropy needed to resist any
	practical brute force attack. In other words, when a large random or		practical brute force attack. In other words, when a large random or
	pseudo-random number from a cryptographic strength pseudo-random		pseudo-random number from a cryptographic strength pseudo-random
	number generator (CSPRNG) [CSPRNG] expressed as a string of		number generator (CSPRNG) [CSPRNG] expressed as a string of
	characters is used as a seed or private key to a cryptosystem with		characters is used as a seed or private key to a cryptosystem with
	_perfect-security_, the critical design parameter is determined by		_perfect-security_, the critical design parameter is determined by
	the amount of random entropy in that string needed to withstand a		the amount of random entropy in that string needed to withstand a
	brute force attack. Any subsequent cryptographic operations must		brute force attack. Any subsequent cryptographic operations must
	skipping to change at page 70, line 11 ¶		skipping to change at page 82, line 44 ¶
	about 3600 * 24 * 365 = 313,536,000 = 2^(log_2313536000)=2^24.91 ~=		about 3600 * 24 * 365 = 313,536,000 = 2^(log_2313536000)=2^24.91 ~=
	2^25 seconds in a year. Thus this set of a million super computers		2^25 seconds in a year. Thus this set of a million super computers
	could try 2^(50+20+25) = 2^95 values per year. For a 128-bit random		could try 2^(50+20+25) = 2^95 values per year. For a 128-bit random
	number this means that the adversary would need on the order of		number this means that the adversary would need on the order of
	2^(128-95) = 2^33 = 8,589,934,592 years to find the right value.		2^(128-95) = 2^33 = 8,589,934,592 years to find the right value.
	This assumes that the value of breaking the cryptosystem is worth the		This assumes that the value of breaking the cryptosystem is worth the
	expense of that much computing power. Consequently, a cryptosystem		expense of that much computing power. Consequently, a cryptosystem
	with perfect security and 128 bits of cryptographic strength is		with perfect security and 128 bits of cryptographic strength is
	computationally infeasible to break via brute force attack.		computationally infeasible to break via brute force attack.
	12.2. Information Theoretic Security and Perfect Security		14.2. Information Theoretic Security and Perfect Security
	The highest level of cryptographic security with respect to a		The highest level of cryptographic security with respect to a
	cryptographic secret (seed, salt, or private key) is called		cryptographic secret (seed, salt, or private key) is called
	_information-theoretic security_ [ITPS]. A cryptosystem that has		_information-theoretic security_ [ITPS]. A cryptosystem that has
	this level of security cannot be broken algorithmically even if the		this level of security cannot be broken algorithmically even if the
	adversary has nearly unlimited computing power including quantum		adversary has nearly unlimited computing power including quantum
	computing. It must be broken by brute force if at all. Brute force		computing. It must be broken by brute force if at all. Brute force
	means that in order to guarantee success the adversary must search		means that in order to guarantee success the adversary must search
	for every combination of key or seed. A special case of		for every combination of key or seed. A special case of
	_information-theoretic security_ is called _perfect-security_ [ITPS].		_information-theoretic security_ is called _perfect-security_ [ITPS].
	_Perfect-security_ means that the ciphertext provides no information		_Perfect-security_ means that the ciphertext provides no information
	about the key. There are two well-known cryptosystems that exhibit		about the key. There are two well-known cryptosystems that exhibit
	_perfect security_. The first is a _one-time-pad_ (OTP) or Vernum		_perfect security_. The first is a _one-time-pad_ (OTP) or Vernum
	Cipher [OTP][VCphr], the other is _secret splitting_ [SSplt], a type		Cipher [OTP][VCphr], the other is _secret splitting_ [SSplt], a type
	of secret sharing [SShr] that uses the same technique as a _one-time-		of secret sharing [SShr] that uses the same technique as a _one-time-
	pad_.		pad_.
	13. Conventions and Definitions		15. Conventions and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	* SAID - Self-Addressing Identifier - any identifier which is		* SAID - Self-Addressing Identifier - any identifier which is
	deterministaclly generated out of the content, digest of the		deterministically generated out of the content, digest of the
	content		content
	14. Security Considerations		16. Security Considerations
	TODO Security		Refer to the body of the specification. Security considerations are
			included in the context of each section. The ACDC specification is
			security driven so the specification itself is riddled with
			discussions of the security considerations in the context in which
			those discussions are most understandable and relevant.
	15. IANA Considerations		17. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	16. References		18. References
	16.1. Normative References		18.1. Normative References
	[ACDC_ID] Smith, S., "IETF ACDC (Authentic Chained Data Containers)		[ACDC_ID] Smith, S., "IETF ACDC (Authentic Chained Data Containers)
	Internet Draft", 2022,		Internet Draft", 2022,
	<https://github.com/trustoverip/tswg-acdc-specification>.		<https://github.com/trustoverip/tswg-acdc-specification>.
	[CBOR] "CBOR Mapping Object Codes", n.d.,		[CBOR] "CBOR Mapping Object Codes", n.d.,
	<https://en.wikipedia.org/wiki/CBOR>.		<https://en.wikipedia.org/wiki/CBOR>.
	[CESR_ID] Smith, S., "IETF CESR (Composable Event Streaming		[CESR_ID] Smith, S., "IETF CESR (Composable Event Streaming
	Representation) Internet Draft", 2022,		Representation) Internet Draft", 2022,
	<https://github.com/WebOfTrust/ietf-cesr>.		<https://github.com/WebOfTrust/ietf-cesr>.
	[DIDK_ID] Feairheller, P., "IETF DID-KERI Internet Draft", 2022,		[DIDK_ID] Feairheller, P., "IETF DID-KERI Internet Draft", 2022,
	<https://github.com/WebOfTrust/ietf-did-keri>.		<https://github.com/WebOfTrust/ietf-did-keri>.
	[IPEX_ID] Feairheller, P., "IPEX (Issuance and Presentation		[IPEX_ID] Feairheller, P., "IPEX (Issuance and Presentation
	EXchange) Internet Draft", 2022,		EXchange) Internet Draft", 2022,
	<https://github.com/WebOfTrust/keripy/blob/master/ref/		<https://github.com/WebOfTrust/ietf-ipex>.
	Peer2PeerCredentials.md>.
	[JSch] "JSON Schema", n.d., <https://json-schema.org>.		[JSch] "JSON Schema", n.d., <https://json-schema.org>.
	[JSch_202012]		[JSch_202012]
	"JSON Schema 2020-12", n.d., <https://json-schema.org/		"JSON Schema 2020-12", n.d., <https://json-schema.org/
	draft/2020-12/release-notes.html>.		draft/2020-12/release-notes.html>.
	[JSON] "JavaScript Object Notation Delimeters", n.d.,		[JSON] "JavaScript Object Notation Delimeters", n.d.,
	<https://www.json.org/json-en.html>.		<https://www.json.org/json-en.html>.
	[KERI_ID] Smith, S., "IETF KERI (Key Event Receipt Infrastructure)		[KERI_ID] Smith, S., "IETF KERI (Key Event Receipt Infrastructure)
	Internet Draft", 2022,		Internet Draft", 2022,
	<https://github.com/WebOfTrust/ietf-keri>.		<https://github.com/WebOfTrust/ietf-keri>.
	[MGPK] "Msgpack Mapping Object Codes", n.d.,		[MGPK] "Msgpack Mapping Object Codes", n.d.,
	<https://github.com/msgpack/msgpack/blob/master/spec.md>.		<https://github.com/msgpack/msgpack/blob/master/spec.md>.
	[OOBI_ID] Smith, S., "IETF OOBI Internet Draft", 2022,		[OOBI_ID] Smith, S., "IETF OOBI (Out-Of-Band-Introduction) Internet
	<https://github.com/WebOfTrust>.		Draft", 2022, <https://github.com/WebOfTrust/ietf-oobi>.
	[Proof_ID] Feairheller, P., "IETF CESR-Proof Internet Draft", 2022,		[Proof_ID] Feairheller, P., "IETF CESR-Proof Internet Draft", 2022,
	<https://github.com/WebOfTrust/ietf-cesr-proof>.		<https://github.com/WebOfTrust/ietf-cesr-proof>.
	[PTEL_ID] Feairheller, P., "IETF PTEL (Public Transaction Event Log)		[PTEL_ID] Feairheller, P., "IETF PTEL (Public Transaction Event Log)
	Internet Draft", 2022,		Internet Draft", 2022,
	<https://github.com/WebOfTrust/ietf-ptel>.		<https://github.com/WebOfTrust/ietf-ptel>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.		<https://www.rfc-editor.org/rfc/rfc2119>.
			[RFC3986] "Uniform Resource Identifier (URI): Generic Syntax", n.d.,
			<https://datatracker.ietf.org/doc/html/rfc3986>.
	[RFC4627] "The application/json Media Type for JavaScript Object		[RFC4627] "The application/json Media Type for JavaScript Object
	Notation (JSON)", n.d.,		Notation (JSON)", n.d.,
	<https://datatracker.ietf.org/doc/rfc4627/>.		<https://datatracker.ietf.org/doc/rfc4627/>.
			[RFC6901] Bryan, P. C., Zyp, K., and M. Nottingham, "JavaScript
			Object Notation (JSON) Pointer", 2003,
			<https://datatracker.ietf.org/doc/html/rfc6901>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
	[RFC8259] "JSON (JavaScript Object Notation)", n.d.,		[RFC8259] "JSON (JavaScript Object Notation)", n.d.,
	<https://datatracker.ietf.org/doc/html/rfc8259>.		<https://datatracker.ietf.org/doc/html/rfc8259>.
			[RFC8820] "URI Design and Ownership", n.d.,
			<https://datatracker.ietf.org/doc/html/rfc8820>.
	[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", 4 December 2020,		Representation (CBOR)", 4 December 2020,
	<https://datatracker.ietf.org/doc/rfc8949/>.		<https://datatracker.ietf.org/doc/rfc8949/>.
	[SAID_ID] Smith, S., "IETF SAID (Self-Addressing IDentifier)		[SAID_ID] Smith, S., "IETF SAID (Self-Addressing IDentifier)
	Internet Draft", 2022,		Internet Draft", 2022,
	<https://github.com/WebOfTrust/ietf-said>.		<https://github.com/WebOfTrust/ietf-said>.
	16.2. Informative References		18.2. Informative References
			[Abuse] "Alice Attempts to Abuse a Verifiable Credential", n.d.,
			<https://github.com/WebOfTrustInfo/rwot9-
			prague/blob/master/final-documents/alice-attempts-abuse-
			verifiable-credential.md>.
	[ACDC_TF] "ACDC (Authentic Chained Data Container) Task Force",		[ACDC_TF] "ACDC (Authentic Chained Data Container) Task Force",
	n.d., <https://wiki.trustoverip.org/display/HOME/		n.d., <https://wiki.trustoverip.org/display/HOME/
	ACDC+%28Authentic+Chained+Data+Container%29+Task+Force>.		ACDC+%28Authentic+Chained+Data+Container%29+Task+Force>.
	[ACDC_WP] "Authentic Chained Data Containers (ACDC) White Paper",		[ACDC_WP] "Authentic Chained Data Containers (ACDC) White Paper",
	n.d., <https://github.com/SmithSamuelM/Papers/blob/master/		n.d., <https://github.com/SmithSamuelM/Papers/blob/master/
	whitepapers/ACDC.web.pdf>.		whitepapers/ACDC.web.pdf>.
	[BDay] "Birthday Attack", n.d.,		[BDay] "Birthday Attack", n.d.,
	skipping to change at page 75, line 24 ¶		skipping to change at page 88, line 24 ¶
	[RB] "Rainbow Table", n.d.,		[RB] "Rainbow Table", n.d.,
	<https://en.wikipedia.org/wiki/Rainbow_table>.		<https://en.wikipedia.org/wiki/Rainbow_table>.
	[RC] "Ricardian Contract", n.d.,		[RC] "Ricardian Contract", n.d.,
	<https://en.wikipedia.org/wiki/Ricardian_contract>.		<https://en.wikipedia.org/wiki/Ricardian_contract>.
	[Salt] "Salts, Nonces, and Initial Values", n.d.,		[Salt] "Salts, Nonces, and Initial Values", n.d.,
	<https://medium.com/@fridakahsas/salt-nonces-and-ivs-		<https://medium.com/@fridakahsas/salt-nonces-and-ivs-
	whats-the-difference-d7a44724a447>.		whats-the-difference-d7a44724a447>.
			[SKEM] "On using the same key pair for Ed25519 and an X25519
			based KEM", n.d., <https://eprint.iacr.org/2021/509>.
	[SShr] "Secret Sharing", n.d.,		[SShr] "Secret Sharing", n.d.,
	<https://en.wikipedia.org/wiki/Secret_sharing>.		<https://en.wikipedia.org/wiki/Secret_sharing>.
	[SSplt] "Secret Splitting", n.d.,		[SSplt] "Secret Splitting", n.d.,
	<https://www.ciphermachinesandcryptology.com/en/		<https://www.ciphermachinesandcryptology.com/en/
	secretsplitting.htm>.		secretsplitting.htm>.
	[TMal] "Transaction Malleability", n.d.,		[TMal] "Transaction Malleability", n.d.,
	<https://en.wikipedia.org/wiki/		<https://en.wikipedia.org/wiki/
	Transaction_malleability_problem>.		Transaction_malleability_problem>.
	skipping to change at page 76, line 24 ¶		skipping to change at page 89, line 28 ¶
	[W3C_VC] "W3C Verifiable Credentials Data Model v1.1", n.d.,		[W3C_VC] "W3C Verifiable Credentials Data Model v1.1", n.d.,
	<https://www.w3.org/TR/vc-data-model/>.		<https://www.w3.org/TR/vc-data-model/>.
	[XORA] "XORA (XORed Accumulator)", n.d.,		[XORA] "XORA (XORed Accumulator)", n.d.,
	<https://github.com/SmithSamuelM/Papers/blob/master/		<https://github.com/SmithSamuelM/Papers/blob/master/
	whitepapers/XORA.md>.		whitepapers/XORA.md>.
	Acknowledgments		Acknowledgments
	TODO acknowledge.		ACDC community.
	Author's Address		Author's Address
	S. Smith		S. Smith
	ProSapien LLC		ProSapien LLC
	Email: sam@prosapien.com		Email: sam@prosapien.com
End of changes. 84 change blocks.
	216 lines changed or deleted		813 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/