jiebi/TextFlow huggingface dataset:
Original text:
The value of "id" might be found the "iss" or "sub" claims if they are present in the protected header or payload. <del> "resolve = (id: string, accept: content_type = 'application/ did+json') => idDocument (of content type application/did+json).  " </del> For example: <del> "did:example:123 " </del> Might resolve to: <del> "{ "id": "did:example:123", "verificationMethod": [{ "id": "#key-42", "type": "JsonWebkey", "controller": "did:example:123", "publicKeyJwk": { "kty": "EC", "crv": "P-384", "alg": "ES384", "x": "LCeAt2sW36j94wuFP0gNEIHDzqR6Nh_Udu2ObLer3cKFBCaAHY1svmbPV69bP3RH", "y": "zz2SkcOGYM6PbYlw19tcbpzo6bEMYHIwGBnN5rd8QWykAprstPdxx4U0uScvDcYd" } }] } " </del> Editor note, we might wish to eliminate this intermediate identity document content type, by treating it as an alterative encoding of "application/jwk-set+json" or "application/cose-key-set".

Reviewer comments:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Revised text:
The value of "id" might be found the "iss" or "sub" claims if they are present in the protected header or payload.  For example:  Might resolve to:  Editor note, we might wish to eliminate this intermediate identity document content type, by treating it as an alterative encoding of "application/jwk-set+json" or "application/cose-key-set".
Original text:
See also draft-ietf-cose-cwt-claims-in-headers [1]. <del> "dereference = (id: string, accept: content_type = 'application/ jwk+json') => publicKeyJwk (of content type application/jwk+json).  " </del> For example, when DIDs are used: <del> "did:example:123#key-42 " </del> Might dereference to: <del> "{ "kty": "EC", "crv": "P-384", "alg": "ES384", "x": "LCeAt2sW36j94wuFP0gNEIHDzqR6Nh_Udu2ObLer3cKFBCaAHY1svmbPV69bP3RH", "y": "zz2SkcOGYM6PbYlw19tcbpzo6bEMYHIwGBnN5rd8QWykAprstPdxx4U0uScvDcYd" } " </del> 5.1.2. Many Issuers issue Signed Statements about different Artifacts under

Reviewer comments:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Revised text:
See also draft-ietf-cose-cwt-claims-in-headers [1].  For example, when DIDs are used:  Might dereference to:  5.1.2. Many Issuers issue Signed Statements about different Artifacts under
Original text:
ts_identifier: The DID of the Transparency Service that issued the Receipt.  Verifiers MAY use this DID as a key discovery mechanism to verify the Receipt; in this case the verification is the same <del> as for Signed Statment and the signer MAY include the "kid" header parameter.  Verifiers MUST support the "did:web" method, all other methods are optional. </del>  We also introduce the following requirements for the COSE signature of the Merkle Root: The SCITT version header MUST be included and its value match the <del> "version" field of the Receipt stucture. </del>  The DID of issuer header (like in Signed Statements) MUST be included and its value match the "ts_identifier" field of the

Reviewer comments:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Revised text:
ts_identifier: The DID of the Transparency Service that issued the Receipt.  Verifiers MAY use this DID as a key discovery mechanism to verify the Receipt; in this case the verification is the same  <ins> as for Signed Statement and the signer MAY include the "kid" header parameter.  Verifiers MUST support the "did:web" method, all other methods are optional. </ins> We also introduce the following requirements for the COSE signature of the Merkle Root: The SCITT version header MUST be included and its value match the  <ins> "version" field of the Receipt structure. </ins> The DID of issuer header (like in Signed Statements) MUST be included and its value match the "ts_identifier" field of the
Original text:
Error code: "badSignatureAlgorithm"  Status 404 - Unknown Operation ID

Reviewer comments:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Revised text:
Error code: "badSignatureAlgorithm" <ins> TODO: more error codes to be defined, see #17 [4] </ins> Status 404 - Unknown Operation ID
Original text:
Statement passed its Registration Policy and was recorded appropriately. <del> Conversely, a corrupt Transparency Service may 1. refuse or delay the Registration of Signed Statements, 2. register Signed Statements that do not pass its Registration Policy (e.g., Signed Statement with Issuer identities and signatures that do not verify), 3. issue verifiable Receipts for Signed Statements that do not match its Registry, or 4. refuse access to its Registry (e.g., to Auditors, possibly after storage loss). </del>  An Auditor granted (partial) access to a Registry and to a collection of disputed Receipts will be able to replay it, detect any invalid

Reviewer comments:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Revised text:
Statement passed its Registration Policy and was recorded appropriately.  <ins> Conversely, a corrupt Transparency Service may refuse or delay the Registration of Signed Statements, register Signed Statements that do not pass its Registration Policy (e.g., Signed Statement with Issuer identities and signatures that do not verify), issue verifiable Receipts for Signed Statements that do not match its Registry, or refuse access to its Registry (e.g., to Auditors, possibly after storage loss). </ins> An Auditor granted (partial) access to a Registry and to a collection of disputed Receipts will be able to replay it, detect any invalid
Original text:
[3] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ issues/17 

