jiebi/TextFlow huggingface dataset:
Original text:
Error code: "entryNotFound" The retrieved Receipt may be embedded in the corresponding COSE_Sign1 <del> document in the unprotected header, see draft-birkholz-scitt-receipts (TODO [1]: replace with final reference). </del>  9.

Reviewer comments:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Revised text:
Error code: "entryNotFound" The retrieved Receipt may be embedded in the corresponding COSE_Sign1  <ins> document in the unprotected header. </ins> 9.
Original text:
Repository: http://www.iana.org/assignments/scitt Index value: No transformation needed. <del> 12.  References 12.1.  URIs [1] more error codes to be defined, see [#17](https://github.com/ ietf-wg-scitt/draft-ietf-scitt-architecture/issues/17) </del>

Reviewer comments:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Revised text:
Repository: http://www.iana.org/assignments/scitt Index value: No transformation needed.
Original text:
in how each Transparency Service is implemented and operates.  Each service MAY enforce its own Registration Policy for authorizing entities to register their Signed Statements to the append-only Log. <del> Some Transparency Services may also enforce role based access control (RBAC) policies limiting who can write, read and audit specific Feeds or the full Registry.  It is critical to provide interoperability for all Transparency Services instances as the composition and configuration of involved supply chain entities and their system components is ever-changing and always in flux. </del>  A Transparency Services provides visibility into Signed Statements associated with various supply chains and their sub-systems.  These

