3.3. <del> 3.3.1. </del> 4. <del> This document establishes a registry of merkle tree algorithms with the following initial contents: </del> <ins> This document establishes a registry of verifiable data structure algorithms values for TBD_1, with the following initial contents: Each algorithm defines: How to identify the data structures supported. How to identify the proof types supported. How to produce and consume the proof types supported. </ins> <del> Each tree algorithm defines: </del> <ins> Each specification MUST define how to encode the algorithm and proof types in CBOR. </ins> <del> How to compute a leaf from a payload and extra data, such as the current size of the tree. </del> <ins> For example, RFC9162_SHA256 requires the following: </ins> <del> How to compute the merkle root from a sequence of leaves. </del> <ins> TBD_1, the verifiable data structure algorithm (binary merkle tree using sha256) </ins> <del> How to compute an inclusion-proof for a leaf. </del> <ins> TBD_2, the inclusion proof type (binary merkle tree using sha256, inclusion proof) </ins> <del> How to compute a consistency-proof for a leaf. </del> <ins> TBD_3, the consistency proof type (binary merkle tree using sha256, consistency proof) </ins> <del> Each specification MUST define how to encode each of these parameters in CBOR, and map them to: </del> <ins> See sec-rfc-9162-verifiable-data-structure-definition as an example. </ins> <del> TBD_1 - (tree alg) </del> <ins> Proof types are specific to their associated "verifiable data structure", for example, different merkle trees might support different representations of "inclusion proof" or "consistency proof". </ins> <del> TBD_2 - (inclusion proof) </del> <ins> Implementers should not expect interoperability accross "verifiable data structures", but they should expect conceptually similar properties across registered proof types. </ins> <del> TBD_3 - (consistency proof) </del> <ins> For example, 2 different merkle tree based verifiable data structures might both support proofs of inclusion.  Protocols requireing proof of inclusion ought to be able to preserve their functionality, while switching from one verifiable data structure to another, so long as both structures upport the same proof types. 5. This document establishes a registry of verifiable data structure proof types tags, with the following initial contents: 5.1. </ins> <del> See sec-rfc-9162-tree-alg-definition as an example. </del> <ins> Inclusion proofs provide a mechanism for a verifier to validate set membership. </ins> <del> 4.1. </del> <ins> The integer identifier for this "verifiable-data-structure-proof- type" is TBD_2.  The string identifier for this "verifiable-data- structure-proof-type" is "inclusion proof". sec-rfc9162-sha256-inclusion-proof provides a concrete example. 5.2. Consistency proofs provide a mechanism for a verifier to validate the consistency of a verifiable data structure. The integer identifier for this "verifiable-data-structure-proof- type" is TBD_3.  The string identifier for this "verifiable-data- structure-proof-type" is "consistency proof". sec-rfc9162-sha256-consistency-proof provides a concrete example. 5.3. </ins> This section defines how to map the data structures described in RFC9162 to the terminology defined in this document, using cbor and cose. <del> 4.1.1. </del> <ins> 5.3.1. </ins> <del> The integer identifier for "tree-alg" is 1.  The string identifier for "tree-alg" is "RFC9162_SHA256". </del> <ins> The integer identifier for this "verifiable-data-structure" is 1. The string identifier for this "verifiable-data-structure" is "RFC9162_SHA256". </ins> <del> 4.1.2. </del> <ins> 5.3.2. </ins> See RFC9162, 2.1.1.  Definition of the Merkle Tree. <del> 4.1.2.1. </del> <ins> 5.3.2.1. </ins> The cbor representation of a merkle root is the bytestring represenation of MTH. <del> 4.1.2.2. </del> <ins> 5.3.2.2. </ins> See RFC9162, 2.1.3.1.  Generating an Inclusion Proof. The cbor representation of the inclusion proof is: <del> 4.1.2.3. </del> <ins> 5.3.2.3. </ins> See RFC9162, 2.1.4.1.  Generating a Consistency Proof.