Original text:
to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum. <del> 3.2.1. </del>  <del> 3.2.1.1. </del>  <del> Headers: </del>  <del> "Content-Type: application/cose" </del>  <del> Body: SCITT COSE_Sign1 message </del>  <del> 3.2.1.2. </del>  <del> One of the following: </del>  <del> Status 201 - Registration is successful. </del>  <del> Header "Location: <Base URL>/entries/<Entry ID>" </del>  <del> Header "Content-Type: application/json" </del>  <del> Body "{ "entryId": "<Entry ID"> }" </del>  <del> Status 202 - Registration is running. </del>  <del> Header "Location: <Base URL>/operations/<Operation ID>" </del>  <del> Header "Content-Type: application/json" </del>  <del> (Optional) Header: "Retry-After: <seconds>" </del>  <del> Body "{ "operationId": "<Operation ID>", "status": "running" }" </del>  <del> Status 400 - Registration was unsuccessful due to invalid input. </del>  <del> Error code "badSignatureAlgorithm" </del>  <del> TBD: more error codes to be defined </del>  <del> If 202 is returned, then clients should wait until Registration succeeded or failed by polling the Registration status using the Operation ID returned in the response.  Clients should always obtain a Receipt as a proof that Registration has succeeded. </del>  <del> 3.2.2. </del>  <del> 3.2.2.1. </del>  <del> 3.2.2.2. </del>  <del> One of the following: </del>  <del> Status 200 - Registration is running </del>  <del> Header: "Content-Type: application/json" </del>  <del> (Optional) Header: "Retry-After: <seconds>" </del>  <del> Body: "{ "operationId": "<Operation ID>", "status": "running" }" </del>  <del> Status 200 - Registration was successful </del>  <del> Header: "Location: <Base URL>/entries/<Entry ID>" </del>  <del> Header: "Content-Type: application/json" </del>  <del> Body: "{ "operationId": "<Operation ID>", "status": "succeeded", "entryId": "<Entry ID>" }" </del>  <del> Status 200 - Registration failed </del>  <del> Header "Content-Type: application/json" </del>  <del> Body: "{ "operationId": "<Operation ID>", "status": "failed", "error": { "type": "<type>", "detail": "<detail>" } }" </del>  <del> Error code: "badSignatureAlgorithm" </del>  <del> Status 404 - Unknown Operation ID </del>  <del> Error code: "operationNotFound" </del>  <del> This can happen if the operation ID has expired and been deleted. </del>  <del> If an operation failed, then error details SHOULD be embedded as a JSON problem details object in the ""error"" field. </del>  <del> If an operation ID is invalid (i.e., it does not correspond to any submit operation), a service may return either a 404 or a "running" status.  This is because differentiating between the two may not be possible in an eventually consistent system. </del>  <del> 3.2.3. </del>  <del> 3.2.3.1. </del>  <del> Query parameters: </del>  <del> (Optional) "embedReceipt=true" </del>  <del> If the query parameter "embedReceipt=true" is provided, then the Signed Statement is returned with the corresponding Registration Receipt embedded in the COSE unprotected header. </del>  <del> 3.2.3.2. </del>  <del> One of the following: </del>  <del> Status 200. </del>  <del> Header: "Content-Type: application/cose" </del>  <del> Body: COSE_Sign1 </del>  <del> Status 404 - Entry not found. </del>  <del> Error code: "entryNotFound" </del>  <del> 3.2.4. </del>  <del> 3.2.4.1. </del>  <del> 3.2.4.2. </del>  <del> One of the following: </del>  <del> Status 200. </del>  <del> Header: "Content-Type: application/cbor" </del>  <del> Body: SCITT_Receipt </del>  <del> Status 404 - Entry not found. </del>  <del> Error code: "entryNotFound" </del>  <del> The retrieved Receipt may be embedded in the corresponding COSE_Sign1 document in the unprotected header. </del>  <del> 4. </del>  TODO <del> 5. </del>  TODO <del> 6. </del>  <del> 6.1. </del>  IANA is requested to register the URN sub-namespace "urn:ietf:params:scitt" in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" Registry IANA.params, following the template in RFC3553: <del> 6.2. </del>  <del> TODO: Register them from here. </del>  <del> 6.3. </del>  <del> For discovering scitt configuration. </del>  <del> TODO: Register them from here. </del>  <del> 6.4. </del>  <del> This section requests registration of the "application/receipt+cose" media type RFC2046 in the "Media Types" registry in the manner described in RFC6838. </del>  <del> TODO: Consider negotiation for receipt as "JSON" or "YAML".  TODO: Consider impact of media type on "Data URIs" and QR Codes. </del>  To indicate that the content is a SCITT Receipt: Type name: application <del> Subtype name: receipt+cose </del>  Required parameters: n/a

Reviewer comments:
This PR updates SCRAPI to match the latest version of the architecture.
I tried pushing a revision to the datatracker from my fork... but it did not work... so unless this is published by some other author with write access before monday, we will be -00 for a solid IETF with no updates : )
Merging based on requests to meet the draft cut off... assuming CI passes
:ship: itWe should get this up ASAP before the cutoff and prior to hackathon

