jiebi/TextFlow huggingface dataset:
Original text:
Authentication MAY be implemented for this endpoint.  See notes on detached payloads below.  The following is a non-normative example of a HTTP request to register a Signed Statement:

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:
Authentication MAY be implemented for this endpoint.  See notes on detached payloads below. <ins> This endpoint is used to register a Signed Statement with a Transparency Service. </ins> The following is a non-normative example of a HTTP request to register a Signed Statement:
Original text:
Clients SHOULD treat 500 and 503 HTTP status code responses as transient failures and MAY retry the same request without <del> modification at a later date.  Note that in the case of a 503 response, the Transparency Service MAY include a "Retry-After" header field per RFC9110 in order to request a minimum time for the client to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum. </del>  2.1.

Reviewer comments:
Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM

Revised text:
Clients SHOULD treat 500 and 503 HTTP status code responses as transient failures and MAY retry the same request without  <ins> modification at a later date. Note that in the case of any error response, the Transparency Service MAY include a "Retry-After" header field per RFC9110 in order to request a minimum time for the client to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum. </ins> 2.1.
Original text:
Response: <del> Additional fields may be present.  Fields that are not understood MUST be ignored. </del>  2.1.2.

Reviewer comments:
Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM

Revised text:
Response:  <ins> Responses to this message are vendor-specific.  Fields that are not understood MUST be ignored. </ins> 2.1.2.
Original text:
2.1.2.3. <del> One of the following errors: TODO: other error codes </del>  2.2.

Reviewer comments:
Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM

Revised text:
2.1.2.3.  <ins> The following expected errors are defined.  Implementations MAY return other errors, so long as they are valid RFC9290 objects. </ins> 2.2.
Original text:
Authentication SHOULD be implemented for this endpoint. This endpoint enables Transparency Service APIs to act like Artifact <del> Repositories, and serve "payload" values directly, instead of </del>  indirectly through Receipts. Request: Response: <del> 2.2.3. Authentication SHOULD be implemented for this endpoint. </del>  <del> This endpoint enables Transparency Service APIs to act like Artifact Repositories, and serve Signed Statements directly, instead of indirectly through Receipts. </del>  <del> Request: </del>  <del> Response: </del>  <del> 2.2.4. </del>  Authentication SHOULD be implemented for this endpoint.

Reviewer comments:
Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM

Revised text:
Authentication SHOULD be implemented for this endpoint. This endpoint enables Transparency Service APIs to act like Artifact  <ins> Repositories, and serve Signed Statements directly, instead of </ins> indirectly through Receipts. Request: Response:  <ins> One of the following: </ins>  <ins> 2.2.2.1. </ins>  <ins> 2.2.2.2. </ins>  <ins> The following expected errors are defined.  Implementations MAY return other errors, so long as they are valid RFC9290 objects. </ins>  <ins> 2.2.3. </ins> Authentication SHOULD be implemented for this endpoint.
Original text:
Response: <del> 2.2.4.1. </del>  If the Signed Statement requested is already included in the Append- Only Log: <del> 2.2.4.2. </del>  If registration of the Signed Statement requested is in progress but not yet included in the Append-Only Log: <del> 2.2.4.3. </del>  If the Signed Statement requested is neither registered in the log nor subject to an in-progress registration: <del> 2.2.4.4. </del>  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: <del> 2.2.4.5. </del>  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. <del> 2.2.5. </del>  This endpoint is used to exchange old or expiring receipts for fresh ones.

Reviewer comments:
Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM

Revised text:
Response:  <ins> 2.2.3.1. </ins> If the Signed Statement requested is already included in the Append- Only Log:  <ins> 2.2.3.2. </ins> If registration of the Signed Statement requested is in progress but not yet included in the Append-Only Log:  <ins> 2.2.3.3. </ins> If the Signed Statement requested is neither registered in the log nor subject to an in-progress registration:  <ins> 2.2.3.4. </ins> 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:  <ins> 2.2.3.5. </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.4. </ins> This endpoint is used to exchange old or expiring receipts for fresh ones.
Original text:
Request: <del> 2.2.5.1. </del>  A new receipt: <del> 2.2.6. </del>  This endpoint is inspired by I-D.draft-ietf-oauth-sd-jwt-vc. Authentication SHOULD NOT be implemented for this endpoint.  This

Reviewer comments:
Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM

Revised text:
Request:  <ins> 2.2.4.1. </ins> A new receipt:  <ins> 2.2.5. </ins> This endpoint is inspired by I-D.draft-ietf-oauth-sd-jwt-vc. Authentication SHOULD NOT be implemented for this endpoint.  This
Original text:
Response: <del> 2.2.7. </del>  This endpoint in inspired by I-D.draft-demarco-oauth-nonce-endpoint.

Reviewer comments:
Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM

Revised text:
Response:  <ins> 2.2.6. </ins> This endpoint in inspired by I-D.draft-demarco-oauth-nonce-endpoint.
Original text:
Response: <del> 2.2.6. This endpoint in inspired by I-D.draft-demarco-oauth-nonce-endpoint. Authentication SHOULD NOT be implemented for this endpoint.  This endpoint is used to demonstrate proof of possession, which is the reason that authentication is not required.  Client holding signed statements that require demonstrating proof of possession MUST use this endpoint to obtain a nonce. Request: Response: </del> 3. TODO

