Code change:
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.

Related discussion:
text: There were basically 2 paths discussed: (implemented in this PR) treealg (TBD1): RFC9162 (1) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): BitcoinMerkleTree (2) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): Merkle^2 Tree (3) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg search proof (TBD4): bytes based on treealg non inclusion proof (TBD5): bytes based on treealg (previously discussed at IETF 115) treealg (TBD1) : "RFC9162SHA256INCLUSIONPROOF" (TBDA) proof (TBDB): bytes based on alg treealg (TBD1) : "RFC9162SHA256CONSISTENCYPROOF" (TBDC) proof (TBDB): bytes based on alg Other things to consider... Can an unprotected header contain multiple proofs for a single type? Can an unprotected header contain multiple proofs of multiple types?
NAME NAME thank you for the reviews. All the CDDL examples will need some help, and certainly there is a lot more editorial work that needs to be done to fully align to this approach. I tried to do the minimum in this PR to host the discussion, but if we merge this, there will need to be further cleanup.
I should point out that the deletion of the consistency proof CDDL, means that it shows up before you define it below. If you think that is ok, I am fine with it.Approved, acknowledging the need for further editorial work & CDDL examplesI agree with Orie's choices; "verifiable data structure" and "proof type" are good generalizations, and I prefer the 2-layer algorithm as e.g. some verifiers may care about a commitment to a VDS even if they don't use a particular proof type.