jiebi/TextFlow huggingface dataset:
Original text:
encoding SHOULD be employed for the JSON object. Security considerations: See the Security Considerations section <del> of [[ this specification ]]. </del>  Interoperability considerations: n/a <del> Published specification: [[ this specification ]] </del>  Applications that use this media type: TBD

Reviewer comments:
This PR addresses: URL Related issues: URL
Some additional details on the construction and use can be found here: URL I'm not including these in the PR, because I don't understand the security properties required by "SCITT Identifiers", but if the code I wrote covers the security properties, I am happy to do a follow up PR, after this one is merged.
LGTM for the consistency of CBOR structures

Revised text:
encoding SHOULD be employed for the JSON object. Security considerations: See the Security Considerations section  <ins> of TBD. </ins> Interoperability considerations: n/a  <ins> Published specification: TBD </ins> Applications that use this media type: TBD
Original text:
enforcing a Registration Policy.  It also maintains a service key, which is used to endorse the state of the Append-only Log in Receipts.  All Transparency Services MUST expose standard endpoints <del> for Registration of Signed Statements and Receipt issuance, which is described in TODO: scrapi.  Each Transparency Service also defines its own Registration Policies, which MUST apply to all entries in the Append-only Log. </del>  The combination of Identity, Registration Policy evaluation, and the Transparency Service endpoint constitute the trusted part of the

Reviewer comments:
This is a simple dependency management PR to decouple SCRAPI from the architecture spec. See SCRAPI can be a layer above, and reference the architecture (dependency) as in HTTP implementation. Decoupling allows us to move forward with the architecture doc, continuing to iterate on SCRAPI independently.

Revised text:
enforcing a Registration Policy.  It also maintains a service key, which is used to endorse the state of the Append-only Log in Receipts.  All Transparency Services MUST expose standard endpoints  <ins> for Registration of Signed Statements and Receipt issuance.  Each Transparency Service also defines its own Registration Policies, which MUST apply to all entries in the Append-only Log. </ins> The combination of Identity, Registration Policy evaluation, and the Transparency Service endpoint constitute the trusted part of the
Original text:
5.1.3.  SCITT payloads are opaque to Transparency Services.  For interoperability, Registration Policy decisions should be based on interpretation of the mandatory metadata in the protected header of a

Reviewer comments:
Looking at URL, I think a that some more diverse examples later that show how multiple statements about one Artifact using the same sub Claim can have different semantics than multiple statements about one Artifact using different sub Claims - including illustrating text when one choice can be used an when the other & pros and cons.
Covered above
LGTM

Revised text:
5.1.3. <ins> An Issuer can make multiple Statements about the same Artifact.  For example, an Issuer can make amended Statements about the same Artifact as their view changes over time. Multiple Issuers can make different, even conflicting Statements, about the same Artifact.  Verifiers can choose which Issuers they trust. Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. 5.1.4. </ins> SCITT payloads are opaque to Transparency Services.  For interoperability, Registration Policy decisions should be based on interpretation of the mandatory metadata in the protected header of a
Original text:
are capitalized.  To ensure readability, only a core set of terms is included in this section.  4. In this document, the definition of transparency is intended to build

Reviewer comments:
Explains Feed as the logical collection, with (Subject) as the property to represent the collection.
That seems pretty reasonable to me. Are there any reasons to keep both?
While I'd agree less is more, this keeps coming back when we try to explain it. A feed is a known concept for a collection of related data We're using CWTClaims , which also makes sense to align with existing specs We avoided Artifact ID Attempting to describe a collection of statements as a subject doesn't resonate. We can keep Feed as the concept, and simply say CWTClaims is how you set an identifier for the feed. How does that work?
Then we should deprecate the term feed in discussions, too, and just explain how a subject is used as a subject in this context?
Updated to merge in PR feedback
NAME NAME NAME PTAL as I've made some updates.