Reviewer comments:
It's not clear why this would be needed, and it doesn't reflect any patterns in the Architecture. Remove?
NAME there's a reference to "proof of possession", so my guess it that this is meant to enable a flow where the client requests a nonce, includes it in the signed statement (protected header or payload) before signing and submission, to "prove" that they held the key at the time of submission, if it is substantially different from the time of signing. I agree that this should be removed because: It's poorly specified for its stated purpose, without mandatory transport-level security, it's possible to effectively DoS a client by using the nonce they requested quicker than they can. Without authentication, a malicious client can also spam the service for fresh nonce values, causing legitimate ones to fall out of the expiry window before they can be used. There is no mention of a scenario where this is helpful or necessary. If such a scenario emerges, where an issuer signs or has signed indiscriminately in advance, and it is desirable to be stricter about what can be made transparent, there are two easier mechanisms the registration policy can use that don't require an awkward stateful API extension such as this: in the signed statement a counter-signature with a submission control key (which may or may not be the same as one of the issuer keys) Neither requires additional API surface, nor creates additional DoS opportunities. Opened
agree to remove. I believe the intent for including that was the cnf claim in a cwt. But per URL it is for the protocol to define if and how a nonce should be used. Removing this does not preclude the use of cnf. And, at the same time, avoids under (or over) specifying in the wrong place.
Agree I don't believe this endpoint is necessaryLGTM

Revised text:
Response:  3. TODO
Original text:
URI suffix: issuer Change controller: IETF Specification document(s): RFCthis.  Related information: N/A <del> 5.3. </del>  The following value is requested to be registered in the "Well-Known URIs" registry (using the template from RFC5785):

Reviewer comments:
Hackathon entry for 119, fill in required elements from RFC 3552
I merged the markdown nits, but left the suggestions that should be reviewed by others.
A bunch of Markdown Nits, and some questions on the correlation between Issuer and RBAC, but happy to merge and iterate through additional PRs

Revised text:
URI suffix: issuer Change controller: IETF Specification document(s): RFCthis.  Related information: N/A  <ins> 6.3. </ins> The following value is requested to be registered in the "Well-Known URIs" registry (using the template from RFC5785):
Original text:
TODO: Register them from here. <del> 5.4. </del>  This section requests registration of the "application/ scitt.receipt+cose" media type RFC2046 in the "Media Types" registry

Reviewer comments:
Hackathon entry for 119, fill in required elements from RFC 3552
I merged the markdown nits, but left the suggestions that should be reviewed by others.
A bunch of Markdown Nits, and some questions on the correlation between Issuer and RBAC, but happy to merge and iterate through additional PRs

Revised text:
TODO: Register them from here.  <ins> 6.4. </ins> This section requests registration of the "application/ scitt.receipt+cose" media type RFC2046 in the "Media Types" registry
Original text:
SCITT architecture focuses on ensuring statement authenticity, visibility/transparency, and intends to provide scalable accessibility.  The following use case illustrates the scope of SCITT <del> and elaborate on the generic problem statement above. </del>  3.

Reviewer comments:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Revised text:
SCITT architecture focuses on ensuring statement authenticity, visibility/transparency, and intends to provide scalable accessibility.  The following use case illustrates the scope of SCITT  <ins> and elaborates on the generic problem statement above. </ins> 3.
Original text:
3.2. <del> In IT industry it is a common practice that once a software product is released, it is evaluated on various aspects.  For example, an auditing company, a code review company or a government body will examine the software product and issue authoritative reports about the product.  The end users (consumers or distribution entities) use these report to make an accurate assessment as to whether the software product is deemed fit to use. </del>  There are multiple such authoritative bodies that make such assessments.  There is no assurance that all the bodies may be aware of statements from other authoritative entities or actively acknowledge them.  Discovery of all sources of such reports and/or <del> identity of the authoritative bodies adds a significant cost to the </del>  end user or consumer of the product. A consumer of released software product wants:

Reviewer comments:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Revised text:
3.2.  <ins> In the IT industry it is a common practice that once a software product is released, it is evaluated on various aspects.  For example, an auditing company, a code review company or a government body will examine the software product and issue authoritative reports about the product.  The end users (consumers or distribution entities) use these report to make an accurate assessment as to whether the software product is deemed fit to use. </ins> There are multiple such authoritative bodies that make such assessments.  There is no assurance that all the bodies may be aware of statements from other authoritative entities or actively acknowledge them.  Discovery of all sources of such reports and/or  <ins> identities of the authoritative bodies adds a significant cost to the </ins> end user or consumer of the product. A consumer of released software product wants:
Original text:
entities to an entity who does it on their behalf to offload the burden to filter from and select all statements <del> that are applicable to a particular release of a multi release </del>  software product, to an entity who does this on their behalf to make an informed decisions on which authoritative entities to

Reviewer comments:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Revised text:
entities to an entity who does it on their behalf to offload the burden to filter from and select all statements  <ins> that are applicable to a particular version of a multi release </ins> software product, to an entity who does this on their behalf to make an informed decisions on which authoritative entities to
Original text:
statement on how to mitigate the vulnerability.  At first, the producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that <del> inhibits exploitation.  Later, A second update of the software </del>  product includes a security patch to the affected software component <del> from the software producer.  Finally, A third update includes a new </del>  release (updated version) of the formerly insecure software component.  For this release, both the software product and the affected software component are deemed secure by the producer and

Reviewer comments:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Revised text:
statement on how to mitigate the vulnerability.  At first, the producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that  <ins> inhibits exploitation.  Later, a second update of the software </ins> product includes a security patch to the affected software component  <ins> from the software producer.  Finally, a third update includes a new </ins> release (updated version) of the formerly insecure software component.  For this release, both the software product and the affected software component are deemed secure by the producer and