jiebi/CodeConvo huggingface dataset:
Code change:
Retains the concepts and many of the same words as before, but addresses concerns form the mailing list and interim call
I've merged in suggestions. Please re-review, with LGTM or actionable suggestions.
yesLGTM

Related discussion:
text: Transparency Services MAY support additional APIs for auditing, for instance, to query the history of Signed Statements. <del> Typically a Transparency Services has a single Issuer identity which </del> <ins> Typically a Transparency Service has a single Issuer identity which </ins> is present in the "iss" claim of Receipts for that service. Multi-tenant support can be enabled through the use of identifiers in
Code change:
Upon re-reading the draft to submit an unrelated PR, I noticed there is a missing verb in paragraph about Signed Statements.
LGTM!LGTM Thanks for the polish NAME

Related discussion:
text: 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 <del> Statements or Receipts that an invalid according to the policy. </del> <ins> Statements or Receipts that are invalid according to the policy. </ins> fig-signed-statement-edn illustrates a payload that is detached. This is to support very large supply chain artifacts, and to ensure
Code change:
While working on a unrelated PR, I noticed that lists that do not have a newline between the list and previous paragraph. The end result is in local testing, and presuming upcoming publication to URL, the lists will not render correctly. I added newlines and also change the equivalent Markdown syntax to match preexisting lists from other sections in the draft that have been around longer. Before: ! After: !
LGTM Thanks, NAME

Related discussion:
text: 4.1.1.1. Transparency Services MUST, at a minimum, perform the following <del> checks before registering a Signed Statement: * Authenticate the Issuer of the Signed Statement </del> <ins> checks before registering a Signed Statement: Authenticate the Issuer of the Signed Statement </ins> The Transparency Service MUST authenticate the Issuer of Signed Statements by validating the COSE signature and checking the identity
Code change:
While working on a unrelated PR, I noticed that lists that do not have a newline between the list and previous paragraph. The end result is in local testing, and presuming upcoming publication to URL, the lists will not render correctly. I added newlines and also change the equivalent Markdown syntax to match preexisting lists from other sections in the draft that have been around longer. Before: ! After: !
LGTM Thanks, NAME

Related discussion:
text: any Signed Statements, a means is required to configure the first Registration Policy that is not the standard issuance of a Signed Statement.  Transparency Services MUST support at least one of these <del> methods: * A built-in default Registration Policy * Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing registration checks * An out-of-band authenticated management interface </del> <ins> methods: A built-in default Registration Policy Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing registration checks An out-of-band authenticated management interface </ins> 4.1.3.
Code change:
I found another typo, to make review simple and not mix it in with a more substantive editorial PR that is pending, I am fixing this misspelling in a separate PR for review and likely approval. Correct singed->signed in Section 6.2.2.

Related discussion:
text: Signed Statements presented for Registration.  Some Transparency Services may publish every Signed Statement in their logs, to facilitate their dissemination and auditing.  Others may just return <del> Receipts to clients that present Singed Statements for Registration, </del> <ins> Receipts to clients that present Signed Statements for Registration, </ins> and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents.
Code change:
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.

Related discussion:
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> <ins> with the guarantee that all Auditors and Verifiers will be able to verify them. </ins> 1.
Code change:
Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.

Related discussion:
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> <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
Code change:
Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.

Related discussion:
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> <ins> and I-D.draft-ietf-cose-merkle-tree-proofs are out of scope for this document. </ins> 4.1.4.
Code change:
Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.

Related discussion:
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> <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.
Code change:
Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.

Related discussion:
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> <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-
Code change:
Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.

Related discussion:
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> <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 <del> covered in I-D.draft-steele-cose-merkle-tree-proofs.  The pseudo-code </del> <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
Code change:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Related discussion:
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
Code change:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Related discussion:
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
Code change:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Related discussion:
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> <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 <del> statement pertains to. See Subject under terminology Terminology. </del> <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
Code change:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Related discussion:
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:
Code change:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Related discussion:
text: multiple receipts may be attached to the unprotected header of the Signed Statement, creating a Transparent Statement. <del> 4.3. </del> <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
Code change:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Related discussion:
text: fig-transparent-statement-cddl illustrates a normative CDDL definition of Transparent Statements. <del> fig-transparent-statement-edn illustrates a payload that is detached. The unprotected header can contain multiple receipts. </del> <ins> fig-transparent-statement-edn illustrates a Transparent Statement with a detached payload, and two receipts in its unprotected header. The label 394 "receipts" in unprotected header can contain multiple receipts. </ins> <del> Notice the verifiable data structure used is RFC9162_SHA256 in this case.  We know from the COSE Verifiable Data Structure Registry that RFC9162_SHA256 is value 1, and that it supports -1 (inclusion proofs) and -2 (consistency proofs). </del> <ins> fig-receipt-edn one of the decoded Receipt from fig-transparent- statement-edn.  The Receipt contains inclusion proofs for verifiable data structures.  The unprotected header contains verifiable data structure proofs.  See the protected header for details regarding the specific verifiable data structure used.  Referencing the COSE Verifiable Data Structure Registry, RFC9162_SHA256 is value "1", which supports "-1" (inclusion proofs) and "-2" (consistency proofs). </ins> <del> Notice the unprotected header contains verifiable data structure proofs, see the protected header for details regarding the specific verifiable data structure used. </del> <ins> fig-receipt-protected-header-edn illustrates the decoded protected header of the Transparent Statement in fig-transparent-statement-edn. The verifiable data structure ("-111") uses "1" from (RFC9162_SHA256). </ins> <del> This is a decoded inclusion proof for RFC9162_SHA256, other verifiable data structures might encode inclusion proofs differently. </del> <ins> fig-receipt-inclusion-proof-edn illustrates the decoded inclusion proof from fig-receipt-edn.  This inclusion proof indicates that the size of the transparency log was "8" at the time the receipt was issued.  The structure of this inclusion proof is specific to the verifiable data structure used (RFC9162_SHA256). </ins> <del> 4.3.1. </del> <ins> 4.4.1. </ins> Relying Parties MUST apply the verification process as described in <del> Section 4.4 of RFC9052. </del> <ins> Section 4.4 of RFC9052, when checking the signature of Signed Statements and Receipts. A Relying Party MUST trust the verification key or certificate and the associated identity of at least one issuer of a Receipt. A Relying Party MAY decide to verify only a single Receipt that is acceptable to them, and not check the signature on the Signed Statement or Receipts which rely on verifiable data structures which they do not understand. </ins> APIs exposing verification logic for Transparent Statements may provide more details than a single boolean result.  For example, an
Code change:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

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

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

Related discussion:
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> <ins> or to request a list of Signed Statements associated with the software package. </ins> 4.2.
Code change:
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

Related discussion:
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.