diff --git a/spec/spec.md b/spec/spec.md index 862fc2a..5e3cae2 100644 --- a/spec/spec.md +++ b/spec/spec.md @@ -39,7 +39,7 @@ Authentic Chained Data Containers (ACDC) https://github.com/trustoverip/tswg-acdc-specification/issues/8 ::: -An Authentic Chained Data Container (ACDC) specification is being incubated at the ToIP (Trust over IP) Foundation [[ref: TOIP]] [[ref: ACDC_TF]]. An ACDC is a compliant external proof format of the W3C VC 2.0 specification. The ACDC specification supports the use of KERI-based (Key Event Receipt Infrastructure) DID methods such as did:KERI and did:webs as primary identifiers W3C DID (Decentralized Identifier) specification [[ref: W3C_DID]]. A major use case for the ACDC specification is the use of ACDCs as vLEIs (verifiable Legal Entity Identifiers) within the ecosystem and infrastructure developed by[[ref: vLEI]] [[ref: GLEIF_vLEI]] [[ref: GLEIF_KERI]]. the Global Legal Entity Identifier Foundation [[ref: GLEIF]]. An ISO standard for vLEIs currently is under development at the International Organization for Standardization (ISO). ACDCs are dependent on a suite of related specifications along with the KERI [[ref: KERI]] specification. These include Composable Event Streaming Representation [[ref: CESR]], Self-addressing Identifier [[ref: SAID]], did:keri [[ref: DIDK_ID]], and Out-of-Band Introduction [[ref: OOBI]]. Some of the major distinguishing features of ACDCs include normative support for chaining, use of composable JSON Schema [[ref: JSch]] [[ref: JSchCp]], multiple serialization formats, namely, JSON [[ref: JSON]] [[ref: RFC4627]], CBOR [[ref: CBOR]] [[ref: RFC8949]], MGPK [[ref: MGPK]], and CESR [[ref: CESR]], support for Ricardian Contracts [[ref: RC]], support for Chain-Link Confidentiality [[ref: CLC]], a well-defined security model derived from KERI [[ref: KERI]], Compact formats for resource constrained applications, simple Partial Disclosure mechanisms and simple Selective Disclosure mechanisms. ACDCs provision data using a synergy of provenance, protection, and performance. +An Authentic Chained Data Container (ACDC) specification is being incubated at the ToIP (Trust over IP) Foundation [[18]] [[17]]. An ACDC is a compliant external proof format of the W3C VC 2.0 specification. The ACDC specification supports the use of KERI-based (Key Event Receipt Infrastructure) DID methods such as did:KERI and did:webs as primary identifiers W3C DID (Decentralized Identifier) specification [[ref: W3C_DID]]. A major use case for the ACDC specification is the use of ACDCs as vLEIs (verifiable Legal Entity Identifiers) [[25]] within the ecosystem and infrastructure developed by [[26]] [[27]] the Global Legal Entity Identifier Foundation [[24]]. An ISO standard for vLEIs currently is under development at the International Organization for Standardization (ISO). ACDCs are dependent on a suite of related specifications along with the KERI [[2]] specification. These include Composable Event Streaming Representation [[1]], Self-addressing Identifier [[3]], did:keri [[5]], and Out-of-Band Introduction [[4]]. Some of the major distinguishing features of ACDCs include normative support for chaining, use of composable JSON Schema [[10]] [[39]], multiple serialization formats, namely, JSON [[7]] [[9]], CBOR [[12]] [[13]], MGPK [[14]], and CESR [[1]], support for Ricardian Contracts [[43], support for Chain-Link Confidentiality [[44], a well-defined security model derived from KERI [[2]], Compact formats for resource constrained applications, simple Partial Disclosure mechanisms and simple Selective Disclosure mechanisms. ACDCs provision data using a synergy of provenance, protection, and performance. [//]: # (:::) @@ -60,11 +60,11 @@ With a little additional syntactic sugar, this primary facility of chained (tree To elaborate, the dictionary definition of credential is "evidence of authority, status, rights, entitlement to privileges, etc." Appropriately structured ACDCs may be used as credentials when their semantics provide verifiable evidence of authority. Chained ACDCs may provide delegated credentials. -Chains of ACDCs that merely provide proof-of-authorship (authenticity) of data may be appended to chains of ACDCs that provide proof-of-authority (delegation) to enable verifiable delegated authorized authorship of data. This is also a vital facility for authentic data supply chains. Furthermore, any physical supply chain may be measured, monitored, regulated, audited, and/or archived by a data supply chain acting as a digital twin [[ref: Twin]]. Therefore, ACDCs provide the critical enabling facility for an authentic data economy and, by association, an authentic real (twinned) economy. +Chains of ACDCs that merely provide proof-of-authorship (authenticity) of data may be appended to chains of ACDCs that provide proof-of-authority (delegation) to enable verifiable delegated authorized authorship of data. This is also a vital facility for authentic data supply chains. Furthermore, any physical supply chain may be measured, monitored, regulated, audited, and/or archived by a data supply chain acting as a digital twin [[54]]. Therefore, ACDCs provide the critical enabling facility for an authentic data economy and, by association, an authentic real (twinned) economy. -ACDCs act as securely attributed (authentic) fragments of a distributed property graph (PG) [[ref: PGM]] [[ref: Dots]]. Thus, ACDCs may be used to construct knowledge graphs expressed as property graphs [[ref: KG]]. ACDCs enable securely-attributed and privacy-protecting knowledge graphs. Semantically modulated verifiable provenanceable graphs enable authenticatable, delegable, attenuable, and aggregable authorizations and attributions. +ACDCs act as securely attributed (authentic) fragments of a distributed property graph (PG) [[56]] [[57]]. Thus, ACDCs may be used to construct knowledge graphs expressed as property graphs [[58]]. ACDCs enable securely-attributed and privacy-protecting knowledge graphs. Semantically modulated verifiable provenanceable graphs enable authenticatable, delegable, attenuable, and aggregable authorizations and attributions. -The ACDC specification (including its disclosure mechanisms) leverages two primary cryptographic operations, namely digests and digital signatures [[ref: Hash]] [[ref: DSig]]. These operations, when used in an ACDC, must have a security level, cryptographic strength, or entropy of approximately 128 bits [[ref: Level]]. (See [Annex A](#cryptographic-strength-and-security) for a discussion of cryptographic strength and security) +The ACDC specification (including its disclosure mechanisms) leverages two primary cryptographic operations, namely digests and digital signatures [[48]] [[52]]. These operations, when used in an ACDC, must have a security level, cryptographic strength, or entropy of approximately 128 bits [[53]]. (See [Annex A](#cryptographic-strength-and-security) for a discussion of cryptographic strength and security) An important property of high-strength cryptographic digests is that a verifiable cryptographic commitment (such as a digital signature) to the digest of some data is equivalent to a commitment to the data itself. The digest enables confidentiality because secure attribution of the commitment to the digest may be verified without disclosing the digested data. Later, confidential disclosure of the digested data can be verified against the digest. ACDCs leverage this property to enable compact chains of ACDCs that commit to (anchor or seal) data via digests. The data actually contained in an ACDC, therefore, may be merely its digest. The digested data may thereby be equivalently but more compactly and confidentially authenticated and authorized by the chain of ACDCs. @@ -230,7 +230,7 @@ ISO and IEC maintain terminological databases for use in standardization at the [[def: Rules]] -~ a top-level field map within an ACDC that provides a legal language as a Ricardian Contract [[ref: RC]], which is both human and machine-readable and referenceable by a cryptographic digest. +~ a top-level field map within an ACDC that provides a legal language as a Ricardian Contract [[43], which is both human and machine-readable and referenceable by a cryptographic digest. [[def: SEMVER]] @@ -288,7 +288,7 @@ ISO and IEC maintain terminological databases for use in standardization at the An ACDC may be modeled abstractly as a nested `key: value` mapping. To avoid confusion with the cryptographic use of the term key, the term field is used instead to refer to a mapping pair and the terms field label and field value for each member of a pair. These pairs can be represented by two tuples e.g., `(label, value)`. This terminology can be qualified, when necessary, by using the term field map to reference such a mapping. Field maps may be nested where a given field value is itself a reference to another field map. A nested set of fields is called a nested field map or simply a nested map for short. -A field may be represented by a [[ref: Framing Code]] or block delimited serialization. In a block delimited serialization, such as JSON, each field map is represented by an object block with block delimiters such as `{}` [[ref: RFC8259]] [[ref: JSON]] [[ref: RFC4627]]. Given this equivalence, the term block or nested block also may be used as synonymous with field map or nested field map. In many programming languages, a field map is implemented as a dictionary or hash table in order to enable performant asynchronous lookup of a field value from its field label. Reproducible serialization of field maps requires a canonical ordering of those fields. One such canonical ordering is called insertion or field creation order. A list of `(field, value)` pairs provides an ordered representation of any field map. Most programming languages now support ordered dictionaries or hash tables that provide reproducible iteration over a list of ordered field `(label, value)` pairs where the ordering is the insertion or field creation order. This enables reproducible round-trip serialization/deserialization of field maps. ACDCs depend on insertion ordered field maps for canonical serialization/deserialization. ACDCs support multiple serialization types, namely JSON, CBOR, MGPK, and CESR but for the sake of simplicity, JSON only will be used for examples [[ref: RFC8259]] [[ref: JSON]]. The basic set of normative field labels in ACDC field maps is defined in the following table. +A field may be represented by a [[ref: Framing Code]] or block delimited serialization. In a block delimited serialization, such as JSON, each field map is represented by an object block with block delimiters such as `{}` [[8]] [[7]] [[9]]. Given this equivalence, the term block or nested block also may be used as synonymous with field map or nested field map. In many programming languages, a field map is implemented as a dictionary or hash table in order to enable performant asynchronous lookup of a field value from its field label. Reproducible serialization of field maps requires a canonical ordering of those fields. One such canonical ordering is called insertion or field creation order. A list of `(field, value)` pairs provides an ordered representation of any field map. Most programming languages now support ordered dictionaries or hash tables that provide reproducible iteration over a list of ordered field `(label, value)` pairs where the ordering is the insertion or field creation order. This enables reproducible round-trip serialization/deserialization of field maps. ACDCs depend on insertion ordered field maps for canonical serialization/deserialization. ACDCs support multiple serialization types, namely JSON, CBOR, MGPK, and CESR but for the sake of simplicity, JSON only will be used for examples [[8]] [[7]]. The basic set of normative field labels in ACDC field maps is defined in the following table. ### Top-Level fields @@ -298,15 +298,15 @@ The following table defines the top-level fields in an ACDC and their order of a | Label | Title | Description | |:-:|:--|:--| |`v`| Version String| Regexable format: ACDCvvSSSShhhhhh_ that provides protocol type, version, serialization type, size, and terminator. | -|`d`| Digest ([[ref: SAID]]) | Self-referential fully qualified cryptographic digest of enclosing map. | +|`d`| Digest ([[3]]) | Self-referential fully qualified cryptographic digest of enclosing map. | |`u`| UUID | Random Universally Unique Identifier as fully qualified high entropy pseudo-random string, a salty nonce. | |`i`| Issuer Identifier ([[ref: AID]])| Autonomic Identifier whose control authority is established via KERI verifiable Key State. | -|`rd`| Registry Digest ([[ref: SAID]]) | Issuance and/or revocation, transfer, or retraction registry for ACDC | -|`s`| Schema| Either the [[ref: SAID]] of a JSON Schema block or the block itself. | -|`a`| Attribute| Either the [[ref: SAID]] of a block of Attributes or the block itself. | +|`rd`| Registry Digest ([[3]]) | Issuance and/or revocation, transfer, or retraction registry for ACDC | +|`s`| Schema| Either the [[3]] of a JSON Schema block or the block itself. | +|`a`| Attribute| Either the [[3]] of a block of Attributes or the block itself. | |`A`| Attribute Aggregate| Either the aggregate of a selectively disclosable block of attributes or the block itself. | -|`e`| Edge| Either the [[ref: SAID]] of a block of Edges or the block itself.| -|`r`| Rule | Either the [[ref: SAID]] a block of Rules or the block itself. | +|`e`| Edge| Either the [[3]] of a block of Edges or the block itself.| +|`r`| Rule | Either the [[3]] a block of Rules or the block itself. | #### Field ordering @@ -323,10 +323,10 @@ These appear at other levels besides the top-level of an ACDC. | Label | Title | Description | |:-:|:--|:--| -|`d`| Digest ([[ref: SAID]]) | Self-referential fully qualified cryptographic digest of enclosing map. | +|`d`| Digest ([[3]]) | Self-referential fully qualified cryptographic digest of enclosing map. | |`u`| UUID | Random Universally Unique Identifier as fully qualified high entropy pseudo-random string, a salty nonce. | |`i`| Identifier ([[ref: AID]])| Context dependent AID as determined by its enclosing map such as Issuee identifier. | -|`n`| Node| [[ref: SAID]] of another ACDC as the terminating point (vertex) of a directed Edge that connects the encapsulating ACDC node to the specified ACDC node as a fragment of a distributed property graph (PG).| +|`n`| Node| [[3]] of another ACDC as the terminating point (vertex) of a directed Edge that connects the encapsulating ACDC node to the specified ACDC node as a fragment of a 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 Language| Text of Ricardian contract clause.| @@ -337,22 +337,22 @@ The primary field labels are compact in that they use only one or two characters ### Version String field -The Version String, `v`, field shall be the first field in any top-level ACDC field map encoded in JSON, CBOR, or MGPK as a Message body [[spec: RFC4627]] [[spec: RFC4627]] [[ref: CBOR]] [[ref: RFC8949]] [[ref: MGPK]]. It provides a regular expression target for determining a serialized field map's serialization format and size (character count) constituting an ACDC message body. A Stream parser may use the Version String to extract and deserialize (deterministically) any serialized Stream of ACDC Message bodies. Each ACDC Message body in a Stream may use a different serialization type. The format for the Version String field value is defined in the CESR specification [[ref: CESR]]. +The Version String, `v`, field shall be the first field in any top-level ACDC field map encoded in JSON, CBOR, or MGPK as a Message body [[spec: RFC4627]] [[spec: RFC4627]] [[12]] [[13]] [[14]]. It provides a regular expression target for determining a serialized field map's serialization format and size (character count) constituting an ACDC message body. A Stream parser may use the Version String to extract and deserialize (deterministically) any serialized Stream of ACDC Message bodies. Each ACDC Message body in a Stream may use a different serialization type. The format for the Version String field value is defined in the CESR specification [[1]]. -The protocol field, `PPPP` value in the Version String shall be `ACDC` for the ACDC protocol. The version field, `VVV`, shall encode the current version of the ACDC protocol [[ref: CESR]]. +The protocol field, `PPPP` value in the Version String shall be `ACDC` for the ACDC protocol. The version field, `VVV`, shall encode the current version of the ACDC protocol [[1]]. ##### Legacy Version String field format -Compliant ACDC version 2.XX implementations shall support the old ACDC version 1.x Version String format to properly verify Message bodies created with 1.x format events. The old version 1.X Version String format is defined in the CESR specification [[ref: CESR]]. The protocol field, `PPPP` value in the version string shall be `ACDC` for the ACDC protocol. The version field, `vv`, shall encode the old version of the ACDC protocol [[ref: CESR]]. +Compliant ACDC version 2.XX implementations shall support the old ACDC version 1.x Version String format to properly verify Message bodies created with 1.x format events. The old version 1.X Version String format is defined in the CESR specification [[1]]. The protocol field, `PPPP` value in the version string shall be `ACDC` for the ACDC protocol. The version field, `vv`, shall encode the old version of the ACDC protocol [[1]]. ### Self-addressing identifier (SAID) fields -Some fields in ACDCs may have for their value either a field map or a SAID. A SAID follows the SAID protocol [[ref: SAID]]. Essentially, a [[ref: SAID]] is a Self-addressing identifier (self-referential content addressable). A SAID is a special type of cryptographic digest of its encapsulating field map (block). The encapsulating block of a SAID is called a SAD (Self-addressed data). Using a SAID as a field value enables a more compact but secure representation of the associated block (SAD) from which the SAID is derived. Any nested field map that includes a SAID field (i.e., is, therefore, a SAD) may be compacted into its SAID. The uncompacted blocks for each associated SAID may be attached or cached to optimize bandwidth and availability without decreasing security. +Some fields in ACDCs may have for their value either a field map or a SAID. A SAID follows the SAID protocol [[3]]. Essentially, a [[3]] is a Self-addressing identifier (self-referential content addressable). A SAID is a special type of cryptographic digest of its encapsulating field map (block). The encapsulating block of a SAID is called a SAD (Self-addressed data). Using a SAID as a field value enables a more compact but secure representation of the associated block (SAD) from which the SAID is derived. Any nested field map that includes a SAID field (i.e., is, therefore, a SAD) may be compacted into its SAID. The uncompacted blocks for each associated SAID may be attached or cached to optimize bandwidth and availability without decreasing security. Several top-level ACDC fields may have for their value either a serialized field map or the SAID of that field map. Each SAID provides a stable, universal, cryptographically verifiable, and agile reference to its encapsulating block (serialized field map). These include the `d`, and `rd` fields. Moreover, the value of top-level `s`, `a`, `e`, and `r` fields may be replaced by the SAID of their associated field map. When replaced by their SAID, these top-level sections are in compact form. -Recall that a cryptographic commitment (such as a digital signature or cryptographic digest) on a given digest with sufficient cryptographic strength, including collision resistance [[ref: HCR]] [[ref: QCHC]], is equivalent to a commitment to the block from which the given digest was derived. Specifically, a digital signature on a SAID makes a verifiable cryptographic non-repudiable commitment that is equivalent to a commitment on the full serialization of the associated block from which the SAID was derived. This enables reasoning about ACDCs in whole or in part via their SAIDS in a fully interoperable, verifiable, compact, and secure manner. This also supports the well-known bow-tie model of Ricardian Contracts [[ref: RC]]. This includes reasoning about the whole ACDC given by its top-level SAID, `d`, field, as well as reasoning about any nested sections using their SAIDS. +Recall that a cryptographic commitment (such as a digital signature or cryptographic digest) on a given digest with sufficient cryptographic strength, including collision resistance [[34]] [[35]], is equivalent to a commitment to the block from which the given digest was derived. Specifically, a digital signature on a SAID makes a verifiable cryptographic non-repudiable commitment that is equivalent to a commitment on the full serialization of the associated block from which the SAID was derived. This enables reasoning about ACDCs in whole or in part via their SAIDS in a fully interoperable, verifiable, compact, and secure manner. This also supports the well-known bow-tie model of Ricardian Contracts [[43]. This includes reasoning about the whole ACDC given by its top-level SAID, `d`, field, as well as reasoning about any nested sections using their SAIDS. ### Registry SAID field @@ -361,17 +361,17 @@ When present, the registry SAID, `rd` field value is the SAID of the initializin ### Universally unique identifier (UUID) fields -The purpose of the UUID, `u`, field in any block is to provide sufficient entropy to the SAID, `d`, field of the associated block to make computationally infeasible any brute force attacks on that block that attempt to discover the block contents from the schema and the SAID. The UUID, `u`, field may be considered a salty nonce [[ref: Salt]]. Without the entropy provided the UUID, `u`, field, an adversary may be able to reconstruct the block contents merely from the SAID of the block and the [[ref: Schema]] of the block using a rainbow or dictionary attack on the set of field values allowed by the Schema [[ref: RB]] [[ref: DRB]]. The effective security level, entropy, or cryptographic strength of the schema-compliant field values may be much less than the cryptographic strength of the SAID digest. Another way of saying this is that the cardinality of the power set of all combinations of allowed field values may be much less than the cryptographic strength of the SAID. Thus, an adversary could successfully discover via brute force the exact block by creating digests of all the elements of the power set which may be small enough to be computationally feasible instead of inverting the SAID itself. Sufficient entropy in the `u` 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 algorithm itself. +The purpose of the UUID, `u`, field in any block is to provide sufficient entropy to the SAID, `d`, field of the associated block to make computationally infeasible any brute force attacks on that block that attempt to discover the block contents from the schema and the SAID. The UUID, `u`, field may be considered a salty nonce [[29]]. Without the entropy provided the UUID, `u`, field, an adversary may be able to reconstruct the block contents merely from the SAID of the block and the [[ref: Schema]] of the block using a rainbow or dictionary attack on the set of field values allowed by the Schema [[30]] [[31]]. The effective security level, entropy, or cryptographic strength of the schema-compliant field values may be much less than the cryptographic strength of the SAID digest. Another way of saying this is that the cardinality of the power set of all combinations of allowed field values may be much less than the cryptographic strength of the SAID. Thus, an adversary could successfully discover via brute force the exact block by creating digests of all the elements of the power set which may be small enough to be computationally feasible instead of inverting the SAID itself. Sufficient entropy in the `u` 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 algorithm itself. 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`, field then its associated SAID, `d`, field makes a blinded commitment to the contents of that block. The UUID, `u`, field is the blinding factor. This makes that block securely partially disclosable or even selectively disclosable notwithstanding disclosure of the associated Schema of the block. The block contents can only be discovered given 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, `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, may be disclosed in a privacy-preserving (correlation minimizing). ### Autonomic IDentifier (AID) fields -Some fields, such as the `i`, Issuer identifier field, must each have an [[ref: AID]] as its value. An AID is a fully qualified Self-certifying Identifier (SCID) that follows the KERI protocol [[ref: KERI]] [[ref: KERI]]. An AID is derived from one or more `(public, private)` key pairs using asymmetric or public-key cryptography to create verifiable digital signatures [[ref: DSig]]. Each AID has a set of one or more Controllers who each control a private key. By virtue of their private key(s), the Controllers may make statements on behalf of the associated AID backed by uniquely verifiable commitments via digital signatures on those statements. Any entity then may verify those signatures using the associated set of public keys. No shared or trusted relationship between the Controllers and Verifiers is required. The verifiable key state for AIDs is established with the KERI protocol [[ref: KERI]]. The use of AIDS enables ACDCs to be used in a portable but securely attributable, fully decentralized manner in an ecosystem that spans trust domains. +Some fields, such as the `i`, Issuer identifier field, must each have an [[ref: AID]] as its value. An AID is a fully qualified Self-certifying Identifier (SCID) that follows the KERI protocol [[2]] [[2]]. An AID is derived from one or more `(public, private)` key pairs using asymmetric or public-key cryptography to create verifiable digital signatures [[52]]. Each AID has a set of one or more Controllers who each control a private key. By virtue of their private key(s), the Controllers may make statements on behalf of the associated AID backed by uniquely verifiable commitments via digital signatures on those statements. Any entity then may verify those signatures using the associated set of public keys. No shared or trusted relationship between the Controllers and Verifiers is required. The verifiable key state for AIDs is established with the KERI protocol [[2]]. The use of AIDS enables ACDCs to be used in a portable but securely attributable, fully decentralized manner in an ecosystem that spans trust domains. ### Namespaced AIDs -Because KERI is agnostic about the namespace for any particular AID, different namespace standards may be used to express KERI AIDs or identifiers derived from AIDs as the value of these AID related fields in an ACDC. Some of the examples below use the W3C DID namespace specification with the `did:keri` method [[ref: DIDK_ID]. However, the examples would have the same validity from a KERI perspective if some other supported namespace was used or no namespace was used at all. The latter case consists of a bare KERI AID (identifier prefix) expressed in CESR format [[ref: CESR]]. +Because KERI is agnostic about the namespace for any particular AID, different namespace standards may be used to express KERI AIDs or identifiers derived from AIDs as the value of these AID related fields in an ACDC. Some of the examples below use the W3C DID namespace specification with the `did:keri` method [[ref: DIDK_ID]. However, the examples would have the same validity from a KERI perspective if some other supported namespace was used or no namespace was used at all. The latter case consists of a bare KERI AID (identifier prefix) expressed in CESR format [[1]]. ### Attribute field @@ -406,7 +406,7 @@ An overview of each variant is explained below. ### Most compact form SAID -As defined in the Schema section below, ACDC variants are defined by composable JSON Schema. The primary Operator for such composition is `oneOf`. The use of the `oneOf` operator for an ACDC schema enables the use of any combination of compacted/uncompacted top-level sections as well as nested blocks. When compact, any section or nested block may be represented merely by its [[ref: JSch]] [[ref: JSchCp]]. +As defined in the Schema section below, ACDC variants are defined by composable JSON Schema. The primary Operator for such composition is `oneOf`. The use of the `oneOf` operator for an ACDC schema enables the use of any combination of compacted/uncompacted top-level sections as well as nested blocks. When compact, any section or nested block may be represented merely by its [[10]] [[39]]. However, for the sake of verifiability, each section or block that is compactable shall have only one SAID regardless of how many different variants its `oneOf` compositions allow. Therefore, there must be one and only one unambiguous way to compute the SAID of a compactifiable section or block with compactifiable nested blocks. This is called the "most compact form" SAID computation algorithm. The basis of the algorithm is that the SAID of a given block is verifiable against that block in expanded form but that SAID can be embedded in an enclosing block in compact form. The SAID of the enclosing block makes a verifiable commitment to the given block via the appearance of only the SAID of the given block. The SAID of the "most compact form" can be computed by a depth-first search. First, compute the SAIDs of the expanded leaf nodes of the tree, then compact the leaves, then compute the SAIDs of their enclosing blocks, then compact those, and so on until the trunk has been reached. @@ -436,15 +436,15 @@ The top-level section field values of a Compact ACDC are the SAIDs of each uncom ### Public ACDC -Given that there is no top-level UUID, `u`, field in an ACDC, then knowledge of both the schema of the ACDC and the top-level SAID, `d`, field may enable the discovery of the remaining contents of the ACDC via a rainbow table attack [[ref: RB]] [[ref: DRB]]. Therefore, although the top-level, `d`, field is a cryptographic digest, it may not securely blind the contents of the ACDC when knowledge of the Schema is available. The field values may be discoverable. Consequently, any cryptographic commitment to the top-level SAID, `d`, field may provide a fixed point of correlation potentially to the ACDC field values themselves in spite of non-disclosure of those field values. Thus, an ACDC without a top-level UUID, `u`, field must be considered a public (non-confidential) ACDC. +Given that there is no top-level UUID, `u`, field in an ACDC, then knowledge of both the schema of the ACDC and the top-level SAID, `d`, field may enable the discovery of the remaining contents of the ACDC via a rainbow table attack [[30]] [[31]]. Therefore, although the top-level, `d`, field is a cryptographic digest, it may not securely blind the contents of the ACDC when knowledge of the Schema is available. The field values may be discoverable. Consequently, any cryptographic commitment to the top-level SAID, `d`, field may provide a fixed point of correlation potentially to the ACDC field values themselves in spite of non-disclosure of those field values. Thus, an ACDC without a top-level UUID, `u`, field must be considered a public (non-confidential) ACDC. ### Private ACDC -Given a top-level UUID, `u`, field, whose value has sufficient cryptographic entropy, then the top-level SAID, `d`, field of an ACDC may provide a secure cryptographic digest that blinds the contents of the ACDC [[ref: Hash]]. An adversary when given both the Schema of the ACDC and the top-level SAID, `d`, field, is not able to discover the remaining contents of the ACDC in a computationally feasible manner such as through a rainbow table attack [[ref: RB]] [[ref: DRB]]. Therefore, the top-level, UUID, `u`, field may be used to securely blind the contents of the ACDC notwithstanding knowledge of the Schema and top-level, SAID, `d`, field. Moreover, a cryptographic commitment to that that top-level SAID, `d`, field does not provide a fixed point of correlation to the other ACDC field values themselves unless and until there has been a disclosure of those field values. Thus, an ACDC with a sufficiently high entropy top-level UUID, `u`, field may be considered a private (confidential) ACDC. enables a verifiable commitment to the top-level SAID of a private ACDC to be made prior to the disclosure of the details of the ACDC itself without leaking those contents. This is called Partial Disclosure. Furthermore, the inclusion of a UUID, `u`, field in a block also enables Selective Disclosure mechanisms described later in the section on Selective Disclosure. +Given a top-level UUID, `u`, field, whose value has sufficient cryptographic entropy, then the top-level SAID, `d`, field of an ACDC may provide a secure cryptographic digest that blinds the contents of the ACDC [[48]]. An adversary when given both the Schema of the ACDC and the top-level SAID, `d`, field, is not able to discover the remaining contents of the ACDC in a computationally feasible manner such as through a rainbow table attack [[30]] [[31]]. Therefore, the top-level, UUID, `u`, field may be used to securely blind the contents of the ACDC notwithstanding knowledge of the Schema and top-level, SAID, `d`, field. Moreover, a cryptographic commitment to that that top-level SAID, `d`, field does not provide a fixed point of correlation to the other ACDC field values themselves unless and until there has been a disclosure of those field values. Thus, an ACDC with a sufficiently high entropy top-level UUID, `u`, field may be considered a private (confidential) ACDC. enables a verifiable commitment to the top-level SAID of a private ACDC to be made prior to the disclosure of the details of the ACDC itself without leaking those contents. This is called Partial Disclosure. Furthermore, the inclusion of a UUID, `u`, field in a block also enables Selective Disclosure mechanisms described later in the section on Selective Disclosure. ### Metadata ACDC -An empty, top-level UUID, `u`, field appearing in an ACDC indicates that the ACDC is a metadata ACDC. The purpose of a metadata ACDC is to provide a mechanism for a Discloser to make cryptographic commitments to the metadata of a yet to be disclosed private ACDC without providing any point of correlation to the actual top-level SAID, `d`, field of that yet to be disclosed ACDC. The top-level SAID, `d`, field, of the metadata ACDC, is cryptographically derived from an ACDC with an empty top-level UUID, `u`, field so its value will necessarily be different from that of an ACDC with a high entropy top-level UUID, `u`, field value. Nonetheless, the Discloser may make a non-repudiable cryptographic commitment to the metadata SAID in order to initiate a contractually protected exchange without leaking correlation to the actual ACDC to be disclosed [[ref: CLC]]. A Disclosee may verify the other metadata information in the metadata ACDC before agreeing to any restrictions imposed by the future disclosure. The metadata includes the Issuer, the Schema, the provenanced Edges, and the Rules (terms-of-use). The top-level Attribute section, `a`, field value, or the top-level Attribute aggregate, `A` field value of a metadata ACDC may be empty so that its value is not correlatable across disclosures (presentations). Should the potential Disclosee refuse to agree to the Rules, then the Discloser has not leaked the SAID of the actual ACDC or the SAID of the Attribute block that would have been disclosed. +An empty, top-level UUID, `u`, field appearing in an ACDC indicates that the ACDC is a metadata ACDC. The purpose of a metadata ACDC is to provide a mechanism for a Discloser to make cryptographic commitments to the metadata of a yet to be disclosed private ACDC without providing any point of correlation to the actual top-level SAID, `d`, field of that yet to be disclosed ACDC. The top-level SAID, `d`, field, of the metadata ACDC, is cryptographically derived from an ACDC with an empty top-level UUID, `u`, field so its value will necessarily be different from that of an ACDC with a high entropy top-level UUID, `u`, field value. Nonetheless, the Discloser may make a non-repudiable cryptographic commitment to the metadata SAID in order to initiate a contractually protected exchange without leaking correlation to the actual ACDC to be disclosed [[44]. A Disclosee may verify the other metadata information in the metadata ACDC before agreeing to any restrictions imposed by the future disclosure. The metadata includes the Issuer, the Schema, the provenanced Edges, and the Rules (terms-of-use). The top-level Attribute section, `a`, field value, or the top-level Attribute aggregate, `A` field value of a metadata ACDC may be empty so that its value is not correlatable across disclosures (presentations). Should the potential Disclosee refuse to agree to the Rules, then the Discloser has not leaked the SAID of the actual ACDC or the SAID of the Attribute block that would have been disclosed. Given the metadata ACDC, the potential Disclosee is able to verify the Issuer, the Schema, the provenanced Edges, and Rules prior to agreeing to the Rules. Similarly, an Issuer may use a metadata ACDC to get agreement to a contractual waiver expressed in the Rules section with a potential Issuee prior to issuance. Should the Issuee refuse to accept the terms of the waiver, then the Issuer has not leaked the SAID of the actual ACDC that would have been issued nor the SAID of its attributes block nor the Attribute values themselves. @@ -640,15 +640,15 @@ The schema for the Compact private ACDC example above is provided below. #### Type-is-schema -Notable is the fact that no top-level type fields exist in an ACDC. This is because the [[ref: Schema]], `s`, field itself is the type field for the ACDC and its parts. ACDCs follow the design principle of separation of concerns between a data container's actual payload information and the type information of that container's payload. In this sense, type information is metadata, not data. The Schema dialect used by ACDCs is JSON Schema 2020-12 [[ref: JSch]] [[ref: JSch_202012]]. JSON Schema supports composable schema (subschema), conditional Schema (subschema), and regular expressions in the Schema. 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) information about the payload [[ref: JSchCp]] [[ref: JSchRE]] [[ref: JSchId]] [[ref: JSchCx]]. A static but composed schema allows a verifiably immutable set of 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. +Notable is the fact that no top-level type fields exist in an ACDC. This is because the [[ref: Schema]], `s`, field itself is the type field for the ACDC and its parts. ACDCs follow the design principle of separation of concerns between a data container's actual payload information and the type information of that container's payload. In this sense, type information is metadata, not data. The Schema dialect used by ACDCs is JSON Schema 2020-12 [[10]] [[11]]. JSON Schema supports composable schema (subschema), conditional Schema (subschema), and regular expressions in the Schema. 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) information about the payload [[39]] [[40]] [[41]] [[42]]. A static but composed schema allows a verifiably immutable set of 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. #### Schema ID field label -The usual field label for SAID fields in ACDCs is `d`. In the case of the [[ref: Schema]] section, however, the field label for the SAID of the Schema section is `$id`. This repurposes the Schema id field label, `$id` as defined by JSON Schema [[ref: JSchId]] [[ref: JSchCx]]. The top-level id, `$id`, field value in a JSON Schema provides a unique identifier of the Schema instance. In a non-ACDC schema, the value of the id, `$id`, field is expressed as a URI. This is called the Base URI of the schema. In an ACDC schema, however, the top-level id, `$id`, field value is repurposed. This field value must include the SAID of the schema. This ensures that the ACDC Schema is static and verifiable to their SAIDS. A verifiably static Schema satisfies one of the essential security properties of ACDCs as discussed below. There are several ACDC supported formats for the value of the top-level id, `$id`, field but all of the formats must include the SAID of the Schema (see below). Correspondingly, the value of the top-level schema, `s`, field must be the SAID included in the schema's top-level `$id` field. The detailed schema is either attached or cached and maybe discovered via its SAIDified, id, `$id`, field value. +The usual field label for SAID fields in ACDCs is `d`. In the case of the [[ref: Schema]] section, however, the field label for the SAID of the Schema section is `$id`. This repurposes the Schema id field label, `$id` as defined by JSON Schema [[41]] [[42]]. The top-level id, `$id`, field value in a JSON Schema provides a unique identifier of the Schema instance. In a non-ACDC schema, the value of the id, `$id`, field is expressed as a URI. This is called the Base URI of the schema. In an ACDC schema, however, the top-level id, `$id`, field value is repurposed. This field value must include the SAID of the schema. This ensures that the ACDC Schema is static and verifiable to their SAIDS. A verifiably static Schema satisfies one of the essential security properties of ACDCs as discussed below. There are several ACDC supported formats for the value of the top-level id, `$id`, field but all of the formats must include the SAID of the Schema (see below). Correspondingly, the value of the top-level schema, `s`, field must be the SAID included in the schema's top-level `$id` field. The detailed schema is either attached or cached and maybe discovered via its SAIDified, id, `$id`, field value. -The digest algorithm employed for generating [[ref: Schema]] SAIDS shall have an approximate cryptographic strength of 128 bits. The [[ref: SAID]] MUST be generated in compliance with the ToIP SAID internet draft specification and MUST be encoded using CESR. The CESR encoding indicates the type of cryptographic digest used to generate the SAID. +The digest algorithm employed for generating [[ref: Schema]] SAIDS shall have an approximate cryptographic strength of 128 bits. The [[3]] MUST be generated in compliance with the ToIP SAID internet draft specification and MUST be encoded using CESR. The CESR encoding indicates the type of cryptographic digest used to generate the SAID. -When an id, '$id', field appears in a subschema, it indicates a bundled subschema called a schema resource [[ref: JSchId]] [[ref: JSchCx]]. The value of the id, '$id', field in any ACDC bundled subschema resource must include the SAID of that subschema using one of the formats described below. The subschema so bundled must be verifiable against its referenced and embedded SAID value. This ensures secure bundling. +When an id, '$id', field appears in a subschema, it indicates a bundled subschema called a schema resource [[41]] [[42]]. The value of the id, '$id', field in any ACDC bundled subschema resource must include the SAID of that subschema using one of the formats described below. The subschema so bundled must be verifiable against its referenced and embedded SAID value. This ensures secure bundling. #### Static (immutable) schema @@ -656,15 +656,15 @@ For security reasons, the full Schema of an ACDC must be completely self-contain Should an adversary successfully attack the source that provides the dynamic Schema resource and change the result provided by that reference, then the Schema validation on any ACDC that uses that dynamic Schema reference may fail. Such an attack effectively revokes all the ACDCs that use that dynamic Schema reference, which is called a Schema revocation attack. -More insidiously, an attacker could shift the semantics of the dynamic Schema in such a way that although the ACDC still passes its Schema validation, the behavior of the downstream processing of that ACDC is changed by the semantic shift. This type of attack is called a semantic malleability attack which may be considered a new type of transaction malleability attack [[ref: TMal]]. +More insidiously, an attacker could shift the semantics of the dynamic Schema in such a way that although the ACDC still passes its Schema validation, the behavior of the downstream processing of that ACDC is changed by the semantic shift. This type of attack is called a semantic malleability attack which may be considered a new type of transaction malleability attack [[55]]. To prevent both forms of attack, all Schema must be static, i.e., Schema must be SADs and therefore verifiable against their SAIDs. To elaborate, the serialization of a static schema may be self-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 a verifiable cryptographic identifier for its SAD. Therefore, all ACDC compliant Schema must be SADs. In other words, the Schema must therefore be SAIDified. The associated detailed static Schema (uncompacted SAD) is bound cryptographically and verifiable to its SAID. -The JSON Schema specification allows complex Schema references that may include non-local URI references [[ref: JSchId]] [[ref: JSchCx]] [[ref: RFC3986]] [[ref: RFC8820]]. These references may use the `$id` or `$ref` keywords. A relative URI reference provided by a `$ref` keyword is resolved against the Base URI provided by the top-level `$id` field. When this top-level Base URI is non-local, then all relative `$ref` references are therefore also non-local. A non-local URI reference provided by a `$ref` keyword may be resolved without reference to the Base URI. +The JSON Schema specification allows complex Schema references that may include non-local URI references [[41]] [[42]] [[15]] [[16]]. These references may use the `$id` or `$ref` keywords. A relative URI reference provided by a `$ref` keyword is resolved against the Base URI provided by the top-level `$id` field. When this top-level Base URI is non-local, then all relative `$ref` references are therefore also non-local. A non-local 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 `$ref`) must not be used because they are not cryptographically end-verifiable. The value of the underlying Schema resource so referenced may change (mutate). To restate, a non-local URI Schema resource is not end-verifiable to its URI reference because there is no cryptographic binding between URI and resource [[ref: RFC3986]] [[ref: RFC8820]]. +In general, Schema indicated by non-local URI references (`$id` or `$ref`) must not be used because they are not cryptographically end-verifiable. The value of the underlying Schema resource so referenced may change (mutate). To restate, a non-local URI Schema resource is not end-verifiable to its URI reference because there is no cryptographic binding between URI and resource [[15]] [[16]]. This does not preclude the use of remotely cached SAIDified Schema resources because those resources are end-verifiable to their embedded SAID references. Said another way, a SAIDified Schema resource is itself a SAD referenced by its SAID. A URI that includes a SAID may be used to securely reference a remote or distributed SAIDified schema resource because that resource is fixed (immutable, nonmalleable) and verifiable to both the SAID in the reference and the embedded SAID in the resource so referenced. To elaborate, a non-local URI reference that includes an embedded cryptographic commitment such as a SAID is verifiable to the underlying resource when that resource is a SAD. This applies to JSON Schema as a whole as well as bundled subschema resources. @@ -674,17 +674,17 @@ Bare SAIDs may be used to refer to a SAIDified Schema as long as the JSON Schema - The `sad:` URI scheme may be used to directly indicate a URI resource that safely returns a verifiable SAD. For example, `sad:SAID` where SAID is replaced with the actual SAID of a SAD that provides a verifiable non-local reference to JSON Schema as indicated by the media-type of `schema+json`. -- The KERI OOBI specification provides a URL syntax that references a SAD resource by its SAID at the service endpoint indicated by that URL [[ref: OOBI]]. Such remote OOBI URLs are also safe because the provided SAD resource is verifiable against the SAID in the OOBI URL. Therefore, OOBI URLs are also acceptable non-local URI references for JSON Schema [[ref: OOBI]] [[ref: RFC3986]] [[ref: RFC8820]]. +- The KERI OOBI specification provides a URL syntax that references a SAD resource by its SAID at the service endpoint indicated by that URL [[4]]. Such remote OOBI URLs are also safe because the provided SAD resource is verifiable against the SAID in the OOBI URL. Therefore, OOBI URLs are also acceptable non-local URI references for JSON Schema [[4]] [[15]] [[16]]. -- The `did:` URI scheme may be used safely to prefix non-local URI references that act to namespace SAIDs expressed as DID URIs or DID URLs. DID resolvers resolve DID URLs for a given DID method such as `did:keri` [[ref: DIDK_ID]] and may return DID docs or DID doc metadata with SAIDified schema or service endpoints that return SAIDified schema or OOBIs that return SAIDified schema [[ref: RFC3986]] [[ref: RFC8820]] [[ref: OOBI]]. A verifiable non-local reference in the form of DID URL that includes the schema SAID is resolved safely when it dereferences to the SAD of that SAID. For example, the resolution result returns an ACDC JSON Schema whose id, `$id`, field includes the SAID and returns a resource with JSON Schema mime-type of `schema+json`. +- The `did:` URI scheme may be used safely to prefix non-local URI references that act to namespace SAIDs expressed as DID URIs or DID URLs. DID resolvers resolve DID URLs for a given DID method such as `did:keri` [[5]] and may return DID docs or DID doc metadata with SAIDified schema or service endpoints that return SAIDified schema or OOBIs that return SAIDified schema [[15]] [[16]] [[4]]. A verifiable non-local reference in the form of DID URL that includes the schema SAID is resolved safely when it dereferences to the SAD of that SAID. For example, the resolution result returns an ACDC JSON Schema whose id, `$id`, 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 allow dynamically generated Schema resources to be obtained from online JSON Schema Libraries [[ref: JSchId]] [[ref: JSchCx]]. The latter approach may be difficult or impossible to secure because a cryptographic commitment to the base Schema that includes complex Schema (non-relative URI-based) references only commits to the non-relative URI reference and not to the actual schema resource which may change (is dynamic, mutable, malleable). To restate, this approach is insecure because a cryptographic commitment to a complex (non-relative URI-based) reference is not equivalent to a commitment to the detailed associated Schema resource so referenced if it may change. +To clarify, ACDCs must not use complex JSON Schema references which allow dynamically generated Schema resources to be obtained from online JSON Schema Libraries [[41]] [[42]]. The latter approach may be difficult or impossible to secure because a cryptographic commitment to the base Schema that includes complex Schema (non-relative URI-based) references only commits to the non-relative URI reference and not to the actual schema resource which may change (is dynamic, mutable, malleable). To restate, this approach is insecure because a cryptographic commitment to a complex (non-relative URI-based) reference is not equivalent to a commitment to the detailed associated Schema resource so referenced if it may change. -ACDCs must use static JSON Schema (i.e., SAIDifiable Schema). These may include internal relative references to other parts of a fully self-contained static (SAIDified) Schema or references to static (SAIDified) external Schema parts. As indicated above, these references may be bare SAIDs, DID URIs or URLs (`did:` scheme), SAD URIs (`sad:` scheme), or OOBI URLs [[ref: OOBI]]. Recall that a commitment to a SAID with sufficient collision resistance makes an equivalent secure commitment to its encapsulating block SAD. Thus, static schema may be either fully self-contained or distributed in parts but the value of any reference to a part must be verifiably static (immutable, nonmalleable) by virtue of either being relative to the self-contained whole or being referenced by its SAID. The static schema in whole or in parts may be attached to the ACDC itself or provided via a highly available cache or data store. To restate, this approach is securely end-verifiable (zero-trust) because a cryptographic commitment to the SAID of a SAIDified schema is equivalent to a commitment to the detailed associated schema itself (SAD). +ACDCs must use static JSON Schema (i.e., SAIDifiable Schema). These may include internal relative references to other parts of a fully self-contained static (SAIDified) Schema or references to static (SAIDified) external Schema parts. As indicated above, these references may be bare SAIDs, DID URIs or URLs (`did:` scheme), SAD URIs (`sad:` scheme), or OOBI URLs [[4]]. Recall that a commitment to a SAID with sufficient collision resistance makes an equivalent secure commitment to its encapsulating block SAD. Thus, static schema may be either fully self-contained or distributed in parts but the value of any reference to a part must be verifiably static (immutable, nonmalleable) by virtue of either being relative to the self-contained whole or being referenced by its SAID. The static schema in whole or in parts may be attached to the ACDC itself or provided via a highly available cache or data store. To restate, this approach is securely end-verifiable (zero-trust) because a cryptographic commitment to the SAID of a SAIDified schema is equivalent to a commitment to the detailed associated schema itself (SAD). #### Schema dialect -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/schema"` [[ref: JSch]] [[ref: JSch_202012]]. This is indicated in a JSON Schema via the value of the top-level `$schema` field. Although the value of `$schema` is expressed as a URI, de-referencing does not provide dynamically downloadable schema dialect validation code. This would be an attack vector. The Validator must control the tooling code dialect used for Schema validation and hence the tooling dialect version actually used. A mismatch between the supported tooling code dialect version and the `$schema` string value should cause the validation to fail. The string is simply an identifier that communicates the intended dialect to be processed by the Schema validation tool. When provided, the top-level `$schema` field value for ACDC version 1.0 must be "https://json-schema.org/draft/2020-12/schema". +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/schema"` [[10]] [[11]]. This is indicated in a JSON Schema via the value of the top-level `$schema` field. Although the value of `$schema` is expressed as a URI, de-referencing does not provide dynamically downloadable schema dialect validation code. This would be an attack vector. The Validator must control the tooling code dialect used for Schema validation and hence the tooling dialect version actually used. A mismatch between the supported tooling code dialect version and the `$schema` string value should cause the validation to fail. The string is simply an identifier that communicates the intended dialect to be processed by the Schema validation tool. When provided, the top-level `$schema` field value for ACDC version 1.0 must be "https://json-schema.org/draft/2020-12/schema". #### Schema versioning @@ -704,7 +704,7 @@ The composed detailed (uncompacted) (bundled) static Schema for an ACDC may be c #### Composable JSON Schema -A composable JSON Schema enables the use of any combination of compacted/uncompacted Attribute, Edge, and Rule sections in a provided ACDC. When compact, any one of these sections may be represented merely by its SAID [[ref: JSch]] [[ref: JSchCp]]. When used for the top-level attribute, `a`, edge, `e`, or rule, `r`, section field values, the `oneOf` subschema composition operator provides both compact and uncompacted variants. The provided ACDC must validate against an allowed combination of the composed variants. The Validator determines what decomposed variants the provided ACDC must also validate against. Decomposed variants may be dependent on the type of Graduated Disclosure. Essentially, a composable schema is a verifiable bundle of metadata (composed) about content that can then 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 disclosure variants allowed by the composition. +A composable JSON Schema enables the use of any combination of compacted/uncompacted Attribute, Edge, and Rule sections in a provided ACDC. When compact, any one of these sections may be represented merely by its SAID [[10]] [[39]]. When used for the top-level attribute, `a`, edge, `e`, or rule, `r`, section field values, the `oneOf` subschema composition operator provides both compact and uncompacted variants. The provided ACDC must validate against an allowed combination of the composed variants. The Validator determines what decomposed variants the provided ACDC must also validate against. Decomposed variants may be dependent on the type of Graduated Disclosure. Essentially, a composable schema is a verifiable bundle of metadata (composed) about content that can then 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 disclosure variants allowed by the composition. Unlike the other compactifiable sections, it is impossible to define recursively the exact detailed schema as a variant of a `oneOf` composition operator contained in itself. Nonetheless, the provided schema, whether self-contained, attached, or cached must validate as a SAD against its provided SAID. It also must validate against one of its specified `oneOf` variants. Typically, it's SAID or a generic object. @@ -714,9 +714,9 @@ ACDC-specific Schema compliance requirements usually are specified in the EGF fo To elaborate, a Validator can confirm compliance of any non-schema section of the ACDC against its Schema both before and after uncompacted disclosure of that section by using a composed base Schema with `oneOf` pre-disclosure and a decomposed Schema post-disclosure with the compact `oneOf` option removed. This capability provides a mechanism for secure Schema validation of both Compact and uncompacted variants that require the Issuer to only commit to the composed Schema and not to all the different Schema variants for each combination of a given compact/uncompacted section in an ACDC. -One of the most important features of ACDCs is support for Chain-Link Confidentiality [[ref: CLC]]. This provides a powerful mechanism for protecting against unpermissioned exploitation of the data disclosed via an ACDC. Essentially, an exchange of information compatible with Chain-Link Confidentiality starts with an offer by the Discloser to disclose confidential information to a potential Disclosee. This offer includes sufficient metadata about the information to be disclosed such that the Disclosee can agree to those terms. Specifically, the metadata includes both the schema of the information to be disclosed and the terms of use of that data once disclosed. Once the Disclosee has accepted the terms, then Full disclosure is made. A Full Disclosure that happens after contractual acceptance of the terms of use is called permissioned disclosure. The pre-acceptance disclosure of metadata is a form of Partial Disclosure. +One of the most important features of ACDCs is support for Chain-Link Confidentiality [[44]. This provides a powerful mechanism for protecting against unpermissioned exploitation of the data disclosed via an ACDC. Essentially, an exchange of information compatible with Chain-Link Confidentiality starts with an offer by the Discloser to disclose confidential information to a potential Disclosee. This offer includes sufficient metadata about the information to be disclosed such that the Disclosee can agree to those terms. Specifically, the metadata includes both the schema of the information to be disclosed and the terms of use of that data once disclosed. Once the Disclosee has accepted the terms, then Full disclosure is made. A Full Disclosure that happens after contractual acceptance of the terms of use is called permissioned disclosure. The pre-acceptance disclosure of metadata is a form of Partial Disclosure. -As is the case for Compact (uncompacted) ACDC disclosure, composable JSON Schema enables the use of the same base Schema for both the validation of the Partial disclosure of the offer metadata prior to contract acceptance and validation of full or detailed disclosure after contract acceptance [[ref: JSch]][[ref: JSchCp]]. A cryptographic commitment to the base schema securely specifies the allowable semantics for both Partial and Full Disclosure. Decomposition of the base Schema enables a Validator to impose more specific semantics at later stages of the exchange process. Specifically, the `oneOf` subschema composition operator validates against either the compact SAID of a block or the full block. Decomposing the schema to remove the optional Compact variant enables a Validator to ensure complaint Full Disclosure. To clarify, a Validator can confirm Schema compliance both before and after detailed disclosure by using a composed base Schema pre-disclosure and a decomposed schema post-disclosure with the undisclosed options removed. These features provide a mechanism for secure schema-validated contractually-bound Partial (and/or Selective) Disclosure of confidential data via ACDCs. +As is the case for Compact (uncompacted) ACDC disclosure, composable JSON Schema enables the use of the same base Schema for both the validation of the Partial disclosure of the offer metadata prior to contract acceptance and validation of full or detailed disclosure after contract acceptance [[10]][[39]]. A cryptographic commitment to the base schema securely specifies the allowable semantics for both Partial and Full Disclosure. Decomposition of the base Schema enables a Validator to impose more specific semantics at later stages of the exchange process. Specifically, the `oneOf` subschema composition operator validates against either the compact SAID of a block or the full block. Decomposing the schema to remove the optional Compact variant enables a Validator to ensure complaint Full Disclosure. To clarify, a Validator can confirm Schema compliance both before and after detailed disclosure by using a composed base Schema pre-disclosure and a decomposed schema post-disclosure with the undisclosed options removed. These features provide a mechanism for secure schema-validated contractually-bound Partial (and/or Selective) Disclosure of confidential data via ACDCs. ### Attribute section @@ -815,7 +815,7 @@ Consider the case where the Issuee, `i`, field is absent at the top level of the This ACDC has an Issuer but no Issuee. There is no provably controllable AID as a Target of the issuance, i.e., Untargeted. The data in the Attribute section may be considered an undirected verifiable attestation or observation by the Issuer. The attestation is addressed "to whom it may concern." An Untargeted ACDC enables verifiable authorship by the Issuer of the data in the Attributes section, but there is no specified counterparty and no verifiable mechanism for delegation of authority. Consequently, the Rules section may provide only contractual obligations of implied counterparties. -This form of an ACDC provides a container for authentic data only (not authentic data as authorization). But authentic data is still a very important use case. To clarify, an Untargeted ACDC enables verifiable authorship of data. An observer, such as a sensor that controls an AID, may make verifiable, nonrepudiable measurements and publish them as ACDCs. These may be chained together to provide provenance for or a chain-of-custody of any data. Furthermore, a hybrid chain of one or more targeted ACDCs ending in a chain of one or more Untargeted ACDCs enables delegated authorized attestations at the tail of that chain. These provenanceable chains of ACDCs could be used to provide a verifiable data supply chain for any compliance-regulated application. This provides a way to protect participants in a supply chain from imposters. Such data supply chains are also useful as a verifiable digital twin of a physical supply chain [[ref: Twin]]. +This form of an ACDC provides a container for authentic data only (not authentic data as authorization). But authentic data is still a very important use case. To clarify, an Untargeted ACDC enables verifiable authorship of data. An observer, such as a sensor that controls an AID, may make verifiable, nonrepudiable measurements and publish them as ACDCs. These may be chained together to provide provenance for or a chain-of-custody of any data. Furthermore, a hybrid chain of one or more targeted ACDCs ending in a chain of one or more Untargeted ACDCs enables delegated authorized attestations at the tail of that chain. These provenanceable chains of ACDCs could be used to provide a verifiable data supply chain for any compliance-regulated application. This provides a way to protect participants in a supply chain from imposters. Such data supply chains are also useful as a verifiable digital twin of a physical supply chain [[54]]. #### Targeted private-attribute section example @@ -900,11 +900,11 @@ As described above in the Schema section of this specification, the `oneOf` subs As discussed above, the presence of the `i` field at the top level of the Attribute section block makes this a targeted Attribute section. The AID given by the `i` field value is the target entity called the Issuee. The semantics of the Issuee maybe defined by the Credential Frameworks in the EGF. -Given the presence of a top-level UUID, `u`, field of the Attribute block whose value has sufficient cryptographic entropy, then the top-level SAID, `d`, field of the Attribute block provides a secure cryptographic digest of the contents of the Attribute block [[ref: Hash]]. An adversary when given both 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 computationally feasible manner such as a rainbow table attack [[ref: RB]] ] [[ref: DRB]]. Therefore, the attribute block's UUID, `u`, field in a compact ACDC enables its Attribute block's SAID, `d`, field to securely blind the contents of the Attribute block notwithstanding knowledge of the Attribute block's Schema and SAID, `d` field. Moreover, a cryptographic commitment to that Attribute block's, SAID, `d`, field does not provide a fixed point of correlation to the Attribute field values themselves unless and until there has been a disclosure of those field values. +Given the presence of a top-level UUID, `u`, field of the Attribute block whose value has sufficient cryptographic entropy, then the top-level SAID, `d`, field of the Attribute block provides a secure cryptographic digest of the contents of the Attribute block [[48]]. An adversary when given both 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 computationally feasible manner such as a rainbow table attack [[30]] ] [[31]]. Therefore, the attribute block's UUID, `u`, field in a compact ACDC enables its Attribute block's SAID, `d`, field to securely blind the contents of the Attribute block notwithstanding knowledge of the Attribute block's Schema and SAID, `d` field. Moreover, a cryptographic commitment to that Attribute block's, SAID, `d`, field does not provide a fixed point of correlation to the Attribute field values themselves unless and until there has been a disclosure of those field values. To elaborate, when an ACDC includes a sufficiently high entropy UUID, `u`, field at the top level of its Attributes block then the ACDC may be considered a private-attributes ACDC when expressed in compact form, that is, the Attribute block is represented by its SAID, `d`, field and the value of its top-level Attribute section, `a`, field is the value of the nested SAID, `d`, field from the uncompacted version of the Attribute block. A verifiable commitment may be made to the compact form of the ACDC without leaking details of the Attributes. Later disclosure of the uncompacted Attribute block may be verified against its SAID, `d`, field that was provided in the compact form as the value of the top-level Attribute section, `a`, field. -Because the Issuee AID is nested in the attribute block as that block's top-level, Issuee, `i`, field, a presentation exchange (disclosure) could be initiated on behalf of a different AID that has not yet been correlated to the Issuee AID and then only correlated to the Issuee AID after the Disclosee has agreed to the Chain-Link Confidentiality provisions in the rules section of the private-attributes ACDC [[ref: CLC]]. +Because the Issuee AID is nested in the attribute block as that block's top-level, Issuee, `i`, field, a presentation exchange (disclosure) could be initiated on behalf of a different AID that has not yet been correlated to the Issuee AID and then only correlated to the Issuee AID after the Disclosee has agreed to the Chain-Link Confidentiality provisions in the rules section of the private-attributes ACDC [[44]. #### Targeted public-attribute section example @@ -986,7 +986,7 @@ The SAID, `d`, field at the top level of the uncompacted Attribute block is the As discussed above, the presence of the `i` field at the top level of the Attribute section block makes this a targeted Attribute section. The AID given by the `i` field value is the Target or Issuee. The semantics of the issuance may be defined by the Credential Frameworks of the EGF. -Given the absence of a `u` field at the top level of the Attributes block, however, knowledge of both SAID, `d`, field at the top level of an Attributes block and the schema of the Attributes block may enable the discovery of the remaining contents of the attributes block via a rainbow table attack [[ref: RB]] [[ref: DRB]]. Therefore, the SAID, `d`, field of the Attributes block, although a cryptographic digest, does not securely blind the contents of the Attributes block given knowledge of the Schema. It only provides compactness, not privacy. Moreover, any cryptographic commitment to that SAID, `d`, field potentially provides a fixed correlation point to the attribute block field values despite the non-disclosure of those field values via a Compact Attribute section. Thus, an ACDC without a UUID, `u` field in its Attributes block must be considered a Public-Attribute ACDC even when expressed in compact form. +Given the absence of a `u` field at the top level of the Attributes block, however, knowledge of both SAID, `d`, field at the top level of an Attributes block and the schema of the Attributes block may enable the discovery of the remaining contents of the attributes block via a rainbow table attack [[30]] [[31]]. Therefore, the SAID, `d`, field of the Attributes block, although a cryptographic digest, does not securely blind the contents of the Attributes block given knowledge of the Schema. It only provides compactness, not privacy. Moreover, any cryptographic commitment to that SAID, `d`, field potentially provides a fixed correlation point to the attribute block field values despite the non-disclosure of those field values via a Compact Attribute section. Thus, an ACDC without a UUID, `u` field in its Attributes block must be considered a Public-Attribute ACDC even when expressed in compact form. #### Nested partially disclosable Attribute section example @@ -1156,15 +1156,15 @@ Nested Edge-groups may only appear as locally unique labeled blocks nested withi #### ACDCs as secure graph fragments of a globally distributed property graph (PG) -A set of ACDCs as nodes connected by edges forms a labeled property graph (LPG) or property graph (PG) for short [[ref: PGM]] [[ref: Dots]] [[ref: KG]]. Property graphs have properties not only in the nodes but also in the edges. The properties of each node (ACDC) are provided essentially by its Attribute Section. The properties of each edge are provided by the combination of Edge blocks and Edge-group blocks. In this regard, the set of nested Edge-groups within a given top-level Edge Section, i.e., the `e` field block of a given ACDC, constitute a sub-graph of a super-graph of ACDCs where the nodes of the super-graph are ACDCs. The nodes of the sub-graph are the Edge-groups and Edges, not whole ACDCs. One of the attractive features of property graphs (PGs) is their support for different edge and node types, which enables nested sub-graphs that support the rich expression of complex logical or aggregative operations on groups of Edges and/or Edge-groups (as subnodes) within the top-level Edge Section, `e`, field of an ACDC (as supernode). +A set of ACDCs as nodes connected by edges forms a labeled property graph (LPG) or property graph (PG) for short [[56]] [[57]] [[58]]. Property graphs have properties not only in the nodes but also in the edges. The properties of each node (ACDC) are provided essentially by its Attribute Section. The properties of each edge are provided by the combination of Edge blocks and Edge-group blocks. In this regard, the set of nested Edge-groups within a given top-level Edge Section, i.e., the `e` field block of a given ACDC, constitute a sub-graph of a super-graph of ACDCs where the nodes of the super-graph are ACDCs. The nodes of the sub-graph are the Edge-groups and Edges, not whole ACDCs. One of the attractive features of property graphs (PGs) is their support for different edge and node types, which enables nested sub-graphs that support the rich expression of complex logical or aggregative operations on groups of Edges and/or Edge-groups (as subnodes) within the top-level Edge Section, `e`, field of an ACDC (as supernode). To clarify, the Edge Section of an ACDC forms a sub-graph where each Edge block is a leaf of a branch in that sub-graph that terminates at the value of its node, `n`, field. Its node, `n` field, points to some other ACDC that is itself a sub-graph. The head of each sub-graph is the top-level Edge-group, i.e. the Edge Section. Thus, an Edge block is a leaf with respect to the sub-graph formed by any nested Edge-group blocks in which the Edge appears. -Abstractly, an ACDC with one or more edges may be viewed as a fragment of a larger distributed property graph where each ACDC Edge Section is a sub-graph. Each node in this larger graph is universally uniquely identified by the SAID of its ACDC. Recall that a SAID is a cryptographic digest. The local labels on each Edge block or Edge-group block are not universally uniquely resolvable, so they are inappropriate as a verifiable hook for resolving the Edges in a globally distributed property graph. This requires resolving both nodes and Edges. To enable both the node and its connecting edge to be globally uniquely resolvable, each Edge's block must also have a SAID, `d`, field. Recall that a SAID is a cryptographic digest. Therefore, it will universally and uniquely identify an Edge with a given set of properties [[ref: Hash]], including the node it points to. +Abstractly, an ACDC with one or more edges may be viewed as a fragment of a larger distributed property graph where each ACDC Edge Section is a sub-graph. Each node in this larger graph is universally uniquely identified by the SAID of its ACDC. Recall that a SAID is a cryptographic digest. The local labels on each Edge block or Edge-group block are not universally uniquely resolvable, so they are inappropriate as a verifiable hook for resolving the Edges in a globally distributed property graph. This requires resolving both nodes and Edges. To enable both the node and its connecting edge to be globally uniquely resolvable, each Edge's block must also have a SAID, `d`, field. Recall that a SAID is a cryptographic digest. Therefore, it will universally and uniquely identify an Edge with a given set of properties [[48]], including the node it points to. -Thus, a given ACDC with its Edges may be universally uniquely resolvable as a graph fragment of a larger graph. Moreover, because each ACDC with edges, i.e., a graph fragment, may be independently sourced and securely attributed, a distributed property graph can be securely assembled and verified fragment by fragment. To summarize, these features enable ACDCs to be used as securely attributed fragments of a globally distributed property graph (PG). This further enables such a property graph so assembled to serve as a global verifiable knowledge graph that crosses trust domains [[ref: PGM]] [[ref: Dots]] [[ref: KG]]. +Thus, a given ACDC with its Edges may be universally uniquely resolvable as a graph fragment of a larger graph. Moreover, because each ACDC with edges, i.e., a graph fragment, may be independently sourced and securely attributed, a distributed property graph can be securely assembled and verified fragment by fragment. To summarize, these features enable ACDCs to be used as securely attributed fragments of a globally distributed property graph (PG). This further enables such a property graph so assembled to serve as a global verifiable knowledge graph that crosses trust domains [[56]] [[57]] [[58]]. -The universal uniqueness of the ACDC SAIDs (nodes) and their Edge SAIDs enable the simplified discovery of ACDCs via service endpoints. The 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-Introduction) that links the service endpoint URL to the SAID of the ACDC or by the SAID of the Edge that points to the SAID of that ACDC [[ref: OOBI]]. Alternatively, the Issuer may provide as an attachment at the time of issuance a copy of the referenced ACDC. In either case, after a successful exchange, the Issuee of any ACDC will have either a copy or a means of obtaining a copy of any referenced ACDCs as nodes in the edge sections of all referenced ACDCs. That Issuee will then have everything it needs to make a successful disclosure to some other Disclosee. This is the essence of Percolated Discovery [[ref: OOBI]]. +The universal uniqueness of the ACDC SAIDs (nodes) and their Edge SAIDs enable the simplified discovery of ACDCs via service endpoints. The 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-Introduction) that links the service endpoint URL to the SAID of the ACDC or by the SAID of the Edge that points to the SAID of that ACDC [[4]]. Alternatively, the Issuer may provide as an attachment at the time of issuance a copy of the referenced ACDC. In either case, after a successful exchange, the Issuee of any ACDC will have either a copy or a means of obtaining a copy of any referenced ACDCs as nodes in the edge sections of all referenced ACDCs. That Issuee will then have everything it needs to make a successful disclosure to some other Disclosee. This is the essence of Percolated Discovery [[4]]. #### Edge-group @@ -1224,9 +1224,9 @@ Edge-groups and Edges nested within a given Edge-group appear as labeled fields Each nested Edge or Edge-group block within an Edge-group including the top-level Edge Section Edge-group shall be labeled with a locally unique non-reserved field label that indicates the type of the nested block. To clarify, each nested block in every Edge-group gets its own field with its own local (to the ACDC) label. The field's value may be either an Edge sub-block or when in compact form, a string. The compact forms are defined below. -Note that each nested block shall not include a type field. The type of each block is provided by that associated subschema in the Edge Section's subschema with a matching label. This is in accordance with the design principle of ACDCs that may be succinctly expressed as "type-is-schema." This approach varies somewhat from other types of property graphs, which often do not have a Schema [[ref: PGM]] [[ref: Dots]] [[ref: KG]]. Because ACDCs have a Schema, they leverage it to provide property graph edge types with a cleaner separation of concerns. Notwithstanding this separation, an Edge block may include a constraint on the type of the ACDC to which that Edge points by including the SAID of the schema of the pointed-to ACDC as a property of that edge (see below). +Note that each nested block shall not include a type field. The type of each block is provided by that associated subschema in the Edge Section's subschema with a matching label. This is in accordance with the design principle of ACDCs that may be succinctly expressed as "type-is-schema." This approach varies somewhat from other types of property graphs, which often do not have a Schema [[56]] [[57]] [[58]]. Because ACDCs have a Schema, they leverage it to provide property graph edge types with a cleaner separation of concerns. Notwithstanding this separation, an Edge block may include a constraint on the type of the ACDC to which that Edge points by including the SAID of the schema of the pointed-to ACDC as a property of that edge (see below). -A main distinguishing feature of a property graph (PG) is that both nodes and Edges may have a set of properties [[ref: PGM]] [[ref: Dots]] [[ref: KG]]. These might include modifiers that influence how the connected node is to be combined or place a constraint on the allowed type(s) of connected nodes. Each Edge's block provides the Edge's properties vis-a-vis a property graph. Additional properties may be inferred from the properties of an enclosing Edge-group's block. Each labeled Edge and Edge-group type is defined by the subschema designated by its label. +A main distinguishing feature of a property graph (PG) is that both nodes and Edges may have a set of properties [[56]] [[57]] [[58]]. These might include modifiers that influence how the connected node is to be combined or place a constraint on the allowed type(s) of connected nodes. Each Edge's block provides the Edge's properties vis-a-vis a property graph. Additional properties may be inferred from the properties of an enclosing Edge-group's block. Each labeled Edge and Edge-group type is defined by the subschema designated by its label. #### Edge @@ -1256,7 +1256,7 @@ Given that an individual edge's property block includes a SAID, `d`, field, a co ##### UUID, `u` field -The UUID, `u` field is optional, but when it appears, it shall appear as the second field in the Edge block following the SAID, `d`, field. The value of this field shall be a cryptographic strength salty-nonce with approximately 128 bits of entropy. When present, the UUID, `u` field means that the block's SAID, `d` field value provides a secure cryptographic digest of the contents of the block [[ref: Hash]]. An adversary, when given both the block's subschema and its SAID, cannot discover the remaining contents of the block in a computationally feasible manner, such as a rainbow table attack [[ref: RB]] [[ref: DRB]]. Therefore, the block's UUID, `u` field securely blinds the contents of the block via its SAID, `d` field notwithstanding knowledge of both the block's subschema and SAID. Moreover, a cryptographic commitment to that block's SAID, `d` field does not provide a fixed point of correlation to the block's field values themselves unless and until there has been a disclosure of those field values. +The UUID, `u` field is optional, but when it appears, it shall appear as the second field in the Edge block following the SAID, `d`, field. The value of this field shall be a cryptographic strength salty-nonce with approximately 128 bits of entropy. When present, the UUID, `u` field means that the block's SAID, `d` field value provides a secure cryptographic digest of the contents of the block [[48]]. An adversary, when given both the block's subschema and its SAID, cannot discover the remaining contents of the block in a computationally feasible manner, such as a rainbow table attack [[30]] [[31]]. Therefore, the block's UUID, `u` field securely blinds the contents of the block via its SAID, `d` field notwithstanding knowledge of both the block's subschema and SAID. Moreover, a cryptographic commitment to that block's SAID, `d` field does not provide a fixed point of correlation to the block's field values themselves unless and until there has been a disclosure of those field values. The absence of the UUID, `u` field in an Edge block makes that edge a Public Edge. The presence of the UUID, `u` field in an Edge block makes that Edge a Private Edge. A Private Edge in compact form, i.e., a Compact Private Edge, enables a presenter of that ACDC to make a verifiable commitment to the ACDC attached to the Edge without disclosing any details of that ACDC, including the ACDC's SAID. Private ACDCs (nodes) and Private Edges may be combined to better protect the privacy of the information in a distributed property graph. @@ -2031,7 +2031,7 @@ As the examples above have shown, the Edge Section syntax enables the composable ### Rule Section -The purpose of the Rules section is to provide a set of rules or conditions as a Ricardian Contract [[ref: RC]]. The important features of a Ricardian contract are that it be both human and machine-readable and referenceable by a cryptographic digest. A JSON-encoded document or block, such as the Rules section block, is a practical example of both a human and machine-readable document. The Rules section's top-level SAID, `d` field provides the digest. This provision supports the bow-tie model of RC. +The purpose of the Rules section is to provide a set of rules or conditions as a Ricardian Contract [[43]. The important features of a Ricardian contract are that it be both human and machine-readable and referenceable by a cryptographic digest. A JSON-encoded document or block, such as the Rules section block, is a practical example of both a human and machine-readable document. The Rules section's top-level SAID, `d` field provides the digest. This provision supports the bow-tie model of RC. The Rules Section includes labeled nested blocks called Rules that provide the legal language (terms , conditions, definitions etc). The labeled clauses can be structured hierarchically, where each Rule, in turn, can include nested labeled Rules. The labels on the Rules may follow a structured naming or numbering convention. These provisions enable the Rules section to satisfy the features of an RC. @@ -2075,9 +2075,9 @@ Rules and Rule-group nested within a Rule-group appear as labeled fields whose l To elaborate, each nested Rule or Rule-group block shall be labeled with a locally unique non-reserved field label that indicates the type of the nested block. To clarify, each nested block gets its own field with its own local (to the ACDC Rule Section) label. The field's value may be either the Rule or Rule-group block or, in compact form, a string. The compact forms are defined below. -Note that each nested block shall not include a type field. The type of each block is provided by that associated nested subschema with a matching label. This is in accordance with the design principle of ACDCs that may be succinctly expressed as "type-is-schema." This approach varies somewhat from other types of property graphs, which often do not have a Schema [[ref: PGM]][[ref: Dots]][[ref: KG]]. Because ACDCs have a Schema, they leverage it to provide property graph types with a cleaner separation of concerns. +Note that each nested block shall not include a type field. The type of each block is provided by that associated nested subschema with a matching label. This is in accordance with the design principle of ACDCs that may be succinctly expressed as "type-is-schema." This approach varies somewhat from other types of property graphs, which often do not have a Schema [[56]][[57]][[58]]. Because ACDCs have a Schema, they leverage it to provide property graph types with a cleaner separation of concerns. -A main distinguishing feature of a property graph (PG) is that both nodes and Edges may have a set of properties [[ref: PGM]][[ref: Dots]][[ref: KG]]. Each Rule-group's block provides its additional properties vis-a-vis a property graph as labeled fields. Additional properties may be inferred from the properties of an enclosing Rule-group block. Each labeled Rule type is defined by the subschema designated by its label. +A main distinguishing feature of a property graph (PG) is that both nodes and Edges may have a set of properties [[56]][[57]][[58]]. Each Rule-group's block provides its additional properties vis-a-vis a property graph as labeled fields. Additional properties may be inferred from the properties of an enclosing Rule-group block. Each labeled Rule type is defined by the subschema designated by its label. #### Rule @@ -2103,7 +2103,7 @@ Given that an individual Rule block includes a SAID, `d` field, a compact repres ##### UUID, `u` field -The UUID, `u` field is optional, but when it appears, it shall appear as the second field in the Rule Section block following the SAID, `d` field. The value of this field shall be a cryptographic strength salty-nonce with approximately 128 bits of entropy. When present, the UUID, `u` field means that the block's SAID, `d` field value provides a secure cryptographic digest of the contents of the block [[ref: Hash]]. An adversary, when given both the block's subschema and its SAID, cannot discover the remaining contents of the block in a computationally feasible manner, such as a rainbow table attack [[ref: RB]] [[ref: DRB]]. Therefore, the block's UUID, `u` field securely blinds the contents of the block via its SAID, `d` field notwithstanding knowledge of both the block's subschema and SAID. Moreover, a cryptographic commitment to that block's SAID, `d` field does not provide a fixed point of correlation to the block's field values themselves unless and until there has been a disclosure of those field values. +The UUID, `u` field is optional, but when it appears, it shall appear as the second field in the Rule Section block following the SAID, `d` field. The value of this field shall be a cryptographic strength salty-nonce with approximately 128 bits of entropy. When present, the UUID, `u` field means that the block's SAID, `d` field value provides a secure cryptographic digest of the contents of the block [[48]]. An adversary, when given both the block's subschema and its SAID, cannot discover the remaining contents of the block in a computationally feasible manner, such as a rainbow table attack [[30]] [[31]]. Therefore, the block's UUID, `u` field securely blinds the contents of the block via its SAID, `d` field notwithstanding knowledge of both the block's subschema and SAID. Moreover, a cryptographic commitment to that block's SAID, `d` field does not provide a fixed point of correlation to the block's field values themselves unless and until there has been a disclosure of those field values. ##### Legal, `l` field @@ -2118,7 +2118,7 @@ When a Rule block has only one field, that is, its legal, `l` field, i.e., it ha ##### Private rules -Some Rules and Rule-groups, as opposed to the Rule Section as a whole, may benefit from confidential disclosure. Recall that individual Rule and Rule-group blocks may have their own SAID, `d`, field and UUID, `u,` field. To clarify, a Rule or Rule-group block with both a SAID, `d`, and UUID, `u` fields, where that UUID has sufficiently high entropy, protects the compact form of that block from discovery via a rainbow table attack merely from its SAID and subschema [[ref: RB]] [[ref: DRB]]. Therefore, such a Rule or Rule-group may kept hidden until later disclosure. These are called private Rules or Rule-groups. The following example has an independently hidable Rule-group and Rules. +Some Rules and Rule-groups, as opposed to the Rule Section as a whole, may benefit from confidential disclosure. Recall that individual Rule and Rule-group blocks may have their own SAID, `d`, field and UUID, `u,` field. To clarify, a Rule or Rule-group block with both a SAID, `d`, and UUID, `u` fields, where that UUID has sufficiently high entropy, protects the compact form of that block from discovery via a rainbow table attack merely from its SAID and subschema [[30]] [[31]]. Therefore, such a Rule or Rule-group may kept hidden until later disclosure. These are called private Rules or Rule-groups. The following example has an independently hidable Rule-group and Rules. Issued by Amy: @@ -2620,7 +2620,7 @@ This model is diagrammed below. ### Least disclosure ACDCs provide several mechanisms designed to help protect against the exploitation of disclosed data. These are based on the principle of least disclosure as follows: -The system should disclose only the minimum amount of information about a given party needed to facilitate a transaction and no more. [[ref: IDSys]] +The system should disclose only the minimum amount of information about a given party needed to facilitate a transaction and no more. [[47]] ### Graduated Disclosure @@ -2667,7 +2667,7 @@ Graduated Disclosure enables a comprehensive protection mechanism called Contrac 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. The process by which such least disclosures progress to full disclosure is described in the IPEX (Issuance and Exchange Protocol) section below. -One special case of a Contractually protected disclosure is a Chain-Link Confidential disclosure [[ref: CLC]]. Chain-Link Confidentiality imposes conditions and limitations on the further disclosure and/or use of the disclosed data. These may be specific terms of use or other consensual constraints. These terms may be applied to subsequent disclosures by the Disclosee that follow the data (hence chain-link). Another way of viewing Chain-link confidential disclosure is that the disclosed data has "strings attached." The chaining, in this case, is different from the chaining of ACDCs via their edges, i.e., a DAG of ACDCs. Chain-link confidentiality, in contrast, chains together a sequence of Disclosees. Each Disclosee in the sequence, in turn, is the Discloser to the next Disclosee. The terms-of-use of the original disclosure as applied to the original Disclosee shall be applied by each subsequent Discloser to each subsequent Disclosee via each of the subsequent disclosures. These terms of use are meant to contractually protect the data rights of the original Issuer or Issuee of the data being disclosed. These terms of use typically constrain disclosure to only approved parties, i.e., imbue the chain of disclosures with some degree of confidentiality. +One special case of a Contractually protected disclosure is a Chain-Link Confidential disclosure [[44]. Chain-Link Confidentiality imposes conditions and limitations on the further disclosure and/or use of the disclosed data. These may be specific terms of use or other consensual constraints. These terms may be applied to subsequent disclosures by the Disclosee that follow the data (hence chain-link). Another way of viewing Chain-link confidential disclosure is that the disclosed data has "strings attached." The chaining, in this case, is different from the chaining of ACDCs via their edges, i.e., a DAG of ACDCs. Chain-link confidentiality, in contrast, chains together a sequence of Disclosees. Each Disclosee in the sequence, in turn, is the Discloser to the next Disclosee. The terms-of-use of the original disclosure as applied to the original Disclosee shall be applied by each subsequent Discloser to each subsequent Disclosee via each of the subsequent disclosures. These terms of use are meant to contractually protect the data rights of the original Issuer or Issuee of the data being disclosed. These terms of use typically constrain disclosure to only approved parties, i.e., imbue the chain of disclosures with some degree of confidentiality. Another special case of Contractually Protected Disclosure is Contingent Disclosure. In a Contingent Disclosure, some contingency is specified in the Rules 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 contract term. 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, 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 commitment, 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 Full Disclosure of PII is latent in the Contingent Disclosure but never realized (actualized) until the conditions of the contingency is satisfied. This minimizes inadvertent leakage while protecting both the Discloser and the Disclosee. @@ -2681,7 +2681,7 @@ The difference between exchange types is the information disclosed, not the mech The second is convenience. A standard, simple protocol is easier to implement, support, update, understand, and adopt. The tooling is more consistent. -This IPEX [[ref: IPEX]] protocol leverages important features of ACDCs and ancillary protocols such as CESR [[ref: CESR]], SAIDs [[ref: SAID]], and CESR-Path proofs [[ref: Proof-ID]] as well as Ricardian Contracts [[ref: RC]] and Graduated Disclosure (Metadata, Partial, Selective, Full) to enable Contractually Protected Disclosure. Contractually Protected Disclosure includes both Chain-Link Confidential [[ref: CLC]] and Contingent Disclosure [[ref: ACDC]]. +This IPEX [[ref: IPEX]] protocol leverages important features of ACDCs and ancillary protocols such as CESR [[1]], SAIDs [[3]], and CESR-Path proofs [[ref: Proof-ID]] as well as Ricardian Contracts [[43] and Graduated Disclosure (Metadata, Partial, Selective, Full) to enable Contractually Protected Disclosure. Contractually Protected Disclosure includes both Chain-Link Confidential [[44] and Contingent Disclosure [[ref: ACDC]]. ### Exchange Protocol @@ -2738,11 +2738,11 @@ Thus, for any disclosed variant of an ACDC, the Disclosee need only verify one P ### Disclosure-specific (bespoke) issued ACDCs -Chaining two or more ACDCs via edges enables disclosure-specific issuance of bespoke issued 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. A given Discloser issues its own bespoke ACDC referencing some other ACDC via an Edge. 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-SAD-Path proof references that are relative to the node SAID in the Edge [[ref: RFC6901]] [[ref: Proof_ID]]. +Chaining two or more ACDCs via edges enables disclosure-specific issuance of bespoke issued 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. A given Discloser issues its own bespoke ACDC referencing some other ACDC via an Edge. 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-SAD-Path proof references that are relative to the node SAID in the Edge [[6]] [[ref: 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 Rulea section of the bespoke ACDC that references the Issuee of that ACDC as a named party. Signing the agreement to the offer of that bespoke ACDC consummates a contract between the named Issuer and the 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 [[ref: Abuse]]. +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 [[59]]. #### Example of a bespoke issued ACDC @@ -2898,7 +2898,7 @@ The Message type, `t` field value shall be one of the Message types in the tabl The SAID, `d` field value shall be the SAID of its enclosing block. A transaction event's SAID enables a verifiable globally unique reference to that event. ##### UUID, `u` field -The UUID, `u` field value shall be a cryptographic strength salty nonce with approximately 128 bits of entropy. The UUID, `u` field means that the block's SAID, `d` field value provides a secure cryptographic digest of the contents of the block [[ref: Hash]]. An adversary, when given both the block's SAID and knowledge of all possible state values, cannot discover the actual state in a computationally feasible manner, such as a rainbow table attack [[ref: RB]] [[ref: DRB]]. Therefore, the block's UUID, `u` field securely blinds the contents of the block via its SAID, `d` field notwithstanding knowledge of both the block's structure, possible state values, and SAID. Moreover, a cryptographic commitment to that block's SAID, `d` field does not provide a fixed point of correlation to the block's state unless and until there has been a disclosure of that state. +The UUID, `u` field value shall be a cryptographic strength salty nonce with approximately 128 bits of entropy. The UUID, `u` field means that the block's SAID, `d` field value provides a secure cryptographic digest of the contents of the block [[48]]. An adversary, when given both the block's SAID and knowledge of all possible state values, cannot discover the actual state in a computationally feasible manner, such as a rainbow table attack [[30]] [[31]]. Therefore, the block's UUID, `u` field securely blinds the contents of the block via its SAID, `d` field notwithstanding knowledge of both the block's structure, possible state values, and SAID. Moreover, a cryptographic commitment to that block's SAID, `d` field does not provide a fixed point of correlation to the block's state unless and until there has been a disclosure of that state. ##### Issuer, `i` field @@ -2944,7 +2944,7 @@ The SAID, `d` field value shall be the SAID of its enclosing block. An Attribute ##### UUID, `u` field -The UUID, `u` field value shall be a cryptographic strength salty nonce with approximately 128 bits of entropy. The UUID, `u` field means that the block's SAID, `d` field value provides a secure cryptographic digest of the contents of the block [[ref: Hash]]. An adversary, when given both the block's SAID and knowledge of all possible state values, cannot discover the actual state in a computationally feasible manner, such as a rainbow table attack [[ref: RB]] [[ref: DRB]]. Therefore, the block's UUID, `u` field securely blinds the contents of the block via its SAID, `d` field notwithstanding knowledge of both the block's structure, possible state values, and SAID. Moreover, a cryptographic commitment to that block's SAID, `d` field does not provide a fixed point of correlation to the block's state unless and until there has been a disclosure of that state. +The UUID, `u` field value shall be a cryptographic strength salty nonce with approximately 128 bits of entropy. The UUID, `u` field means that the block's SAID, `d` field value provides a secure cryptographic digest of the contents of the block [[48]]. An adversary, when given both the block's SAID and knowledge of all possible state values, cannot discover the actual state in a computationally feasible manner, such as a rainbow table attack [[30]] [[31]]. Therefore, the block's UUID, `u` field securely blinds the contents of the block via its SAID, `d` field notwithstanding knowledge of both the block's structure, possible state values, and SAID. Moreover, a cryptographic commitment to that block's SAID, `d` field does not provide a fixed point of correlation to the block's state unless and until there has been a disclosure of that state. When the UUID, `u`, is derived from a shared secret salt and a public path such as the sequence number using a hierarchically deterministic derivation algorithm and given that the possible state values are finite small, then any holder of the shared secret can derive the state given the public information in the top-level fields of the transaction event. @@ -3217,7 +3217,7 @@ There are about 3600 * 24 * 365 = 313,536,000 = 2log23135360000 + a1 + a2). -Given sufficient collision resistance of the digest Operator, the digest of an ordered concatenation is not subject to a birthday attack on its concatenated elements [[ref: BDC][[ref: BDay][[ref: QCHC][[ref: HCR][[ref: Hash]]. +Given sufficient collision resistance of the digest Operator, the digest of an ordered concatenation is not subject to a birthday attack on its concatenated elements [[ref: BDC][[ref: BDay][[ref: QCHC][[ref: HCR][[48]]. In compact form, the value of the selectively disclosable top-level Attribute section, `A`, field is set to the aggregated value ‘A’. This aggregate ‘A’ makes a blinded cryptographic commitment to the all the ordered elements in the list, @@ -3489,21 +3489,21 @@ verifying the provided signature(s) of the Issuee on the provided top-level SAID The last 3 steps that culminate with verifying the signature(s) require determining the Key state of the Issuer at the time of issuance. Therefore, this may require additional verification steps as per the KERI and SAD Path protocols. -A private selectively disclosable ACDC provides significant correlation minimization because a Discloser may use a metadata ACDC prior to acceptance by the Disclosee of the terms of the Chain Link Confidentiality expressed in the Rule section [[ref: CLC]]. Thus, only malicious Disclosees who violate Chain Lnk Confidentiality may correlate between presentations of a given private selectively disclosable ACDC. Nonetheless, the malicious Disclosees are not able to discover any undisclosed Attributes. +A private selectively disclosable ACDC provides significant correlation minimization because a Discloser may use a metadata ACDC prior to acceptance by the Disclosee of the terms of the Chain Link Confidentiality expressed in the Rule section [[44]. Thus, only malicious Disclosees who violate Chain Lnk Confidentiality may correlate between presentations of a given private selectively disclosable ACDC. Nonetheless, the malicious Disclosees are not able to discover any undisclosed Attributes. #### Inclusion proof via Merkle tree root digest -The inclusion proof via aggregated list may be somewhat verbose when there are a large number of attribute blocks in the selectively disclosable Attribute section. A more efficient approach is to create a Merkle tree of the attribute block digests and let the aggregate, ‘A’, be the Merkle tree root digest [[ref: Mrkl]]. Specifically, set the value of the top-level selectively disclosable attribute section, `A`, field to the aggregate, ‘A’ whose value is the Merkle tree root digest [[ref: Mrkl]]. +The inclusion proof via aggregated list may be somewhat verbose when there are a large number of attribute blocks in the selectively disclosable Attribute section. A more efficient approach is to create a Merkle tree of the attribute block digests and let the aggregate, ‘A’, be the Merkle tree root digest [[49]]. Specifically, set the value of the top-level selectively disclosable attribute section, `A`, field to the aggregate, ‘A’ whose value is the Merkle tree root digest [[49]]. -The Merkle tree needs to have appropriate second-pre-image attack protection of interior branch nodes [[ref: TwoPI]] [[ref: MTSec]]. The Discloser then only needs to provide a subset of digests from the Merkle tree to prove that a given digest, aj contributed to the Merkle tree root digest, ‘A. For ACDCs with a small number of attributes, the added complexity of the Merkle tree approach may not be worth the savings in verbosity. +The Merkle tree needs to have appropriate second-pre-image attack protection of interior branch nodes [[50]] [[51]]. The Discloser then only needs to provide a subset of digests from the Merkle tree to prove that a given digest, aj contributed to the Merkle tree root digest, ‘A. For ACDCs with a small number of attributes, the added complexity of the Merkle tree approach may not be worth the savings in verbosity. #### Hierarchical derivation at issuance of selectively disclosable attribute ACDCs -The amount of data transferred between the Issuer and Issuee (or recipient in the case of an Untargeted ACDC) at issuance of a selectively disclosable attribute ACDC may be minimized by using a hierarchical deterministic derivation function to derive the value of the UUDI, `u`, fields from a shared secret salt [[ref: Salt]]. +The amount of data transferred between the Issuer and Issuee (or recipient in the case of an Untargeted ACDC) at issuance of a selectively disclosable attribute ACDC may be minimized by using a hierarchical deterministic derivation function to derive the value of the UUDI, `u`, fields from a shared secret salt [[29]]. -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 and Issuee AIDs, (or recipient AID in the case of an Untargeted ACDC), a corresponding X15519 asymmetric encryption Key pair(s) may be derived from each controlling Ed25519 key pair(s) [[ref: EdSC]] [[ref: PSEd]] [[ref: TMEd]] [[ref: SKEM]]. An X25519 public key may be derived securely from an Ed25519 public key [[ref: KeyEx]] [[ref: SKEM]]. Likewise, an X25519 private key may be derived securely from an Ed25519 private key [[ref: KeyEx]] [[ref: SKEM]]. +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 and Issuee AIDs, (or recipient AID in the case of an Untargeted ACDC), a corresponding X15519 asymmetric encryption Key pair(s) may be derived from each controlling Ed25519 key pair(s) [[36]] [[37]] [[38]] [[60]]. An X25519 public key may be derived securely from an Ed25519 public key [[46]] [[60]]. Likewise, an X25519 private key may be derived securely from an Ed25519 private key [[46]] [[60]]. -In an interactive approach, the Issuer derives a public asymmetric X25519 encryption key from the Issuee's published Ed25519 public key and the Issuee derives a public asymmetric X25519 encryption key from the Issuer's published Ed25519 public key. The two then interact via a Diffie-Hellman (DH) key exchange to create a shared symmetric encryption key [[ref: KeyEx]] [[ref: DHKE]]. The shared symmetric encryption key may be used to encrypt the secret salt or the shared symmetric encryption key itself may be used has high entropy cryptographic material from which the secret salt may be derived. +In an interactive approach, the Issuer derives a public asymmetric X25519 encryption key from the Issuee's published Ed25519 public key and the Issuee derives a public asymmetric X25519 encryption key from the Issuer's published Ed25519 public key. The two then interact via a Diffie-Hellman (DH) key exchange to create a shared symmetric encryption key [[46]] [[45]]. The shared symmetric encryption key may be used to encrypt the secret salt or the shared symmetric encryption key itself may be used has high entropy cryptographic material from which the secret salt may be derived. In a non-interactive approach, the Issuer derives an X25519 asymmetric public encryption key from the Issuee's (recipient's) public Ed25519 public key. The Issuer then encrypts the secret salt with that public asymmetric encryption key and signs the encryption with the Issuer's private Ed25519 signing key. This is transmitted to the Issuee, who verifies the signature and decrypts the secret salt using the private X25519 decryption key derived from the Issuee's private Ed25519 key. This non-interactive approach is more scalable for AIDs that are controlled with a multi-sig group of signing keys. The Issuer can broadcast to all members of the Issuee's (or recipient's) multi-sig signing group individually asymmetrically encrypted and signed copies of then may be derived. Likewise, both compact and uncompacted versions of the ACDC then may be generated. The derivation path for the top-level UUID, `u`, field (for private ACDCS), is the string "0" and derivation path the zeroth indexed attribute in the Attributes array is the string ‘0/0’. Likewise, the next Attribute's derivation path is the string ‘0/1’ and so forth. @@ -3519,17 +3519,17 @@ For example, the Issuee could use one copy of a bulk-issued private ACDC per pre This is about Permissioned Correlation. Any Verifier that has received a complete presentation of a private ACDC has access to all the fields disclosed by the presentation but the terms of the Chain-link Confidentiality agreement may forbid sharing those field values outside a given context. Thus, an Issuee may use a combination of bulk-issued ACDCs with Chain-link Confidentiality to control Permissioned Correlation of the contents of an ACDC while allowing the SAID of the ACDC to be more public. The SAID of a private ACDC does not expose the ACDC contents to an unpermissioned 3rd party. Unique SAIDs belonging to bulk issued ACDCs prevent 3rd parties from making a provable correlation between ACDCs via their SAIDs in spite of those SAIDs being public. This does not stop malicious Verifiers (as 2nd parties) from colluding and correlating against the disclosed fields, but it does limit provable correlation to the information disclosed to a given group of malicious colluding Verifiers. To restate, unique SAIDs per copy of a set of private bulk issued ACDC prevent unpermissioned 3rd parties from making provable correlations, in spite of those SAIDs being public, unless they collude with malicious Verifiers (2nd parties). -In some applications, Chain Link Confidentiality is insufficient to deter unpermissioned correlation. Some Verifiers may be malicious with sufficient malicious incentives to overcome whatever counter incentives the terms of the contractual Chain-link confidentiality may impose. In these cases, more aggressive technological anti-correlation mechanisms such as bulk issued ACDCs may be useful. To elaborate, in spite of the fact that Chain-link confidentiality terms of use may forbid such malicious correlation, making such correlation more difficult technically may provide better protection than Chain-link confidentiality alone [[ref: CLC]]. +In some applications, Chain Link Confidentiality is insufficient to deter unpermissioned correlation. Some Verifiers may be malicious with sufficient malicious incentives to overcome whatever counter incentives the terms of the contractual Chain-link confidentiality may impose. In these cases, more aggressive technological anti-correlation mechanisms such as bulk issued ACDCs may be useful. To elaborate, in spite of the fact that Chain-link confidentiality terms of use may forbid such malicious correlation, making such correlation more difficult technically may provide better protection than Chain-link confidentiality alone [[44]. It is important to note that any group of colluding malicious Verifiers always may make a statistical correlation between presentations despite technical barriers to cryptographically provable correlation. This is called contextual linkability. In general, there is no cryptographic mechanism that precludes statistical correlation among a set of colluding Verifiers because they may make cryptographically unverifiable or unprovable assertions about information presented to them that may be proven as likely true using merely statistical correlation techniques. Linkability, due the context of the disclosure itself, may defeat any unlinkability guarantees of a cryptographic technique. Thus, without contractually protected disclosure, contextual linkability in spite of cryptographic unlinkability may make the complexity of using advanced cryptographic mechanisms to provide unlinkability an exercise in diminishing returns. #### Basic bulk issuance proceedure -The amount of data transferred between the Issuer and Issuee (or recipient of an untargeted ACDC) at issuance of a set of bulk issued ACDCs may be minimized by using a hierarchical deterministic derivation function to derive the value of the UUID, `u`, fields from a shared secret salt [[ref: Salt]]. +The amount of data transferred between the Issuer and Issuee (or recipient of an untargeted ACDC) at issuance of a set of bulk issued ACDCs may be minimized by using a hierarchical deterministic derivation function to derive the value of the UUID, `u`, fields from a shared secret salt [[29]]. -As described above, there are several ways that the Issuer may share a secret salt securely. Given that the Issuer and Issuee (or recipient for Untargeted ACDCs) AIDs are each controlled by an Ed25519 key pair(s), a corresponding X15519 asymmetric encryption key pair(s) may be derived from the controlling Ed25519 key pair(s) [[ref: EdSC]][[ref: PSEd]][[ref: TMEd]]. An X25519 public key may be securely derived from an Ed25519 public key [[ref: KeyEx]][[ref: SKEM]]. Likewise, an X25519 private key may be securely derived from an Ed25519 private key [[ref: KeyEx]][[ref: SKEM]]. +As described above, there are several ways that the Issuer may share a secret salt securely. Given that the Issuer and Issuee (or recipient for Untargeted ACDCs) AIDs are each controlled by an Ed25519 key pair(s), a corresponding X15519 asymmetric encryption key pair(s) may be derived from the controlling Ed25519 key pair(s) [[36]][[37]][[38]]. An X25519 public key may be securely derived from an Ed25519 public key [[46]][[60]]. Likewise, an X25519 private key may be securely derived from an Ed25519 private key [[46]][[60]]. -In an interactive approach, the Issuer derives a public asymmetric X25519 encryption key from the Issuee's published Ed25519 public key and the Issuee derives a public asymmetric X25519 encryption key from the Issuer's published Ed25519 public key. The two then interact via a Diffie-Hellman (DH) key exchange to create a shared symmetric encryption key [[ref: KeyEx]][[ref: DHKE]]. The shared symmetric encryption key may be used to encrypt the secret salt or the shared symmetric encryption key itself may be used has high entropy cryptographic material from which the secret salt may be derived. +In an interactive approach, the Issuer derives a public asymmetric X25519 encryption key from the Issuee's published Ed25519 public key and the Issuee derives a public asymmetric X25519 encryption key from the Issuer's published Ed25519 public key. The two then interact via a Diffie-Hellman (DH) key exchange to create a shared symmetric encryption key [[46]][[45]]. The shared symmetric encryption key may be used to encrypt the secret salt or the shared symmetric encryption key itself may be used has high entropy cryptographic material from which the secret salt may be derived. In a non-interactive approach, the Issuer derives an X25519 asymmetric public encryption key from the Issuee's (or recipient's) public Ed25519 public key. The Issuer then encrypts the secret salt with that public asymmetric encryption key and signs the encryption with the Issuer's private Ed25519 signing key. This is transmitted to the Issuee, who verifies the signature and decrypts the secret salt using the private X25519 decryption key derived from the Issuee's private Ed25519 key. This non-interactive approach is more scalable for AIDs that are controlled with a multi-sig group of signing keys. The Issuer can broadcast to all members of the Issuee's (or recipient's) multi-sig signing group individually asymmetrically encrypted and signed copies of the secret salt. @@ -3550,7 +3550,7 @@ Suppose there are ‘M’ ACDCs in a bulk issued set. Using zero-based indexing Let ck = vk + dk denote the blinding concatenation where ‘+’ is the infix concatenation Operator. Then the blinded digest, bk, is given by, bk = H(ck) = H(vk + dk), -where H is the digest Operator. Blinding is performed by a digest of the concatenation of the binding factor, vk, with the SAID, dk instead of XORing the two. An XOR of two elements whose bit count is much greater than 2 is not vulnerable to a birthday table attack [[ref: BDay]] [[ref: DRB]] [[ref: BDC]]. In order to XOR, however, the two must be of the same length. Different SAIDs MAY be of different lengths, however, and therefore, may require different length blinding factors. Because concatenation is length independent it is simpler to implement. +where H is the digest Operator. Blinding is performed by a digest of the concatenation of the binding factor, vk, with the SAID, dk instead of XORing the two. An XOR of two elements whose bit count is much greater than 2 is not vulnerable to a birthday table attack [[32]] [[31]] [[33]]. In order to XOR, however, the two must be of the same length. Different SAIDs MAY be of different lengths, however, and therefore, may require different length blinding factors. Because concatenation is length independent it is simpler to implement. The aggregation of blinded digests, ‘B’, is given by, B = H(C(bk for all k in \{0, ..., M-1\})), @@ -3558,7 +3558,7 @@ where ‘C’ is the concatenation Operator and ‘H’ is the digest Operator. The aggregate, ‘B’, makes a blinded cryptographic commitment to the ordered elements in the li’t \[b0, b1, ...., bM-1\] A commitment to ‘B’ is a commitment to all the bk and hence all the dk. -Given sufficient collision resistance of the digest Operator, the digest of an ordered concatenation is not subject to a birthday attack on its concatenated elements [[ref: BDC]][[ref: BDay]][[ref: QCHC]][[ref: HCR]][[ref: Hash]]. +Given sufficient collision resistance of the digest Operator, the digest of an ordered concatenation is not subject to a birthday attack on its concatenated elements [[33]][[32]][[35]][[34]][[48]]. Disclosure of any given bk element does not expose or disclose any discoverable information detail about either the SAID of its associated ACDC or any other ACDC's SAID. Therefore, the full list of bk elements can be disclosed safely without exposing the blinded bulk issued SAID values, dk. @@ -3601,9 +3601,9 @@ The requirement of an anchored issuance proof seal of the aggregate ‘B’ mean #### Inclusion proof via Merkle tree -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 more efficient approach is to create a Merkle tree of the blinded SAID digests, bk and set the aggregate ‘B’ value as the Merkle tree root digest [[ref: Mrkl]]. +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 more efficient approach is to create a Merkle tree of the blinded SAID digests, bk and set the aggregate ‘B’ value as the Merkle tree root digest [[49]]. -The Merkle tree needs to have appropriate second-pre-image attack protection of interior branch nodes [[ref: TwoPI]] [[ref: MTSec]]. The Discloser then only needs to provide a subset of digests from the Merkle tree to prove that a given digest, bk contributed to the Merkle tree root digest. For a small-numbered bulk-issued set of ACDCs, the added complexity of the Merkle tree approach may not be worth the savings in verbosity. +The Merkle tree needs to have appropriate second-pre-image attack protection of interior branch nodes [[50]] [[51]]. The Discloser then only needs to provide a subset of digests from the Merkle tree to prove that a given digest, bk contributed to the Merkle tree root digest. For a small-numbered bulk-issued set of ACDCs, the added complexity of the Merkle tree approach may not be worth the savings in verbosity. #### Bulk issuance of private ACDCs with unique issuee AIDs @@ -4272,280 +4272,244 @@ Composed Schema that supports both public compact and uncompacted variants [//]: # (# Bibliography) -[[def: Composable Event Streaming Representation, CESR]] +[1]. Composable Event Streaming Representation, CESR -~ https://github.com/trustoverip/tswg-acdc-specification +[1]: https://github.com/trustoverip/tswg-acdc-specification -[[def: Key Event Receipt Infrastructure, KERI]] +[2]. Key Event Receipt Infrastructure, KERI -~ https://github.com/trustoverip/tswg-keri-specification +[2]: https://github.com/trustoverip/tswg-keri-specification -[[def: Self-Addressing IDentifier, SAID]] +[3]. Self-Addressing IDentifier, SAID -~ https://github.com/trustoverip/tswg-cesr-specification +[3]: https://github.com/trustoverip/tswg-cesr-specification -[[def: Out-Of-Band-Introduction, OOBI]] +[4]. Out-Of-Band-Introduction, OOBI -~ https://github.com/trustoverip/tswg-keri-specification +[4]: https://github.com/trustoverip/tswg-keri-specification -[[def: DIDK_ID, IETF DID-KERI Internet Draft]] +[5]. DIDK_ID, IETF DID-KERI Internet Draft -~ https://github.com/WebOfTrust/ietf-did-keri +[5]: https://github.com/WebOfTrust/ietf-did-keri -[[def: RFC6901, JavaScript Object Notation (JSON) Pointer]] +[6]. RFC6901, JavaScript Object Notation (JSON) Pointer -~ https://datatracker.ietf.org/doc/html/rfc6901 +[6]: https://datatracker.ietf.org/doc/html/rfc6901 -[[def: JSON, JavaScript Object Notation Delimeters]] +[7]. JSON, JavaScript Object Notation Delimeters -~ https://www.json.org/json-en.html +[7]: https://www.json.org/json-en.html -[[def: RFC8259, JSON (JavaScript Object Notation)]] +[8]. RFC8259, JSON (JavaScript Object Notation) -~ https://datatracker.ietf.org/doc/html/rfc8259 +[8]: https://datatracker.ietf.org/doc/html/rfc8259 -[[def: RFC4627, The application/json Media Type for JavaScript Object Notation (JSON)]] +[9]. RFC4627, The application/json Media Type for JavaScript Object Notation (JSON) -~ https://datatracker.ietf.org/doc/rfc4627/ +[9]: https://datatracker.ietf.org/doc/rfc4627/ -[[def: JSch, JSON Schema]] +[10]. JSch, JSON Schema -~ https://json-schema.org +[10]: https://json-schema.org -[[def: JSch_202012, JSON Schema 2020-12]] +[11]. JSch_202012, JSON Schema 2020-12 -~ https://json-schema.org/draft/2020-12/release-notes.html +[11]: https://json-schema.org/draft/2020-12/release-notes.html -[[def: CBOR, CBOR Mapping Object Codes]] +[12]. CBOR, CBOR Mapping Object Codes -~ https://en.wikipedia.org/wiki/CBOR +[12]: https://en.wikipedia.org/wiki/CBOR -[[def: RFC8949, Concise Binary Object Representation (CBOR)]] +[13]. RFC8949, Concise Binary Object Representation (CBOR) -~ https://datatracker.ietf.org/doc/rfc8949/ +[13]: https://datatracker.ietf.org/doc/rfc8949/ -[[def: MGPK, Msgpack Mapping Object Codes]] +[14]. MGPK, Msgpack Mapping Object Codes -~ https://github.com/msgpack/msgpack/blob/master/spec.md +[14]: https://github.com/msgpack/msgpack/blob/master/spec.md -[[def: RFC3986, Uniform Resource Identifier (URI): Generic Syntax]] +[15]. RFC3986, Uniform Resource Identifier (URI): Generic Syntax -~ https://datatracker.ietf.org/doc/html/rfc3986 +[15]: https://datatracker.ietf.org/doc/html/rfc3986 -[[def: RFC8820, URI Design and Ownership]] +[16]. RFC8820, URI Design and Ownership -~ https://datatracker.ietf.org/doc/html/rfc8820 +[16]: https://datatracker.ietf.org/doc/html/rfc8820 -[[def: ACDC_WP, Authentic Chained Data Containers (ACDC) White Paper]] +[17]. ACDC_TF, ACDC (Authentic Chained Data Container) Task Force -~ https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/ACDC.web.pdf +[17]: https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force -[[def: VCEnh, VC Spec Enhancement Strategy Proposal]] +[18]. TOIP, Trust Over IP (ToIP) Foundation -~ https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/VC_Enhancement_Strategy.md +[18]: https://trustoverip.org -[[def: ACDC_TF, ACDC (Authentic Chained Data Container) Task Force]] +[19]. ITPS, Information-Theoretic and Perfect Security -~ https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force +[19]: https://en.wikipedia.org/wiki/Information-theoretic_security -[[def: TOIP, Trust Over IP (ToIP) Foundation]] +[20]. OTP, One-Time-Pad -~ https://trustoverip.org +[20]: https://en.wikipedia.org/wiki/One-time_pad -[[def: IETF, Internet Engineering Task Force]] +[21]. VCphr, Vernom Cipher (OTP) -~ https://www.ietf.org +[21]: https://www.ciphermachinesandcryptology.com/en/onetimepad.htm -[[def: KERI, Key Event Receipt Infrastructure (KERI)]] +[22]. SSplt, Secret Splitting -~ https://arxiv.org/abs/1907.02143 +[22]: https://www.ciphermachinesandcryptology.com/en/secretsplitting.htm -[[def: ITPS, Information-Theoretic and Perfect Security]] +[23]. SShr, Secret Sharing -~ https://en.wikipedia.org/wiki/Information-theoretic_security +[23]: https://en.wikipedia.org/wiki/Secret_sharing -[[def: OTP, One-Time-Pad]] +[24]. GLEIF, GLEIF (Global Legal Entity Identifier Foundation) -~ https://en.wikipedia.org/wiki/One-time_pad +[24]: https://www.gleif.org/en/ -[[def: VCphr, Vernom Cipher (OTP)]] +[25]. vLEI, vLEI (verifiable Legal Entity Identifier) Definition -~ https://www.ciphermachinesandcryptology.com/en/onetimepad.htm +[25]: https://github.com/WebOfTrust/vLEI -[[def: SSplt, Secret Splitting]] +[26]. GLEIF_vLEI, GLEIF vLEI (verifiable Legal Entity Identifier) -~ https://www.ciphermachinesandcryptology.com/en/secretsplitting.htm +[26]: https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-lei-vlei -[[def: SShr, Secret Sharing]] +[27]. GLEIF_KERI, GLEIF with KERI Architecture -~ https://en.wikipedia.org/wiki/Secret_sharing +[27]: https://github.com/WebOfTrust/vLEI -[[def: CSPRNG, Cryptographically-secure pseudorandom number generator (CSPRNG)]] +[28]. W3C_DID, W3C Decentralized Identifiers (DIDs) v1.0 -~ https://en.wikipedia.org/wiki/Cryptographically-secure_pseudorandom_number_generator +[28]: https://w3c-ccg.github.io/did-spec/ -[[def: IThry, Information Theory]] +[29]. Salt, Salts, Nonces, and Initial Values -~ https://en.wikipedia.org/wiki/Information_theory +[29]: https://medium.com/@fridakahsas/salt-nonces-and-ivs-whats-the-difference-d7a44724a447 -[[def: CAcc, Cryptographic Accumulator]] +[30]. RB, Rainbow Table -~ https://en.wikipedia.org/wiki/Accumulator_(cryptography) +[30]: https://en.wikipedia.org/wiki/Rainbow_table -[[def: XORA, XORA (XORed Accumulator)]] +[31]. DRB, Dictionary Attacks, Rainbow Table Attacks and how Password Salting defends against them -~ https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/XORA.md +[31]: https://www.commonlounge.com/discussion/2ee3f431a19e4deabe4aa30b43710aa7 -[[def: GLEIF, GLEIF (Global Legal Entity Identifier Foundation)]] +[32]. BDay, Birthday Attack -~ https://www.gleif.org/en/ +[32]: https://en.wikipedia.org/wiki/Birthday_attack -[[def: vLEI, vLEI (verifiable Legal Entity Identifier) Definition]] +[33]. BDC, Birthday Attacks, Collisions, And Password Strength -~ https://github.com/WebOfTrust/vLEI +[33]: https://auth0.com/blog/birthday-attacks-collisions-and-password-strength/ -[[def: GLEIF_vLEI, GLEIF vLEI (verifiable Legal Entity Identifier)]] +[34]. HCR, Hash Collision Resistance -~ https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-lei-vlei +[34]: https://en.wikipedia.org/wiki/Collision_resistance -[[def: GLEIF_KERI, GLEIF with KERI Architecture]] +[35]. QCHC, Cost analysis of hash collisions: Will quantum computers make SHARCS obsolete? -~ https://github.com/WebOfTrust/vLEI +[35]: https://cr.yp.to/hash/collisioncost-20090823.pdf -[[def: W3C_VC, W3C Verifiable Credentials Data Model v1.1]] +[36]. EdSC, The Provable Security of Ed25519: Theory and Practice Report -~ https://www.w3.org/TR/vc-data-model/ +[36]: https://eprint.iacr.org/2020/823 -[[def: W3C_DID, W3C Decentralized Identifiers (DIDs) v1.0]] +[37]. PSEd, The Provable Security of Ed25519: Theory and Practice -~ https://w3c-ccg.github.io/did-spec/ +[37]: https://ieeexplore.ieee.org/document/9519456?denied= -[[def: Salt, Salts, Nonces, and Initial Values]] +[38]. TMEd, Taming the many EdDSAs -~ https://medium.com/@fridakahsas/salt-nonces-and-ivs-whats-the-difference-d7a44724a447 +[38]: https://eprint.iacr.org/2020/1244.pdf -[[def: RB, Rainbow Table]] +[39]. JSchCp, Schema Composition in JSON Schema -~ https://en.wikipedia.org/wiki/Rainbow_table +[39]: https://json-schema.org/understanding-json-schema/reference/combining.html -[[def: DRB, Dictionary Attacks, Rainbow Table Attacks and how Password Salting defends against them]] +[40]. JSchRE, Regular Expressions in JSON Schema -~ https://www.commonlounge.com/discussion/2ee3f431a19e4deabe4aa30b43710aa7 +[40]: https://json-schema.org/understanding-json-schema/reference/regular_expressions.html -[[def: BDay, Birthday Attack]] +[41]. JSchId, JSON Schema Identification -~ https://en.wikipedia.org/wiki/Birthday_attack +[41]: https://json-schema.org/understanding-json-schema/structuring.html#schema-identification -[[def: BDC, Birthday Attacks, Collisions, And Password Strength]] +[42]. JSchCx, Complex JSON Schema Structuring -~ https://auth0.com/blog/birthday-attacks-collisions-and-password-strength/ +[42]: https://json-schema.org/understanding-json-schema/structuring.html#base-uri -[[def: HCR, Hash Collision Resistance]] +[43]. RC, Ricardian Contract -~ https://en.wikipedia.org/wiki/Collision_resistance +[43]: https://en.wikipedia.org/wiki/Ricardian_contract -[[def: QCHC, Cost analysis of hash collisions: Will quantum computers make SHARCS obsolete?]] +[44]. CLC, Chain-Link Confidentiality -~ https://cr.yp.to/hash/collisioncost-20090823.pdf +[44]: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818 -[[def: EdSC, The Provable Security of Ed25519: Theory and Practice Report]] +[45]. DHKE, Diffie-Hellman Key Exchange -~ https://eprint.iacr.org/2020/823 +[45]: https://www.infoworld.com/article/3647751/understand-diffie-hellman-key-exchange.html -[[def: PSEd, The Provable Security of Ed25519: Theory and Practice]] +[46]. KeyEx, Key Exchange -~ https://ieeexplore.ieee.org/document/9519456?denied= +[46]: https://libsodium.gitbook.io/doc/key_exchange -[[def: TMEd, Taming the many EdDSAs]] +[47]. IDSys, Identity System Essentials -~ https://eprint.iacr.org/2020/1244.pdf +[47]: https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf -[[def: JSchCp, Schema Composition in JSON Schema]] +[48]. Hash, Cryptographic Hash Function -~ https://json-schema.org/understanding-json-schema/reference/combining.html +[48]: https://en.wikipedia.org/wiki/Cryptographic_hash_function -[[def: JSchRE, Regular Expressions in JSON Schema]] +[49]. Mrkl, Merkle Tree -~ https://json-schema.org/understanding-json-schema/reference/regular_expressions.html +[49]: https://en.wikipedia.org/wiki/Merkle_tree -[[def: JSchId, JSON Schema Identification]] +[50]. TwoPI, Second Pre-image Attack on Merkle Trees -~ https://json-schema.org/understanding-json-schema/structuring.html#schema-identification +[50]: https://flawed.net.nz/2018/02/21/attacking-merkle-trees-with-a-second-preimage-attack/ -[[def: JSchCx, Complex JSON Schema Structuring]] +[51]. MTSec, Merkle Tree Security -~ https://json-schema.org/understanding-json-schema/structuring.html#base-uri +[51]: https://blog.enuma.io/update/2019/06/10/merkle-trees-not-that-simple.html -[[def: RC, Ricardian Contract]] +[52]. DSig, Digital Signature -~ https://en.wikipedia.org/wiki/Ricardian_contract +[52]: https://en.wikipedia.org/wiki/Digital_signature -[[def: CLC, Chain-Link Confidentiality]] +[53]. Level, Security Level -~ https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818 +[53]: https://en.wikipedia.org/wiki/Security_level -[[def: DHKE, Diffie-Hellman Key Exchange]] +[54]. Twin, Digital Twin -~ https://www.infoworld.com/article/3647751/understand-diffie-hellman-key-exchange.html +[54]: https://en.wikipedia.org/wiki/Digital_twin -[[def: KeyEx, Key Exchange]] +[55]. TMal, Transaction Malleability -~ https://libsodium.gitbook.io/doc/key_exchange +[55]: https://en.wikipedia.org/wiki/Transaction_malleability_problem -[[def: IDSys, Identity System Essentials]] +[56]. PGM, The Property Graph Database Model -~ https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf +[56]: http://ceur-ws.org/Vol-2100/paper26.pdf -[[def: Hash, Cryptographic Hash Function]] +[57]. Dots, Constructions from Dots and Lines -~ https://en.wikipedia.org/wiki/Cryptographic_hash_function +[57]: https://arxiv.org/pdf/1006.2361.pdf -[[def: Mrkl, Merkle Tree]] +[58]. KG, Knowledge Graphs -~ https://en.wikipedia.org/wiki/Merkle_tree +[58]: https://arxiv.org/pdf/2003.02320.pdf -[[def: TwoPI, Second Pre-image Attack on Merkle Trees]] +[59]. Abuse, Alice Attempts to Abuse a Verifiable Credential -~ https://flawed.net.nz/2018/02/21/attacking-merkle-trees-with-a-second-preimage-attack/ +[59]: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md -[[def: MTSec, Merkle Tree Security]] +[60]. SKEM, On using the same key pair for Ed25519 and an X25519 based KEM -~ https://blog.enuma.io/update/2019/06/10/merkle-trees-not-that-simple.html - -[[def: DSig, Digital Signature]] - -~ https://en.wikipedia.org/wiki/Digital_signature - -[[def: Level, Security Level]] - -~ https://en.wikipedia.org/wiki/Security_level - -[[def: Twin, Digital Twin]] - -~ https://en.wikipedia.org/wiki/Digital_twin - -[[def: TMal, Transaction Malleability]] - -~ https://en.wikipedia.org/wiki/Transaction_malleability_problem - -[[def: PGM, The Property Graph Database Model]] - -~ http://ceur-ws.org/Vol-2100/paper26.pdf - -[[def: Dots, Constructions from Dots and Lines]] - -~ https://arxiv.org/pdf/1006.2361.pdf - -[[def: KG, Knowledge Graphs]] - -~ https://arxiv.org/pdf/2003.02320.pdf - -[[def: Abuse, Alice Attempts to Abuse a Verifiable Credential]] - -~ https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md - -[[def: SKEM, On using the same key pair for Ed25519 and an X25519 based KEM]] - -~ https://eprint.iacr.org/2021/509 +[60]: https://eprint.iacr.org/2021/509 [[spec]]