Reviewer comments:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Revised text:
in how each Transparency Service is implemented and operates.  Each service MAY enforce its own Registration Policy for authorizing entities to register their Signed Statements to the append-only Log.  <ins> Some Transparency Services may also enforce authorization policies limiting who can write, read and audit specific Feeds or the full registry.  It is critical to provide interoperability for all Transparency Services instances as the composition and configuration of involved supply chain entities and their system components is ever-changing and always in flux. </ins> A Transparency Services provides visibility into Signed Statements associated with various supply chains and their sub-systems.  These
Original text:
Signed Statement about an Artifact.  Issuers may Register new Signed Statements about Artifacts, but they cannot delete or alter Signed Statements previously added to the append-only Log.  A Transparency <del> Service may restrict access to Signed Statements through Role Based Access Control, however third parties such as Auditors would be </del>  granted access as needed to attest to the validity of the Artifact, <del> Feed or entirety of the Transparency Service. </del>  Trust in the Transparency Service itself is supported both by protecting their implementation (using, for instance, replication,

Reviewer comments:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Revised text:
Signed Statement about an Artifact.  Issuers may Register new Signed Statements about Artifacts, but they cannot delete or alter Signed Statements previously added to the append-only Log.  A Transparency  <ins> Service may restrict access to Signed Statements through access control policies.  However, third parties (such as Auditors) would be </ins> granted access as needed to attest to the validity of the Artifact,  <ins> Feed or the entirety of the Transparency Service. </ins> Trust in the Transparency Service itself is supported both by protecting their implementation (using, for instance, replication,
Original text:
The SCITT architecture consists of a very loose federation of Transparency Services, and a set of common formats and protocols for <del> issuing, registering and auditing Transparent Statements. </del>  In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed

Reviewer comments:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Revised text:
The SCITT architecture consists of a very loose federation of Transparency Services, and a set of common formats and protocols for  <ins> issuing, registering Signed Statements and auditing Transparent Statements. </ins> In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed
Original text:
Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle-tree- proofs. <del> In this section, a high level the three main roles and associated processes in SCITT: Issuers and the Signed Statement issuance process, transparency Registry and the Transparent Statement Registration process, as well as Verifiers and the Receipt validation process. </del>  5.1.

Reviewer comments:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Revised text:
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 issuance process, Transparency Service and the Signed Statement Registration process, as well as Verifiers of the Transparent Statements and the Receipt validation process. </ins> 5.1.
Original text:
Beyond the trusted components, Transparency Services may operate additional endpoints for auditing, for instance to query for the <del> history of Transparent Statements registered by a given Issuer via a </del>  certain Feed.  Implementations of Transparency Services SHOULD avoid using the service identity and extending the Registry in auditing endpoints; as much as practical, the Registry SHOULD contain enough

Reviewer comments:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Revised text:
Beyond the trusted components, Transparency Services may operate additional endpoints for auditing, for instance to query for the  <ins> history of Signed Statements registered by a given Issuer via a </ins> certain Feed.  Implementations of Transparency Services SHOULD avoid using the service identity and extending the Registry in auditing endpoints; as much as practical, the Registry SHOULD contain enough
Original text:
the Transparency Service Registration Policy and that has been persisted in the Registry.  Unless advertised in the Transparency Service Registration Policy, the Verifier should not assume that the <del> ordering of Transparent Statements in the Registry matches the ordering of their issuance. </del>  Similarly, the fact that an Issuer can be held accountable for its Transparent Statements does not on its own provide any mitigation or

Reviewer comments:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Revised text:
the Transparency Service Registration Policy and that has been persisted in the Registry.  Unless advertised in the Transparency Service Registration Policy, the Verifier should not assume that the  <ins> ordering of Signed Statements in the Registry matches the ordering of their issuance. </ins> Similarly, the fact that an Issuer can be held accountable for its Transparent Statements does not on its own provide any mitigation or
Original text:
10.1.1.1. If a Transparency Service is honest, then a Transparent Statement <del> including a correct Receipt ensures that the Transparent 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

Reviewer comments:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Revised text:
10.1.1.1. If a Transparency Service is honest, then a Transparent Statement  <ins> including a correct Receipt ensures that the associated Signed Statement passed its Registration Policy and was recorded appropriately. </ins> Conversely, a corrupt Transparency Service may 1. refuse or delay the Registration of Signed Statements, 2. register Signed Statements that
Original text:
Due to the operational challenge of maintaining a globally consistent append-only Log, some Transparency Services may provide limited <del> support for historical queries on the Transparent Statements they have registered, and accept the risk of being blamed for inconsistent </del>  Registration or Issuer equivocation. Verifier and Auditors may also witness (1,4) but may not be able to

Reviewer comments:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Revised text:
Due to the operational challenge of maintaining a globally consistent append-only Log, some Transparency Services may provide limited  <ins> support for historical queries on the Signed Statements they have registered, and accept the risk of being blamed for inconsistent </ins> Registration or Issuer equivocation. Verifier and Auditors may also witness (1,4) but may not be able to
Original text:
The Transparency Service is trusted with the confidentiality of the Signed Statements presented for Registration.  Some Transparency <del> Services may publish every Transparent Statement in their logs, to </del>  facilitate their dissemination and auditing.  Others may just return Receipts to clients that present Singed Statements for Registration, and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents. <del> A collection of Transparent Statements must not leak information about the contents of other Transparent Statements registered on the Transparency Service. </del>  Nonetheless, Issuers should carefully review the inclusion of private/confidential materials in their Statements.  For example,

Reviewer comments:
NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later

Revised text:
The Transparency Service is trusted with the confidentiality of the Signed Statements presented for Registration.  Some Transparency  <ins> Services may publish every Signed Statement in their logs, to </ins> facilitate their dissemination and auditing.  Others may just return Receipts to clients that present Singed Statements for Registration, and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents.  <ins> A collection of Signed Statements must not leak information about the contents of other Signed Statements registered on the Transparency Service. </ins> Nonetheless, Issuers should carefully review the inclusion of private/confidential materials in their Statements.  For example,
Original text:
Repository: http://www.iana.org/assignments/scitt Index value: No transformation needed. 

Reviewer comments:
This PR attempts to address the problem of documenting the various ways that known key content types, such as and are discovered from opaque strings or URIs such as and . This PR also explains how DIDs are similar to OIDC.
I have a working demo of this on URL, URL URL Its also possible to do same thing with did methods other than , for example ... There is a demo of that working with index db here: URL This shows that there is interoperability across issuers that use different did methods, that conform to the same resolution and dereferencing interfaces.
made comments, but I think a bit more discussion/work is needed.Asked Kristina to also look at this.a proposal for discussion @ IETF 117 Hackathon and meeting seems very useful to me. :+1: LGTM to merge as a baseline for future discussion

Revised text:
Repository: http://www.iana.org/assignments/scitt Index value: No transformation needed. <ins> 12.  References 12.1.  URIs [1] https://datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in- headers/ </ins>
Original text:
2.1.2. <del> Authentication MUST be implemented for this endpoint. </del>  The following is a non-normative example of a HTTP request to register a Signed Statement:

Reviewer comments:
Issue Also harmonize title with other endpoints
In the case of a government end point, why must client authentication be implemented. The signature on the statement is the authentication for the content and is ultimately who is making a reputation statement.
Agreed. In addition to this I think there are several places where we need to clean up seemingly helpful implementation comments which are actually harmful. For instance the mention of using auth for rate limiting is a fine thing to say but it's nothing to do with SCITT and will be done in other layers by any sensible implementation.
Resolved by
On internal or truly public instances this could be MAY

Revised text:
2.1.2.  <ins> Authentication MAY be implemented for this endpoint.  See notes on detached payloads below. </ins> The following is a non-normative example of a HTTP request to register a Signed Statement:
Original text:
If the "payload" is detached, the Transparency Service depends on the authentication context of the client in the Registration Policy.  If the "payload" is attached, the Transparency Service depends on both <del> the authentication context of the client, and the verification of the Signed Statement in the Registration Policy.  The details of Registration Policy are out of scope for this document. </del>  If registration succeeds the following identifier MAY be used to refer to the Signed Statement that was accepted:

Reviewer comments:
Issue Also harmonize title with other endpoints
In the case of a government end point, why must client authentication be implemented. The signature on the statement is the authentication for the content and is ultimately who is making a reputation statement.
Agreed. In addition to this I think there are several places where we need to clean up seemingly helpful implementation comments which are actually harmful. For instance the mention of using auth for rate limiting is a fine thing to say but it's nothing to do with SCITT and will be done in other layers by any sensible implementation.
Resolved by
On internal or truly public instances this could be MAY

Revised text:
If the "payload" is detached, the Transparency Service depends on the authentication context of the client in the Registration Policy.  If the "payload" is attached, the Transparency Service depends on both  <ins> the authentication context of the client (if present), and the verification of the Signed Statement in the Registration Policy.  The details of Registration Policy are out of scope for this document. </ins> If registration succeeds the following identifier MAY be used to refer to the Signed Statement that was accepted:
Original text:
eventually be available for the Signed Statement. If 202 is returned, then clients should wait until Registration <del> succeeded or failed by polling the receipt endpoint using the receipt </del>  identifier returned in the response. 2.1.2.3.

Reviewer comments:
Issue Exposes another issue with signed statement identifiers which is being fixed in a different PR.
LGTM

Revised text:
eventually be available for the Signed Statement. If 202 is returned, then clients should wait until Registration  <ins> succeeded or failed by polling the Resolve Receipt endpoint using the </ins> identifier returned in the response. 2.1.2.3.
Original text:
Response:  If the Signed Statement requested is already included in the Append- Only Log: <del> If the Signed Statement requested is not yet included in the Append- Only Log: </del>  <del> Additional eventually consistent operation details MAY be present. Support for eventually consistent Receipts is implementation specific, and out of scope for this specification. </del>  2.2.5.

Reviewer comments:
Issue Exposes another issue with signed statement identifiers which is being fixed in a different PR.
LGTM

Revised text:
Response: <ins> 2.2.4.1. </ins> If the Signed Statement requested is already included in the Append- Only Log:  <ins> 2.2.4.2. If registration of the Signed Statement requested is in progress but not yet included in the Append-Only Log: 2.2.4.3. If the Signed Statement requested is neither registered in the log nor subject to an in-progress registration: 2.2.4.4. If a client is polling for an in-progress registration too frequently then the Transparency Service MAY, in addition to implementing rate- limiting, return a 429 response: 2.2.4.5. </ins>  <ins> For all responses additional eventually consistent operation details MAY be present.  Support for eventually consistent Receipts is implementation specific, and out of scope for this specification. </ins> 2.2.5.
Original text:
2.1.1. <del> Authentication SHOULD NOT be implemented for this endpoint.  This endpoint is used to discovery the capabilities of a transparency service implementing this specification. </del>  Request:

Reviewer comments:
Issue
In the case of a government end point, why must client authentication be implemented. The signature on the statement is the authentication for the content and is ultimately who is making a reputation statement.
Agreed. In addition to this I think there are several places where we need to clean up seemingly helpful implementation comments which are actually harmful. For instance the mention of using auth for rate limiting is a fine thing to say but it's nothing to do with SCITT and will be done in other layers by any sensible implementation.
Resolved by
The optional API endpoints have intent statements that outline the goal of the Endpoints for example 2.2.1 (Issue Signed Statement Endpoint) has this intent statement: Such a statement is currently missing from both: (Transparency Configuration) and 2.1.2 (Signed Statement Registration).
I'll take this one and put a PR up with consistency for all the endpoints
This was fixed in
LGTM

Revised text:
2.1.1.  <ins> Authentication SHOULD NOT be implemented for this endpoint. This endpoint is used to discover the capabilities and current configuration of a transparency service implementing this specification. </ins> Request: