jiebi/TextFlow huggingface dataset:
Original text:
interoperability across different implementations of Transparency Services with various auditing and compliance requirements.  Issuers can register their Signed Statements on any Transparency Service, <del> with the guarantee that all Consumers will be able to verify them. </del>  1.

Reviewer comments:
Related mailing list thread: URL
these changes make sense to me
As part of , I would like to consider the removal of Consumer and consumer from this specification if we are not going to define it. It is a generalized term and I would rather expend work group time on trying to tailor an appropriate custom definition of it. I will likely post this issue to the mailing list and cross-reference that thread here and leave this issue for review for a week to solicit feedback. Related mailing list thread: URL
I do think Producer and Consumer is a good generic concept, with more clearly defined roles as Relying Party, Verifier, and Auditor, however, I'd support replacing Consumer with Relying Party or Verifier.
But we do not define them nor cite references that do. From a formality and procedures perspective in IETF, is that OK? Thanks for the feedback.
LGTM with some comments to accept/reject Hello, I have been reviewing the specification and there are usages of Consumer(s) as a specific term to be defined in the draft and consume/consumer(s) generically. The use of the term consumer is ill-defined and I would support not consuming time ahead of 119 defining it. Therefore, I am proposing that we remove the capitalized term and some generic usage of it for clarity. I welcome feedback on the pull request to alter or critique specific, individual changes (207), the issue to track the work for more general discussion (206), or in the form of replies in this thread on the mailing list. URL URL If I do not hear back in one week and there is no objection in the pull request, the issue, or mailing list, I will follow up and ask the authors to merge (if it has not been merged already). Thanks in advance for your review and any feedback you provide. Thanks, A.J.

Revised text:
interoperability across different implementations of Transparency Services with various auditing and compliance requirements.  Issuers can register their Signed Statements on any Transparency Service,  <ins> with the guarantee that all Auditors and Verifiers will be able to verify them. </ins> 1.
Original text:
wrapper format for Receipts, which specifies the Transparency Service identity and the agility parameters for the Signed Inclusion Proofs. Most of the details of the Receipt's contents are specified in the <del> COSE Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle- </del>  tree-proofs. This section describes at a high level, the three main roles and

Reviewer comments:
Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.

Revised text:
wrapper format for Receipts, which specifies the Transparency Service identity and the agility parameters for the Signed Inclusion Proofs. Most of the details of the Receipt's contents are specified in the  <ins> COSE Signed Merkle Tree Proof document I-D.draft-ietf-cose-merkle- </ins> tree-proofs. This section describes at a high level, the three main roles and
Original text:
proofs of non inclusion. Specific verifiable data structures, such those describes in RFC9162 <del> and I-D.draft-steele-cose-merkle-tree-proofs are out of scope for this document. </del>  4.1.4.

Reviewer comments:
Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.

Revised text:
proofs of non inclusion. Specific verifiable data structures, such those describes in RFC9162  <ins> and I-D.draft-ietf-cose-merkle-tree-proofs are out of scope for this document. </ins> 4.1.4.
Original text:
A Receipt is a Signed Statement, (cose-sign1), with addition claims in its protected header related to verifying the inclusion proof in <del> its unprotected header.  See I-D.draft-steele-cose-merkle-tree- proofs. </del>  fig-signed-statement-cddl illustrates a normative CDDL definition for of the protected header for Signed Statements and Receipts.

Reviewer comments:
Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.

Revised text:
A Receipt is a Signed Statement, (cose-sign1), with addition claims in its protected header related to verifying the inclusion proof in  <ins> its unprotected header.  See I-D.draft-ietf-cose-merkle-tree-proofs. </ins> fig-signed-statement-cddl illustrates a normative CDDL definition for of the protected header for Signed Statements and Receipts.
Original text:
Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE <del> Signed Merkle Tree Proofs (I-D.draft-steele-cose-merkle-tree-proofs). </del>  The registration time is defined as the timestamp at which the Transparency Service has added this Signed Statement to its Append-

Reviewer comments:
Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.

Revised text:
Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE  <ins> Signed Merkle Tree Proofs (I-D.draft-ietf-cose-merkle-tree-proofs). </ins> The registration time is defined as the timestamp at which the Transparency Service has added this Signed Statement to its Append-
Original text:
Verifiers MUST apply the verification process as described in Section 4.4 of RFC9052. <del> In order to verify the inclusion proof that is included in the Receipt, the verification process for the inclusion proof MUST be performed as described in the document that registers corresponding Verifiable Data Structure Parameters (see I-D.draft-steele-cose- merkle-tree-proofs). APIs exposing verification logic for Transparent Statements may wish to provide more details that a single boolean result, for example, indicating if the signature on the Receipt or Signed Statement is valid, if claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid. </del>  The algorithm-specific details of checking inclusion proofs are <del> covered in I-D.draft-steele-cose-merkle-tree-proofs.  The pseudo-code </del>  for validation of a transparent statement is as follows: Before checking a Transparent Statement, the Verifier must be

Reviewer comments:
Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.

Revised text:
Verifiers MUST apply the verification process as described in Section 4.4 of RFC9052.  <ins> APIs exposing verification logic for Transparent Statements may provide more details than a single boolean result.  For example, an API may indicate if the signature on the Receipt or Signed Statement is valid, if claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid. </ins> The algorithm-specific details of checking inclusion proofs are  <ins> covered in I-D.draft-ietf-cose-merkle-tree-proofs.  The pseudo-code </ins> for validation of a transparent statement is as follows: Before checking a Transparent Statement, the Verifier must be
Original text:
The terms "header", "payload", and "to-be-signed bytes" are defined in RFC9052.  3. In this document, the definition of transparency is intended to build

Reviewer comments:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Revised text:
The terms "header", "payload", and "to-be-signed bytes" are defined in RFC9052. <ins> The terms claim is defined in RFC8392, and is repeated here for readability: </ins> 3. In this document, the definition of transparency is intended to build
Original text:
to allow implementations to make the restrictions that make the most sense for their operational use cases. <del> At least one identifier for an identity document MUST be included in the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". Support for "x5t" is mandatory to implement. Support for "kid" and "x5chain" is optional. When "x5t" or "x5chain" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. The mechanisms for how Transparency Services obtain identity documents is out-of-scope of this document. The "kid" header parameter MUST be present when neither "x5t" nor "x5chain" are present.  Key discovery protocols are out-of-scope of this document. The protected header of a Signed Statement and a Receipt MUST include the "CWT Claims" header parameter as specified in CWT_CLAIMS_COSE. The "CWT Claims" value MUST include the "Issuer Claim" (Claim label 1) and the "Subject Claim" (Claim label 2) IANA.cwt. A Receipt is a Signed Statement, (cose-sign1), with addition claims in its protected header related to verifying the inclusion proof in its unprotected header.  See I-D.draft-ietf-cose-merkle-tree-proofs. fig-signed-statement-cddl illustrates a normative CDDL definition for of the protected header for Signed Statements and Receipts. Everything that is optional in the following CDDL can potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields.  A Registration Policy that requires an optional field to be present MUST reject any Signed Statements or Receipts that are invalid according to the policy. fig-signed-statement-edn illustrates a payload that is detached. This is to support very large supply chain artifacts, and to ensure that Transparent Statements can integrate with existing file systems. </del> There are many types of Statements (such as SBOMs, malware scans, audit reports, policy definitions) that Issuers may want to turn into Signed Statements.  An Issuer must first decide on a suitable format

