Code change:
3. <del> This section describes representations of merkle proof structures in CBOR. Some of the structures such as the construction of a merkle tree leaf, or an inclusion proof from a leaf to a merkle root, might have several different representations. Some differences in representations are necessary to support efficient verification of different kinds of inclusion proofs and for compatibility with deployed tree algorithms used in specific implementations. In case of RFC9162, this is defined in Section 2.1.1.  Definition of the Merkle Tree. 3.1. RFC6962 defines a merkle audit path for a leaf in a merkle tree as the shortest list of additional nodes in the merkle tree required to compute the merkle root for that tree. RFC9162 changed the term from "merkle audit path" to "merkle inclusion proof". We prefer to use the term "inclusion path" to avoid confusion with Signed Inclusion Proof. For tree algorithm "RFC9162_SHA256", we define the following compact encoding of an inclusion proof for a leaf: Leaf index is also sometimes referred to as sequence number. 3.2. A Merkle root is signed with COSE_Sign1: Protected header parameters: alg (label: 1): REQUIRED.  Signature algorithm identifier.  Value type: int / tstr. verifiable_data_structure (label: TBD): REQUIRED.  Merkle tree algorithm identifier.  Value type: int / tstr. crit (label: 2): REQUIRED.  Criticality marker.  Value type: [ +label ] </del> <ins> This section describes representations of verifiable data structure proofs structures in CBOR. </ins> <del> The criticality header MUST contain the verifiable_data_structure label. </del> <ins> Different verifiable data structures support the same proof types, but the representations of the proofs varies greatly. </ins> <del> The envelope payload MUST be computed by the process defined for the verifiable_data_structure. </del> <ins> For example, construction of a merkle tree leaf, or an inclusion proof from a leaf to a merkle root, might have several different representations, depending on the verifiable data structure used. </ins> <del> The envelope payload MUST be detached, and recomputed by the verifier. </del> <ins> Some differences in representations are necessary to support efficient verification of different kinds of proofs and for compatibility with specific implementations. </ins> <del> One example of a Signed Inclusion Proof is a "transparent statement" as defined in I-D.ietf-scitt-architecture. </del> <ins> Some proof types benefit from standard envelope formats for signing and encryption. </ins> <del> 3.3. </del> <ins> In order to improve interoperability we define two extension points for enabling verifiable data structures with COSE, and we provide concrete examples for the structures and proofs defined in RFC9162. </ins> <del> 4. </del> <ins> 3.1. </ins> This document establishes a registry of verifiable data structure <del> 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. </del> <ins> algorithms, with the following initial contents: </ins> <del> How to produce and consume the proof types supported. </del> <ins> 3.1.1. </ins> Each specification MUST define how to encode the algorithm and proof types in CBOR. <del> For example, RFC9162_SHA256 requires the following: TBD_1, the verifiable data structure algorithm (binary merkle tree using sha256) TBD_2, the inclusion proof type (binary merkle tree using sha256, inclusion proof) TBD_3, the consistency proof type (binary merkle tree using sha256, consistency proof) </del> <ins> Each specification MUST define how to produce and consume the supported proof types. </ins> See sec-rfc-9162-verifiable-data-structure-definition as an example. <ins> 4. </ins> Proof types are specific to their associated "verifiable data <del> structure", for example, different merkle trees might support </del> <ins> structure", for example, different Merkle trees might support </ins> different representations of "inclusion proof" or "consistency proof".

Related discussion:
text: This PR build on and attempts to clarify what is generic vc what is specific to RFC9162 encodings
Mostly improves on the earlier version, I like the generality it allows for. A couple of larger questions in here amongst the suggestions