jiebi/CodeConvo huggingface dataset:
Code change:
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

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

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

Related discussion:
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> <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. <del> A collection of Transparent Statements must not leak information about the contents of other Transparent Statements registered on the Transparency Service. </del> <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,
Code change:
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

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

Related discussion:
text: 2.1.2. <del> Authentication MUST be implemented for this endpoint. </del> <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:
Code change:
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

Related discussion:
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> <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:
Code change:
Issue Exposes another issue with signed statement identifiers which is being fixed in a different PR.
LGTM

Related discussion:
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> <ins> succeeded or failed by polling the Resolve Receipt endpoint using the </ins> identifier returned in the response. 2.1.2.3.
Code change:
Issue Exposes another issue with signed statement identifiers which is being fixed in a different PR.
LGTM

Related discussion:
text: Response: <ins> 2.2.4.1. </ins> 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> <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> <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> <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.
Code change:
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

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

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

Related discussion:
text: If the Transparency Service cannot process a client's request, it MUST return an HTTP 4xx or 5xx status code, and the body SHOULD be a <del> JSON problem details object (RFC9457) containing: </del> <ins> Concise Problem Details object (RFC9290) containing: </ins> <del> type: A URI reference identifying the problem.  To facilitate </del> <ins> title: A human-readable string identifying the error that prevented the Transparency Service from processing the request, ideally short and suitable for inclusion in log messages. detail: A human-readable string describing the error in more depth, ideally with sufficient detail to enable the error to be rectified. instance: A URN reference identifying the problem.  To facilitate </ins> automated response to errors, this document defines a set of standard tokens for use in the type field within the URN namespace of: "urn:ietf:params:scitt:error:". <del> detail: A human-readable string describing the error that prevented the Transparency Service from processing the request, ideally with sufficient detail to enable the error to be rectified. </del> <ins> response-code: The HTTP error response code relating to this error. application/concise-problem-details+cbor </ins> <del> Error responses SHOULD be sent with the "Content-Type: application/ problem+json" HTTP header. </del> <ins> NOTE: SCRAPI is not a CoAP API.  Nonetheless Constrained Problem Details objects (RFC9290) provide a useful CBOR encoding for problem details and avoids the need for mixing CBOR and JSON in endpoint implementations. </ins> As an example, submitting a Signed Statement with an unsupported signature algorithm would return a "400 Bad Request" status code and
Code change:
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

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

Related discussion:
text: Response: <del> Additional fields may be present.  Fields that are not understood MUST be ignored. </del> <ins> Responses to this message are vendor-specific.  Fields that are not understood MUST be ignored. </ins> 2.1.2.
Code change:
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

Related discussion:
text: 2.1.2.3. <del> One of the following errors: TODO: other error codes </del> <ins> The following expected errors are defined.  Implementations MAY return other errors, so long as they are valid RFC9290 objects. </ins> 2.2.
Code change:
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

Related discussion:
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> <ins> Repositories, and serve Signed Statements directly, instead of </ins> indirectly through Receipts. Request: Response: <del> 2.2.3. Authentication SHOULD be implemented for this endpoint. </del> <ins> One of the following: </ins> <del> This endpoint enables Transparency Service APIs to act like Artifact Repositories, and serve Signed Statements directly, instead of indirectly through Receipts. </del> <ins> 2.2.2.1. </ins> <del> Request: </del> <ins> 2.2.2.2. </ins> <del> Response: </del> <ins> The following expected errors are defined.  Implementations MAY return other errors, so long as they are valid RFC9290 objects. </ins> <del> 2.2.4. </del> <ins> 2.2.3. </ins> Authentication SHOULD be implemented for this endpoint.
Code change:
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

Related discussion:
text: Response: <del> 2.2.4.1. </del> <ins> 2.2.3.1. </ins> If the Signed Statement requested is already included in the Append- Only Log: <del> 2.2.4.2. </del> <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: <del> 2.2.4.3. </del> <ins> 2.2.3.3. </ins> If the Signed Statement requested is neither registered in the log nor subject to an in-progress registration: <del> 2.2.4.4. </del> <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: <del> 2.2.4.5. </del> <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. <del> 2.2.5. </del> <ins> 2.2.4. </ins> This endpoint is used to exchange old or expiring receipts for fresh ones.
Code change:
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

Related discussion:
text: Request: <del> 2.2.5.1. </del> <ins> 2.2.4.1. </ins> A new receipt: <del> 2.2.6. </del> <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