Reviewer comments:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Revised text:
to allow implementations to make the restrictions that make the most sense for their operational use cases.  There are many types of Statements (such as SBOMs, malware scans, audit reports, policy definitions) that Issuers may want to turn into Signed Statements.  An Issuer must first decide on a suitable format
Original text:
Once all the Envelope headers are set, an Issuer MUST use a standard COSE implementation to produce an appropriately serialized Signed <del> Statement (the SCITT tag of "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed Statement). </del>  Issuers may produce Signed Statements about different Artifacts under the same Identity.  Issuers and Relying Parties must be able to recognize the Artifact to which the statements pertain by looking at the Signed Statement.  The "iss" and "sub" claims, within the CWT_Claims protected header, are used to identify the Artifact the <del> statement pertains to. See Subject under terminology Terminology. </del>  Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed

Reviewer comments:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Revised text:
Once all the Envelope headers are set, an Issuer MUST use a standard COSE implementation to produce an appropriately serialized Signed  <ins> Statement.  The SCITT tag "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed Statement. </ins> Issuers may produce Signed Statements about different Artifacts under the same Identity.  Issuers and Relying Parties must be able to recognize the Artifact to which the statements pertain by looking at the Signed Statement.  The "iss" and "sub" claims, within the CWT_Claims protected header, are used to identify the Artifact the  <ins> statement pertains to.  (See Subject under terminology Terminology.) </ins> Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed
Original text:
Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree.  4.2.1.  To register a Signed Statement, the Transparency Service performs the following steps:

Reviewer comments:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Revised text:
Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. <ins> At least one identifier for an identity document MUST be included in the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". Support for "x5t" is mandatory to implement. Support for "kid" and "x5chain" is optional. When "x5t" or "x5chain" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. The mechanisms for how Transparency Services obtain identity documents is out-of-scope of this document. The "kid" header parameter MUST be present when neither "x5t" nor "x5chain" are present.  Key discovery protocols are out-of-scope of this document. The protected header of a Signed Statement and a Receipt MUST include the "CWT Claims" header parameter as specified in CWT_CLAIMS_COSE. The "CWT Claims" value MUST include the "Issuer Claim" (Claim label 1) and the "Subject Claim" (Claim label 2) IANA.cwt. A Receipt is a Signed Statement, (cose-sign1), with addition claims in its protected header related to verifying the inclusion proof in its unprotected header.  See I-D.draft-ietf-cose-merkle-tree-proofs. </ins> 4.2.1. <ins> fig-signed-statement-cddl illustrates a normative CDDL definition for of the protected header for Signed Statements and Receipts. Everything that is optional in the following CDDL can potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields.  A Registration Policy that requires an optional field to be present MUST reject any Signed Statements or Receipts that are invalid according to the policy. fig-signed-statement-edn illustrates an instance of a Signed Statement in EDN, with a payload that is detached.  Detached payloads support large artifacts, and ensure Signed Statements can integrate with existing storage systems. fig-signed-statement-protected-header-edn illustrates the decoded protected header of the Signed Statement in fig-signed-statement-edn. It indicates the Signed Statement is securing a JSON content type, and identifying the content with the "sub" claim "vendor.product.example". 4.3. </ins> To register a Signed Statement, the Transparency Service performs the following steps:
Original text:
multiple receipts may be attached to the unprotected header of the Signed Statement, creating a Transparent Statement. <del> 4.3. </del>  The Client (which is not necessarily the Issuer) that registers a Signed Statement and receives a Receipt can produce a Transparent

Reviewer comments:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Revised text:
multiple receipts may be attached to the unprotected header of the Signed Statement, creating a Transparent Statement.  <ins> 4.4. </ins> The Client (which is not necessarily the Issuer) that registers a Signed Statement and receives a Receipt can produce a Transparent
Original text:
is valid, if claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid. <del> The algorithm-specific details of checking inclusion proofs are covered in I-D.draft-ietf-cose-merkle-tree-proofs.  The pseudo-code for validation of a transparent statement is as follows: Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency Services. </del> Relying Parties MAY be configured to re-verify the Issuer's Signed <del> Statement locally, but this requires a fresh resolution of the Issuer's verification keys, which MAY fail if the key has been revoked. Some Relying Parties MAY decide to locally re-apply some or all of the Registration Policies, if they have limited trust in the Transparency Services.  In addition, Relying Parties MAY apply arbitrary validation 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. Relying Parties MAY offer options to store or share the Receipt of the Transparent Statement for auditing the Transparency Services in case a dispute arises. </del>  5.

Reviewer comments:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Revised text:
is valid, if claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid.  Relying Parties MAY be configured to re-verify the Issuer's Signed  <ins> Statement locally. In addition, Relying Parties MAY apply arbitrary validation 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> 5.
Original text:
Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included <del> in the Receipt) to authenticate and retrieve the Transparent Statements describing the registration policy and trust anchors that apply to this registration. </del>  4.1.2.