Revised text:
are capitalized.  To ensure readability, only a core set of terms is included in this section. <ins> Verifiers use the Feed to ensure completeness and Non-equivocation in supply chain evidence by identifying all Transparent Statements linked to the Artifact they are evaluating. </ins> 4. In this document, the definition of transparency is intended to build
Original text:
are capitalized.  To ensure readability, only a core set of terms is included in this section.  4. In this document, the definition of transparency is intended to build

Reviewer comments:
!
The diagram reflects my intention.
Here's a slightly modified view to remove the lines behind, add arrows consistenty !

Revised text:
are capitalized.  To ensure readability, only a core set of terms is included in this section. <ins> The terms "header", "payload", and "to-be-signed bytes" are defined in RFC9052. </ins> 4. In this document, the definition of transparency is intended to build
Original text:
are capitalized.  To ensure readability, only a core set of terms is included in this section. <del> Verifiers use the Feed to ensure completeness and Non-equivocation in supply chain evidence by identifying all Transparent Statements linked to the Artifact they are evaluating. </del> 4. In this document, the definition of transparency is intended to build

Reviewer comments:
Reverts ietf-wg-scitt/draft-ietf-scitt-architecture

Revised text:
are capitalized.  To ensure readability, only a core set of terms is included in this section.  4. In this document, the definition of transparency is intended to build
Original text:
CT logs produce Signed Certificate Timestamps (Transparent Statements) <del> SCTs are checked by browsers (Verifiers) </del>  <del> The Append-only Log can be checked by Auditors Note that just like CT logs are independent and their contents need not be consistent, Transparency Services are similarly independent of each other. </del>  3.

