Original 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>  <del> type: A URI reference identifying the problem.  To facilitate </del>  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>  <del> Error responses SHOULD be sent with the "Content-Type: application/ problem+json" HTTP header. </del>  As an example, submitting a Signed Statement with an unsupported signature algorithm would return a "400 Bad Request" status code and

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:
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  <ins> Concise Problem Details object (RFC9290) containing: </ins>  <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:".  <ins> response-code: The HTTP error response code relating to this error. application/concise-problem-details+cbor </ins>  <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