jiebi/CodeConvo huggingface dataset:
Code change:
This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:

Related discussion:
text: as possible, this document only specifies the format of Signed Statements (which must be used by all Issuers) and a very thin wrapper format for Receipts, which specifies the Transparency Service <del> identity and the agility parameters for the Merkle Tree Proof.  Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle-tree- proofs. </del> <ins> identity and the agility parameters for the Signed Inclusion Proofs. Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle- tree-proofs. </ins> This section describes at a high level, the three main roles and associated processes in SCITT: Issuers and the Signed Statement
Code change:
This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:

Related discussion:
text: other variants.  The Transparency Service is only required to support concise Receipts (i.e., whose size grows at most logarithmically in the number of entries in the Append-only Log) that can be encoded as <del> a COSE Signed Merkle Tree Proof. </del> <ins> a Signed Inclusion Proof. </ins> It is possible to offer multiple signature algorithms for the COSE <del> signature of receipts' Signed Merkle Tree, or to change the signing algorithm at later points.  However, the Merkle Tree algorithm (including its internal hash function) cannot easily be changed without breaking the consistency of the Append-only Log.  It is possible to maintain separate Registries for each algorithm in parallel but the Transparency Service is then responsible for proving their mutual consistency. </del> <ins> signature of receipts' Signed Inclusion Proofs, or to change the signing algorithm at later points.  However, the verifiable data structure cannot easily be changed without breaking the consistency of the Append-only Log.  It is possible to maintain separate Registries for each algorithm in parallel but the Transparency Service is then responsible for proving their mutual consistency. </ins> 5.2.3.1.
Code change:
This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:

Related discussion:
text: 6.4. When a Signed Statement is registered by a Transparency Service a <del> Transparent Statement is created.  This Transparent Statement consists of the Signed Statement and a Receipt.  Receipts are based on COSE Signed Merkle Tree Proofs (I-D.draft-steele-cose-merkle-tree- proofs) with an additional wrapper structure that adds the following information: </del> <ins> Receipt becomes available.  When a Receipt is included in a Signed Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE Signed Merkle Tree Proofs (I-D.draft-steele-cose-merkle-tree-proofs). Receipts protected headers have additional mandatory fields: : The "crit" header (id: 2) MUST be included and all SCITT- specific headers (version, DID of Transparency Service and Registration Policy) MUST be marked critical </ins>
Code change:
This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:

Related discussion:
text: Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency <del> Services.  If more than one service is configured, the Verifier MUST return which service the Transparent Statement is registered on. In some scenarios, the Verifier already expects a specific Issuer and Subject for the Transparent Statement, while in other cases they are not known in advance and can be an output of validation.  Verifiers MAY be configured to re-verify the Issuer's signature locally, but this requires a fresh resolution of the Issuer's DID, which MAY fail if the DID document is not available or if the Statement's signing key has been revoked.  Otherwise, the Verifier trusts the validation done by the Transparency Service during Registration. </del> <ins> Services. Verifiers MAY be configured to re-verify the Issuer's Signed Statment locally, but this requires a fresh resolution of the Issuer's verificaton keys, which MAY fail if the key has been revoked. </ins> Some Verifiers MAY decide to locally re-apply some or all of the Registration Policies, if they have limited trust in the Transparency Services.  In addition, Verifiers MAY apply arbitrary validation <del> policies after the signature and Receipt have been checked.  Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state. </del> <ins> policies after the Transparent Statement has been verified and validated.  Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state. </ins> Verifiers MAY offer options to store or share the Receipt of the Transparent Statement for auditing the Transparency Services in case
Code change:
This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:

