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> <ins> 2.1. </ins> <del> 3.2.1.1. </del> <ins> The following HTTP endpoints are mandatory to implement to enable conformance to this specification. </ins> <del> Headers: </del> <ins> 2.1.1. </ins> <del> "Content-Type: application/cose" </del> <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> <del> Body: SCITT COSE_Sign1 message </del> <ins> Request: </ins> <del> 3.2.1.2. </del> <ins> Response: </ins> <del> One of the following: </del> <ins> Additional fields may be present.  Fields that are not understood MUST be ignored. </ins> <del> Status 201 - Registration is successful. </del> <ins> 2.1.2. </ins> <del> Header "Location: <Base URL>/entries/<Entry ID>" </del> <ins> Authentication MUST be implemented for this endpoint. </ins> <del> Header "Content-Type: application/json" </del> <ins> The following is a non-normative example of a HTTP request to register a Signed Statement: </ins> <del> Body "{ "entryId": "<Entry ID"> }" </del> <ins> Request: </ins> <del> Status 202 - Registration is running. </del> <ins> The Registration Policy for the Transparency Service MUST be applied to the payload bytes, before any additional processing is performed. </ins> <del> Header "Location: <Base URL>/operations/<Operation ID>" </del> <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> <del> Header "Content-Type: application/json" </del> <ins> If registration succeeds the following identifier MAY be used to refer to the Signed Statement that was accepted: </ins> <del> (Optional) Header: "Retry-After: <seconds>" </del> <ins> "urn:ietf:params:scitt:signed-statement:sha- 256:base64url:5i6UeRzg1...qnGmr1o" </ins> <del> Body "{ "operationId": "<Operation ID>", "status": "running" }" </del> <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> <del> Status 400 - Registration was unsuccessful due to invalid input. </del> <ins> "urn:ietf:params:scitt:statement:sha- 256:base64url:5i6UeRzg1...qnGmr1o" </ins> <del> Error code "badSignatureAlgorithm" </del> <ins> Response: </ins> <del> TBD: more error codes to be defined </del> <ins> One of the following: </ins> <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> <ins> 2.1.2.1. </ins> <del> 3.2.2. </del> <ins> The response contains the Receipt for the Signed Statement.  Fresh receipts may be requested through the resource identified in the Location header. </ins> <del> 3.2.2.1. </del> <ins> 2.1.2.2. </ins> <del> 3.2.2.2. </del> <ins> The response contains a reference to the receipt which will eventually be available for the Signed Statement. </ins> <del> One of the following: </del> <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> <del> Status 200 - Registration is running </del> <ins> 2.1.2.3. </ins> <del> Header: "Content-Type: application/json" </del> <ins> One of the following errors: </ins> <del> (Optional) Header: "Retry-After: <seconds>" </del> <ins> TODO: other error codes </ins> <del> Body: "{ "operationId": "<Operation ID>", "status": "running" }" </del> <ins> 2.2. </ins> <del> Status 200 - Registration was successful </del> <ins> The following HTTP endpoints are optional to implement. </ins> <del> Header: "Location: <Base URL>/entries/<Entry ID>" </del> <ins> 2.2.1. </ins> <del> Header: "Content-Type: application/json" </del> <ins> Authentication MUST be implemented for this endpoint. </ins> <del> Body: "{ "operationId": "<Operation ID>", "status": "succeeded", "entryId": "<Entry ID>" }" </del> <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> <del> Status 200 - Registration failed </del> <ins> Request: </ins> <del> Header "Content-Type: application/json" </del> <ins> Response: </ins> <del> Body: "{ "operationId": "<Operation ID>", "status": "failed", "error": { "type": "<type>", "detail": "<detail>" } }" </del> <ins> 2.2.2. </ins> <del> Error code: "badSignatureAlgorithm" </del> <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> <del> Status 404 - Unknown Operation ID </del> <ins> Response: </ins> <del> Error code: "operationNotFound" </del> <ins> 2.2.3. </ins> <del> This can happen if the operation ID has expired and been deleted. </del> <ins> Authentication SHOULD be implemented for this endpoint. </ins> <del> If an operation failed, then error details SHOULD be embedded as a JSON problem details object in the ""error"" field. </del> <ins> This endpoint enables Transparency Service APIs to act like Artifact Repositories, and serve Signed Statements directly, instead of indirectly through Receipts. </ins> <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> <ins> Request: </ins> <del> 3.2.3. </del> <ins> Response: </ins> <del> 3.2.3.1. </del> <ins> 2.2.4. </ins> <del> Query parameters: </del> <ins> Authentication SHOULD be implemented for this endpoint. </ins> <del> (Optional) "embedReceipt=true" </del> <ins> Request: </ins> <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> <ins> Response: </ins> <del> 3.2.3.2. </del> <ins> If the Signed Statement requested is already included in the Append- Only Log: </ins> <del> One of the following: </del> <ins> If the Signed Statement requested is not yet included in the Append- Only Log: </ins> <del> Status 200. </del> <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> <del> Header: "Content-Type: application/cose" </del> <ins> 2.2.5. </ins> <del> Body: COSE_Sign1 </del> <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> <del> Status 404 - Entry not found. </del> <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> <del> Error code: "entryNotFound" </del> <ins> Request: </ins> <del> 3.2.4. </del> <ins> Response: </ins> <del> 3.2.4.1. </del> <ins> 2.2.6. </ins> <del> 3.2.4.2. </del> <ins> This endpoint in inspired by I-D.draft-demarco-oauth-nonce-endpoint. </ins> <del> One of the following: </del> <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> <del> Status 200. </del> <ins> Request: </ins> <del> Header: "Content-Type: application/cbor" </del> <ins> Response: </ins> <del> Body: SCITT_Receipt </del> <ins> 2.2.7. </ins> <del> Status 404 - Entry not found. </del> <ins> This endpoint enables the use of the DID Web Decentralized Identifier Method, as an alternative expression of the Issuer Metadata endpoint. </ins> <del> Error code: "entryNotFound" </del> <ins> This endpoint is DEPRECATED. </ins> <del> The retrieved Receipt may be embedded in the corresponding COSE_Sign1 document in the unprotected header. </del> <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> <del> 4. </del> <ins> Request: Response: 3. </ins> TODO <del> 5. </del> <ins> 4. </ins> TODO <del> 6. </del> <ins> TODO: Consider negotiation for receipt as "JSON" or "YAML".  TODO: Consider impact of media type on "Data URIs" and QR Codes. 5. </ins> <del> 6.1. </del> <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: <del> 6.2. </del> <ins> 5.2. </ins> <del> TODO: Register them from here. </del> <ins> The following value is requested to be registered in the "Well-Known URIs" registry (using the template from RFC5785): </ins> <del> 6.3. </del> <ins> URI suffix: issuer Change controller: IETF Specification document(s): RFCthis.  Related information: N/A </ins> <del> For discovering scitt configuration. </del> <ins> 5.3. </ins> <del> TODO: Register them from here. </del> <ins> The following value is requested to be registered in the "Well-Known URIs" registry (using the template from RFC5785): </ins> <del> 6.4. </del> <ins> URI suffix: transparency-configuration Change controller: IETF Specification document(s): RFCthis.  Related information: N/A </ins> <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> <ins> TODO: Register them from here. </ins> <del> TODO: Consider negotiation for receipt as "JSON" or "YAML".  TODO: Consider impact of media type on "Data URIs" and QR Codes. </del> <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 <del> Subtype name: receipt+cose </del> <ins> Subtype name: scitt.receipt+cose </ins> Required parameters: n/a