Reviewer comments:
from :
MUST and "enough" does not seem suffiMay be we have to tighten up the you can retrieve the signed statement to something in the future that may only get the hashmore correct than before, still a MUST that is tad bit hard to follow. the change in this scope is okay

Revised text:
Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included  <ins> in the Receipt) to authenticate and retrieve the Signed Statements describing the registration policy and trust anchors that apply to this registration. </ins> 4.1.2.
Original text:
that is supporting a software package management system, might be referenced from the APIs exposed for package management.  Providing an ability to request a fresh receipt for a given software package, <del> or to request a list of Signed Statements and Artifacts associated with a software package. </del>  4.2.

Reviewer comments:
from :
MUST and "enough" does not seem suffiMay be we have to tighten up the you can retrieve the signed statement to something in the future that may only get the hashmore correct than before, still a MUST that is tad bit hard to follow. the change in this scope is okay

Revised text:
that is supporting a software package management system, might be referenced from the APIs exposed for package management.  Providing an ability to request a fresh receipt for a given software package,  <ins> or to request a list of Signed Statements associated with the software package. </ins> 4.2.
Original text:
Transparency Service has added this Signed Statement to its Append- only Log. <del> The WG is discussing if existing CWT claims might better support these design principles. </del> fig-transparent-statement-cddl illustrates a normative CDDL definition of Transparent Statements.

Reviewer comments:
This is how a SCITT Signed Statement associates an Issuer making a statement about an Artifact, which has been core to the draft from the start. Previously, these were properties in the protected header, aligned with DIDs: See The use of was to align with other existing standards, for how we associate these concepts. An alternative is to lift these two properties, independently, to the protected header. We already have an in the protected header for additional properties, reducing the duplicity of in the cwtclaims and protected header, potentially simplifing the model. The approach of using cwt claims allows users to benefit from existing cwt libraries, which seemed the better of the choices.
OK so the answer is yes then. I am happy with it, but this is a small, tight PR deleting the editors note, I wanted to understand the implication before I (and maybe others) understand before I approve.
Resolve Section :
LGTM

Revised text:
Transparency Service has added this Signed Statement to its Append- only Log.  fig-transparent-statement-cddl illustrates a normative CDDL definition of Transparent Statements.
Original text:
only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence.  A Receipt is an offline, universally-verifiable proof that an entry is recorded in <del> the Append-only Log.  Receipts do not expire, but it is possible to append new entries (more recent Signed Statements) that subsume older entries (less recent Signed Statements). </del>  Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent

Reviewer comments:
To facilitate this forward for submission on Monday, I'm going to merge a few changes for additional discussion/review.
Fair, could you provide a suggested change? [edit] let me elaborate: not making iat mandatory! But about the fact that extension points in Receipts can render them with an expiration date and that only in the architecture's base definition they do not expire.
After reviewing comments and the paragraph this change sits within, the merged suggestions make a minor improvement, and I don't believe rewinds any problems. While we can/should make additional improvements, can we adopt this change? NAME NAME you have blocking requests. If the merged suggestions don't resolve your concerns, can you either make an additional suggestion or comment on why this shouldn't be merged?
NAME here you go: URL
The changes that have been made to the pull request has lost somethings. The logical receipt itself does not expire. The evidence captured in the ledger is more than just the hash of the signed statement as it has to capture the tests done to the signature and the results. That evidence and where it sits in the ledger establishes a time basis for the decision. A new signature on top of that linkage to the evidence in the ledger is being equated as a whole as the receipt. The "thing" signed is the same (location into the ledger) and the only thing that has changed is possibly the identity key material and algorithm. It is this concept of "never" expiring that is important to key.
from :
Tagging NAME
NAME we'll close this in a week and can reconsider with a PR.
Referring to , the latest changes provide the flexibility for Transparency Services to maintain previous receipts and re-issue them or generate new receipts which may not be persisted. As such, I'm approving this PR as incremental progress.

Revised text:
only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence.  A Receipt is an offline, universally-verifiable proof that an entry is recorded in  <ins> the Append-only Log.  Requesting a receipt can result in the production of a new receipt for the same signed statement.  A Receipt's verification key, signing algorithm, validity period, header parameters or other claims MAY change each time a Receipt is produced. </ins> Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent