Original text:
operators might prefer only integrity protected content be made transparent. <del> 5.1. </del>  In cases where a single merkle root and multiple inclusion paths are used to prove inclusion for multiple payloads.  There is a risk that

Reviewer comments:
This PR attempts to generalize "merkle tree alg" and associated tags for "merkle tree proof types", to: "verifiable data structure" and associated "verifiable data structure proof types". This is intended to support similar structures that provide similar proof types, but that are not based on merkle trees. We are specifically thinking of cryptographic accumulators, and the merkle^2 paper.
I'm not attached to "verifiable data structure" or "verifiable data structure proof types", just needed a word that didn't imply "trees".
The overall "verifiable data structure" generalization is fine, and doesn't impact the structure of the document too much. However, I am not fully satisfied with generalization of proof types. It seems very strange that TBD1 ("binary merkle tree using sha256", a tag that appears in the protected header of the COSE signed root) and TBD2 ("binary merkle tree using sha256, inclusion proof", a tag that appears in the CBOR type for inclusion proof associated with TBD1). It seems clear that TBD2 and TBD3 are refinements of TBD1 that should ideally be in a separate registry. Furthermore, as discussed last week, the notion of proof type (inclusion proof, consistency proof, freshness proof...) is a lot more meaningful than the notion of verfiable data structure type for protocols that build on COMETRE. Therefore, it may be natural to define either a universal type for each proof type, or at least agree on the convention that proofs for all verifiable data structures must be CBOR tagged with the same proof type, which is then defined as a separate registry. Each RFC that extends COMETE must define a new verifiable data structure but may or may not extend the proof type registry. For instance, it would allow the CCF_ledger to use the same CBOR tags for inclusion proof and consistency proof instead of having to define 3 tags with different semantics.
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.

Revised text:
operators might prefer only integrity protected content be made transparent.  <ins> 6.1. </ins> In cases where a single merkle root and multiple inclusion paths are used to prove inclusion for multiple payloads.  There is a risk that