Reviewer comments:
A set of consistency fixes for the next draft.
See URL for discussion on the terminology.
The doc uses the three interchangeably Is there a preferred reference to be consistent?
URL is about Media Type. And then references payload and content type. I've been through this confusion before, where Media Type is the definition of a type of identifier. The challenge becomes when using that type of identifier for different parts of a document. When does the media type refer to the envelope itself? When does the media type refer to a property (aka payload)?
I don't understand the question. is of content type and . It is generally a good idea to use a more specific media type. The payload of a cose-sign1 can have a media type, such as or .
It cuts out cruft, so I support this edit, just one minor nit (take or leave it, it's minor to me), before moving onto .

Revised text:
CT logs produce Signed Certificate Timestamps (Transparent Statements)  <ins> Signed Certificate Timestamps are checked by Verifiers. </ins>  <ins> The Append-only Log can be checked by Verifiers and Auditors </ins> 3.
Original text:
Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent <del> Statements registered by each Issuer.  However, the Registrations of </del>  separate Transparency Services are generally disjoint, though it is <del> possible to take a Transparent Statement from one Transparency Service and register it again on another (if its policy allows), so the authorization of the Issuer and of the Transparency Service by the Verifier of the Receipt are generally independent. </del>  Reputable Issuers are thus incentivized to carefully review their Statements before signing them to produce Signed Statements.

Reviewer comments:
Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this

Revised text:
Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent  <ins> Statements registered by each Issuer.  However, the Registrations on </ins> separate Transparency Services are generally disjoint, though it is  <ins> possible to take a Transparent Statement, a Signed Statement with a Receipt from the first Transparency Service in its unprotected header, and register it on another Transparency Service, where the second receipt will be over the first Receipt in the unprotected header. </ins> Reputable Issuers are thus incentivized to carefully review their Statements before signing them to produce Signed Statements.
Original text:
7. <del> : This topic is still under discussion, see issue 79 [2] </del>  Multiple, independently-operated Transparency Services can help secure distributed supply chains, without the need for a single,

Reviewer comments:
Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this

Revised text:
7.  <ins> : This topic is still under discussion, see issue 79 [1] </ins> Multiple, independently-operated Transparency Services can help secure distributed supply chains, without the need for a single,
Original text:
use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement.  9.1. SCITT provides the following security guarantees:

Reviewer comments:
Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this

Revised text:
use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement. <ins> Each of these functions MUST be carefully protected against both external attacks and internal misbehavior by some or all of the operators of the Transparency Service. For instance, the code for the Registration Policy evaluation and endorsement may be protected by running in a Trusted Execution Environment (TEE). The Transparency Service may be replicated with a consensus algorithm, such as Practical Byzantine Fault Tolerance (pBFT PBFT) and may be used to protect against malicious or vulnerable replicas. Threshold signatures may be use to protect the service key, etc. </ins> 9.1. SCITT provides the following security guarantees:
Original text:
11.1.  URIs <del> [1] https://www.iana.org/assignments/cwt/cwt.xhtml#claims-registry [2] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ </del>  issues/79

Reviewer comments:
Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this

Revised text:
11.1.  URIs  <ins> [1] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ </ins> issues/79
Original text:
Change Controller: IETF Provisional registration?  No <del> 9.  References 9.1.  URIs [1] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ issues/79 </del>

Reviewer comments:
In case there is no rough consensus to keep federation section, I raised URL to remove it.
I'd suggest we've had a few different conversations about federation of everything in a transparency service, vs. selective promotion of a subset of information across Transparency Services. The later being the ability for a consumer of one or more Transparency Services to promote the content for a subset of their software. Microsoft ships lots of software, However a consumer may only want to promote the Office suite of products into their Transparency Service for internal validation. I'd suggest the wording, as current, isn't well defined and I'd vote to cut this section until more well defined.
If this PR is dropped then we should create an issue to address the underspecification of unpotected headers at registration, especially the idea to preserve unprotected headers. Federation is a simple use case that highlights this problem
Its not simple, and we have seen no implementation support for it to date.
If we are at the point where we need to start from scratch on configuration/registration policy and scrap the initialization section, I personally do not see how we can keep federation and not just remove it (not to drive you and others mad, we can always add back later).I think the new text is too specific. To me (and as in the prior text) Federation refers to having multiple TS, and one TS accepting receipts from another TS at registration time is just an advanced case, for which we don't have clarity yet. As discussed earlier, letting the TS decide what unprotected headers to authenticate in its receipts is a major complication. My preference would be (1) keep a general placeholder on Federation --- better than nothing; or else (2) cut the section. But this leaves many questions unanswered, starting with the two TS in the arch diagram.

Revised text:
Change Controller: IETF Provisional registration?  No
Original text:
4.1. <del> An important function of a Transparency Service is to maintain Registration Policies for the Append-only Log.  The Append-only Log is the verifiable data structure which registers Signed Statements and supports the production of Receipts. </del>  All Transparency Services MUST expose APIs for the registration of Signed Statements and issuance of Receipts.

Reviewer comments:
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

Revised text:
4.1.  <ins> Transparency Services MUST feature an Append-only Log.  The Append- only Log is the verifiable data structure that registers Signed Statements and supports the production of Receipts. </ins> All Transparency Services MUST expose APIs for the registration of Signed Statements and issuance of Receipts.
Original 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>  is present in the "iss" claim of Receipts for that service. Multi-tenant support can be enabled through the use of identifiers in

Reviewer comments:
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

Revised text:
Transparency Services MAY support additional APIs for auditing, for instance, to query the history of Signed Statements.  <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
Original 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>  fig-signed-statement-edn illustrates a payload that is detached. This is to support very large supply chain artifacts, and to ensure

Reviewer comments:
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

Revised 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  <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
Original 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>  The Transparency Service MUST authenticate the Issuer of Signed Statements by validating the COSE signature and checking the identity

Reviewer comments:
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

Revised text:
4.1.1.1. Transparency Services MUST, at a minimum, perform the following  <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
Original 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>  4.1.3.

Reviewer comments:
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

Revised 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  <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.
Original 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>  and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents.

Reviewer comments:
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.

Revised 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  <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.