Revised text:
to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum.  <ins> 2.1. </ins>  <ins> The following HTTP endpoints are mandatory to implement to enable conformance to this specification. </ins>  <ins> 2.1.1. </ins>  <ins> Authentication SHOULD NOT be implemented for this endpoint.  This endpoint is used to discovery the capabilites of a transparency service implementing this specification. </ins>  <ins> Request: </ins>  <ins> Response: </ins>  <ins> Additional fields may be present.  Fields that are not understood MUST be ignored. </ins>  <ins> 2.1.2. </ins>  <ins> Authentication MUST be implemented for this endpoint. </ins>  <ins> The following is a non-normative example of a HTTP request to register a Signed Statement: </ins>  <ins> Request: </ins>  <ins> The Registration Policy for the Transparency Service MUST be applied to the payload bytes, before any additional processing is performed. </ins>  <ins> 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 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. </ins>  <ins> If registration succeeds the following identifier MAY be used to refer to the Signed Statement that was accepted: </ins>  <ins> "urn:ietf:params:scitt:signed-statement:sha- 256:base64url:5i6UeRzg1...qnGmr1o" </ins>  <ins> If the "payload" was attached, or otherwise communicated to the Transparency Service, the following identifier MAY be used to refer to the "payload" of the Signed Statement: </ins>  <ins> "urn:ietf:params:scitt:statement:sha- 256:base64url:5i6UeRzg1...qnGmr1o" </ins>  <ins> Response: </ins>  <ins> One of the following: </ins>  <ins> 2.1.2.1. </ins>  <ins> The response contains the Receipt for the Signed Statement.  Fresh receipts may be requested through the resource identified in the Location header. </ins>  <ins> 2.1.2.2. </ins>  <ins> The response contains a reference to the receipt which will eventually be available for the Signed Statement. </ins>  <ins> If 202 is returned, then clients should wait until Registration succeeded or failed by polling the receipt endpoint using the receipt identifier returned in the response. </ins>  <ins> 2.1.2.3. </ins>  <ins> One of the following errors: </ins>  <ins> TODO: other error codes </ins>  <ins> 2.2. </ins>  <ins> The following HTTP endpoints are optional to implement. </ins>  <ins> 2.2.1. </ins>  <ins> Authentication MUST be implemented for this endpoint. </ins>  <ins> This endpoint enables a Transparency Service to be an issuer of Signed Statements on behalf of authenticated clients.  This supports cases where a client lacks the ability to perform complex cryptographic operations, but can be authenticated and report statements and measurements. </ins>  <ins> Request: </ins>  <ins> Response: </ins>  <ins> 2.2.2. </ins>  <ins> Authentication SHOULD be implemented for this endpoint. This endpoint enables Transparency Service APIs to act like Artifact Repositories, and serve "payload" values directly, instead of indirectly through Receipts. Request: </ins>  <ins> Response: </ins>  <ins> 2.2.3. </ins>  <ins> Authentication SHOULD be implemented for this endpoint. </ins>  <ins> This endpoint enables Transparency Service APIs to act like Artifact Repositories, and serve Signed Statements directly, instead of indirectly through Receipts. </ins>  <ins> Request: </ins>  <ins> Response: </ins>  <ins> 2.2.4. </ins>  <ins> Authentication SHOULD be implemented for this endpoint. </ins>  <ins> Request: </ins>  <ins> Response: </ins>  <ins> If the Signed Statement requested is already included in the Append- Only Log: </ins>  <ins> If the Signed Statement requested is not yet included in the Append- Only Log: </ins>  <ins> Additional eventually consistent operation details MAY be present. Support for eventually consistent Receipts is implementation specific, and out of scope for this specification. </ins>  <ins> 2.2.5. </ins>  <ins> This endpoint is inspired by I-D.draft-ietf-oauth-sd-jwt-vc. Authentication SHOULD NOT be implemented for this endpoint.  This endpoint is used to discover verification keys, which is the reason that authentication is not required. </ins>  <ins> The following is a non-normative example of a HTTP request for the Issuer Metadata configuration when "iss" is set to "https://transparency.example/tenant/1234": </ins>  <ins> Request: </ins>  <ins> Response: </ins>  <ins> 2.2.6. </ins>  <ins> This endpoint in inspired by I-D.draft-demarco-oauth-nonce-endpoint. </ins>  <ins> Authentication SHOULD NOT be implemented for this endpoint.  This endpoint is used to demonstrate proof of posession, 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. </ins>  <ins> Request: </ins>  <ins> Response: </ins>  <ins> 2.2.7. </ins>  <ins> This endpoint enables the use of the DID Web Decentralized Identifier Method, as an alternative expression of the Issuer Metadata endpoint. </ins>  <ins> This endpoint is DEPRECATED. </ins>  <ins> The following is a non-normative example of a HTTP request for the Issuer Metadata configuration when "iss" is set to "did:web:transparency.example:tenant:1234": </ins>  <ins> Request: Response: 3. </ins> TODO  <ins> 4. </ins> TODO  <ins> TODO: Consider negotiation for receipt as "JSON" or "YAML".  TODO: Consider impact of media type on "Data URIs" and QR Codes. 5. </ins>  <ins> 5.1. </ins> IANA is requested to register the URN sub-namespace "urn:ietf:params:scitt" in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" Registry IANA.params, following the template in RFC3553:  <ins> 5.2. </ins>  <ins> The following value is requested to be registered in the "Well-Known URIs" registry (using the template from RFC5785): </ins>  <ins> URI suffix: issuer Change controller: IETF Specification document(s): RFCthis.  Related information: N/A </ins>  <ins> 5.3. </ins>  <ins> The following value is requested to be registered in the "Well-Known URIs" registry (using the template from RFC5785): </ins>  <ins> URI suffix: transparency-configuration Change controller: IETF Specification document(s): RFCthis.  Related information: N/A </ins>  <ins> TODO: Register them from here. </ins>  <ins> 5.4. This section requests registration of the "application/ scitt.receipt+cose" media type RFC2046 in the "Media Types" registry in the manner described in RFC6838. </ins> To indicate that the content is a SCITT Receipt: Type name: application  <ins> Subtype name: scitt.receipt+cose </ins> Required parameters: n/a