Abstract <del> This document defines the SCITT REST API, an http interface to transparency services, supporting the primary operations needed to implement the SCITT Architecture I-D.draft-ietf-scitt-architecture. </del> <ins> This document describes a REST API that supports the normative requirements of the SCITT Architecture I-D.draft-ietf-scitt- architecture.  Optional key discovery and query interfaces are provided to support interoperability issues with Decentralized Identifiers, X509 Certificates and Artifact Reposistories. </ins> 1. <del> This API definition MAY be exposed externally as part of a suite of APIs, or be encapsulated internally and exposed indirectly via proprietary APIs. </del> <ins> The SCITT Architecture I-D.draft-ietf-scitt-architecture defines the core operations necessary to support supply chain transparency using COSE (CBOR Object Signing and Encryption). </ins> <del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. 2. The SCITT REST API is designed to support identifier systems that are currently relevant to supply chains, including DID, x509 and PGP. In order to support these systems, the API must be aware of specific header parameters, in particular, "kid", "x5u" and "x5c". The API enables implementers to deploy interoperable URIs for disclosing information feeds related to supply chain actors, and artifacts accessible via transparency services. 2.1. TBD (comments on OAuth / Client Attestation). 2.2. TBD (comments on GAIN / OIDC). 2.3. TBD (comments on URLs / QR Codes). 3. 3.1. In cases where a signed statement is issued by one party and registered by another, there is a need to prove possession of key material and detect tampering while authenticating both parties. Typically a nonce would be chosen by the transparency service and the second party would sign over the nonce, when registering the first issuer's signed statement. In order to avoid interactivity and improve interoperability, document describes a non-exclusive, but mandatory to support, confirmation scheme In this scheme the verifier's challenge is a recent Unix timestamp, the presenting party need not request this information from the transparency service. Here is an example key binding token that can be paired with the confirmation claim in a signed statement: When applying registration policies to signed statements with confirmation, the transparency service acts as a verifier, and performs the following checks: verify the integrity of the issuer's signed statement confirm the verified content meets the registration policy for the transparency service. verify the key binding token, using the confirmation claim in the verified issuer signed statement ensure the key binding token has a nonce that is a string representation of a recent Unix timestamp </del> <ins> Issuance of Signed Statements </ins> <del> The exact window of validity for proving possession is a configuration detail of the transparency service.  Unix timestamps are used so that only a losely synchronised notion of time need be assumed and there is no requirement to account for timezones. </del> <ins> Verification of Signed Statements </ins> <del> If the confirmation key is stolen, the attacker can produce key binding tokens from that point forward in time.  In an interactive confirmation schema, the transparency service can force the confirmation key holder to produce a signature over a nonce that is not guessable, and this prevents certain attacks related to the duration of access to a signing capability and other timing details. However, the cost of coordinating with the transparency service, coupled with the purpose of registering with a transparency service (to obtain a receipt, proving a signed statement was acceptable at a point in time) justify specifying the recent timestamp nonce as a mandatory to implement context binding. </del> <ins> Registration of Signed Statements </ins> <del> In the case that a SCITT transparency service wants to support challenges (nonces) that are context binding, the transparency service can expose a "challenge token endpoint". </del> <ins> Issuance of Receipts </ins> <del> This endpoint can process request parameters, and issuer a challenge token, that future registrations can use to bind to the original request.  This interaction model works well for scenarios where requirements for a given registration might change over time, but it is important for the registering party to commit to acceptable values at the time that a signed statement is registered.  These endpoints are optional to implement. </del> <ins> Verification of Receipts </ins> <del> 3.1.1. </del> <ins> Production of Transparent Statements </ins> <del> 3.1.1.1. </del> <ins> Verification of Transparent Statements </ins> <del> 3.1.1.2. </del> <ins> In addition to defining concrete HTTP endpoints for these operations, this specification defines support for the following endpoints which support these operations: </ins> <del> Header: "Content-Type: application/json" </del> <ins> Resolving Verification Keys for Issuers </ins> <del> (Optional) Header: "Retry-After: <seconds>" </del> <ins> Retrieving Receipts Asynchronously </ins> <del> Query: "?intention={todo}" </del> <ins> Retrieving Signed Statements from an Artifact Repository </ins> <del> Body: "{ "token": "JWT | SD-JWT | base64url( CWT | SD-CWT )>" }" </del> <ins> Retrieving Statements from an Artifact Repository </ins> <del> 3.1.2. </del> <ins> 1.1. </ins> <del> 3.1.2.1. </del> <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> <del> Headers: </del> <ins> This specification uses the terms "Signed Statement", "Receipt", "Transparent Statement", "Artifact Repositories", "Transparency Service", "Append-Only Log" and "Registration Policy" as defined in I-D.draft-ietf-scitt-architecture. </ins> <del> "Content-Type: application/cose" </del> <ins> This specification uses "payload" as defined in RFC9052. </ins> <del> Body: SCITT COSE_Sign1 message </del> <ins> 2. </ins> <del> Note: that the challenge token MUST be present and integrity protected when submitting signed statements to this endpoint.  Note: this endpoint is a duplicate of "POST https://transparency.example/ entries" </del> <ins> Authentication is out of scope for this document.  If Authentication is not implemented, rate limiting or other denial of service mititations MUST be applied to enable anonymous access. </ins> <del> 3.2. </del> <ins> NOTE: '' line wrapping per RFC 8792 in HTTP examples. </ins> All messages are sent as HTTP GET or POST requests.