Related discussion:
text: This may involve registering the same Signed Statements at different Transparency Services, each with their own purpose and Registration <del> Policy.  This may also involve attaching multiple Receipts to the same Signed Statements, each Receipt endorsing the Issuer signature and a subset of prior Receipts, and each Transparency Service verifying prior Receipts as part of their Registration Policy. For example, a supplier may provide a complete, authoritative Transparency Service for its Signed Statements, whereas a Verifiers's Transparency Service may collect different kinds of Signed Statements to ensure complete auditing for a specific use case, and possibly require additional reviews before registering some of these Signed </del> <ins> Policy. This may also involve attaching multiple Receipts to the same Signed </ins> Statements. <del> An independent entities (security companies) may Issue statements of quality about different artifacts on their own Transparency Service. Verifiers choose which independent entities they trust, just as entities choose different security companies today. </del> <ins> For example, a software producer of a supply chain artifact might rely on multiple independent software producers operating transparency services for their upstream artifacts.  Downstream producers benefit from upstream producers providing higher transparency regarding their artifacts. </ins> 8.
Code change:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Related discussion:
text: 5.2.2. <ins> The Transparency Service records its configuration in the Append-Only Log using Transparent Statements with distinguished media type "application/scitt-configuration". The registration policy for statements with the media type suffix ("+<format>" is implementation-specific.  The implementation SHOULD document them, for example defining the Issuers authorized to register configuration Signed Statements. The Transparency Service is configured by the last Transparent Statement of this type.  The Transparency Service MUST register a Signed Statement that defines its initial configuration before registering any other Signed Statement.  The Transparency Service MAY register an additional Signed Statement that updates its configuration. The Transparency Service provides an endpoint that returns the Transparent Statement that describes its current configuration. The configuration "reg_info" SHOULD include a secure version number and a timestamp. The sample configuration payload uses the CDDL 5.2.3. </ins> Authorization is needed prior to registration of Signed Statements to ensure completeness of an audit.  A Transparency Service that registers valid Signed Statement offered by anonymous Issuers would
Code change:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Related discussion:
text: specification leaves the implementation of the Registration Policy to the provider of the Transparency Services and its users. <ins> A provider of a Transparency Service indicates what Registration Policy is used in a given deployment and inform its users about changes to the Registration Policy by issuing and registering configuration statements. </ins> As a minimum, a Transparency Service MUST authenticate the Issuer of the Signed Statement, which requires some form of trust anchor.  As defined in RFC6024, "A trust anchor represents an authoritative
Code change:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Related discussion:
text: key or other structure, as appropriate.  It can be a non-root certificate when it is a certificate. <del> A provider of a Transparency Service is, however, expected to indicate what Registration Policy is used in a given deployment and inform its users about changes to the Registration Policy. 5.2.3. </del> <ins> 5.2.4. </ins> There are many different candidate verifiable data structures that may be used to implement an Append-only Log, such as chronological
Code change:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Related discussion:
text: parallel but the Transparency Service is then responsible for proving their mutual consistency. <del> 5.2.3.1. </del> <ins> 5.2.4.1. </ins> A Transparency Service is append-only.  Once a Signed Statement is registered and becomes a Transparent Statement, it cannot be
Code change:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Related discussion:
text: Append-only Log becomes immutable, and the Receipt provides universally-verifiable evidence of this property. <del> 5.2.3.2. </del> <ins> 5.2.4.2. </ins> There is no fork in the Append-only Log.  Everyone with access to its contents sees the same sequence of entries, and can check its
Code change:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Related discussion:
text: state of the Append-only Log, encoded in an old Receipt, is consistent with the current Append-only Log state. <del> 5.2.3.3. </del> <ins> 5.2.4.3. </ins> Everyone with access to the Transparency Service can check the correctness of its contents.  In particular:
Code change:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Related discussion:
text: a Transparency Service MAY additionally support verifiability of client authentication and access control <del> 5.2.3.4. </del> <ins> 5.2.4.4. </ins> Transparency Services MAY document their governance rules and procedures for operating the Transparency Service and updating its
Code change:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Related discussion:
text: issued with those keys. The Issuer's DID is required and appears in the "1 iss" claim of the <del> "13 CWT_Claims" protected header of the Signed Statements' Envelope. </del> <ins> "15 CWT_Claims" protected header of the Signed Statements' Envelope. </ins> The version of the key from the DID Document used to sign the Signed Statement is written in the "4 kid" protected header.
Code change:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Related discussion:
text: Some Verifiers may systematically fetch all Transparent Statements using the CWT_Claims Subject and assess them alongside the Transparent Statement they are verifying to ensure freshness, <del> completeness of evidence, and the promise of non-equivocation. </del> <ins> completeness of evidence, and Non-equivocation. </ins> Some Verifiers may choose to subset the collection of Statements, filtering on the payload type (Protected Header "3"), the CWT <del> (Protected Header "13") Issuer claim, or other non-opaque properties. </del> <ins> (Protected Header "15") Issuer claim, or other non-opaque properties. </ins> Some Verifiers may systematically resolve Issuer DIDs to fetch the latest corresponding DID documents.  This behavior strictly enforces
Code change:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Related discussion:
text: <del> (label: "13" pending CWT_CLAIM_COSE): A CWT representing the </del> <ins> (label: "15" pending CWT_CLAIM_COSE): A CWT representing the </ins> Issuer ("iss") making the statement, and the Subject ("sub") to correlate a collection of statements about an Artifact. Additional CWT_CLAIMS MAY be used, while "iss" and "sub" MUST be
Code change:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Related discussion:
text: will be available to support them. An Issuer that knows of a changed state of quality for an Artifact, <del> SHOULD Register a new Signed Statement, using the same "13" CWT "iss" </del> <ins> SHOULD Register a new Signed Statement, using the same "15" CWT "iss" </ins> and "sub" claims. Issuers MUST ensure that the Statement payloads in their Signed
Code change:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Related discussion:
text: In both cases, the SCITT Architecture provides generic, universally- verifiable cryptographic proof to individually blame Issuers or the Transparency Service.  On one hand, this enables valid actors to <del> detect and disambiguate malicious actors who issue contradictory Signed Statements to different entities (Verifiers, Auditors, Issuers), otherwise known as 'equivocation'.  On the other hand, their liability and the resulting damage to their reputation are </del> <ins> detect and disambiguate malicious actors who employ Equivocation with Signed Statements to different entities.  On the other hand, their liability and the resulting damage to their reputation are </ins> application specific, and out of scope of the SCITT Architecture. Verifiers and Auditors need not be trusted by other actors.  In