Reviewer comments:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Revised text:
[3] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ issues/17 <ins> [4] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ issues/17 </ins>
Original text:
by enforcing the following complementary security guarantees: Statements made by Issuers about supply chain Artifacts must be <del> identifiable, authentic, and non-repudiable; </del>  <del> such Statements must be registered on a secure append-only Log, so </del>  that their provenance and history can be independently and <del> consistently audited; </del>  Issuers can efficiently prove to any other party the Registration of their Signed Statements; verifying this proof ensures that the Issuer is consistent and non-equivocal when producing Signed <del> Statements. </del>  The first guarantee is achieved by requiring Issuers to sign their Statements and associated metadata using a distributed public key

Reviewer comments:
This PR is intended to update URL as the current version has broken codeblock formatting and no longer reflects the current state of the draft URL URL URL URL URL
I looked through the changes and they are fine. Thanks for fixing the over-long lines in the examples.

Revised text:
by enforcing the following complementary security guarantees: Statements made by Issuers about supply chain Artifacts must be  <ins> identifiable, authentic, and non-repudiable </ins>  <ins> Such Statements must be registered on a secure append-only Log, so </ins> that their provenance and history can be independently and  <ins> consistently audited </ins> Issuers can efficiently prove to any other party the Registration of their Signed Statements; verifying this proof ensures that the Issuer is consistent and non-equivocal when producing Signed  <ins> Statements </ins> The first guarantee is achieved by requiring Issuers to sign their Statements and associated metadata using a distributed public key
Original text:
JSON encoding. Registration Policy info (label: "TBD", temporary: "393"): A map <del> of additional attributes to help enforce Registration Policies. </del>  Key ID (label: "4"): Key ID, as a bytestring.

Reviewer comments:
Good clarification, with a few nits to reduce and clarify the text
All edits have been addressed. I believe this is ready for merging.
Thanks, NAME Sounds like we can address this suggestion separately and we can merge this as-is
For the next submission deadline, RegInfo needs more detail to convey it's purpose. Maybe... it may even need a new name, as RegInfo might not be limited to key/value pairs about registration policy?
LGTMI would prefer "The key/value pair semantics are application-specific, or even possibly specified by each Issuer for each of their Feed." but I am fine with both formulations. Thanks.

Revised text:
JSON encoding. Registration Policy info (label: "TBD", temporary: "393"): A map  <ins> containing key/value pairs set by the Issuer which are sealed on Registration and non-opaque to the Transparency Service.  The key/ value pair semantics are specified by each Issuer or are specific to the Issuer and Feed tuple.  Examples include: the sequence number of signed statements on a feed, Issuer metadata, or a reference to other transparent statements (e.g., augments, replaces, new-version, CPE-for). </ins> Key ID (label: "4"): Key ID, as a bytestring.
Original text:
<del> : organizations, stakeholders, and users involved in creating or </del>  attesting to supply chain artifacts, releasing authentic Statements to a definable set of peers

Reviewer comments:
LGTM, Thanks, NAME the stakeholders to consumers looks like a great change. I don't know if we'd keep both, or replace. I'll merge this to keep moving forward. Also, thanks for the catch on CBOR

Revised text:
 <ins> : organizations, consumers, and users involved in creating or </ins> attesting to supply chain artifacts, releasing authentic Statements to a definable set of peers
Original text:
The interoperability guaranteed by the Transparency Services is enabled via core components (architectural constituents).  Many of the data elements processed by the core components are based on the <del> Concise Signing and Encryption (COSE) standard specified in RFC9052, </del>  which is used to produce Signed Statements about Artifacts and to build and maintain a Merkle tree that functions as an Append-only Log for corresponding Signed Statements.

Reviewer comments:
LGTM, Thanks, NAME the stakeholders to consumers looks like a great change. I don't know if we'd keep both, or replace. I'll merge this to keep moving forward. Also, thanks for the catch on CBOR

Revised text:
The interoperability guaranteed by the Transparency Services is enabled via core components (architectural constituents).  Many of the data elements processed by the core components are based on the  <ins> CBOR Signing and Encryption (COSE) standard specified in RFC9052, </ins> which is used to produce Signed Statements about Artifacts and to build and maintain a Merkle tree that functions as an Append-only Log for corresponding Signed Statements.
Original text:
the data elements processed by the core components are based on the CBOR Signing and Encryption (COSE) standard specified in RFC9052, which is used to produce Signed Statements about Artifacts and to <del> build and maintain a Merkle tree that functions as an Append-only Log for corresponding Signed Statements. </del>  1.1.

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

Revised text:
the data elements processed by the core components are based on the CBOR Signing and Encryption (COSE) standard specified in RFC9052, which is used to produce Signed Statements about Artifacts and to  <ins> build and maintain an Append-only Log for corresponding Signed Statements. </ins> 1.1.
Original 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>  This section describes at a high level, the three main roles and associated processes in SCITT: Issuers and the Signed Statement

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

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

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

Revised 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  <ins> a Signed Inclusion Proof. </ins> It is possible to offer multiple signature algorithms for the COSE  <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.
Original 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> 

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

Revised text:
6.4. When a Signed Statement is registered by a Transparency Service a  <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>
Original 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>  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>  Verifiers MAY offer options to store or share the Receipt of the Transparent Statement for auditing the Transparency Services in case

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

Revised text:
Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency  <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  <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
Original 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>  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>  8.

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

Revised text:
This may involve registering the same Signed Statements at different Transparency Services, each with their own purpose and Registration  <ins> Policy. This may also involve attaching multiple Receipts to the same Signed </ins> Statements.  <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.