Internet DRAFT - draft-ietf-scitt-scrapi

draft-ietf-scitt-scrapi







SCITT                                                        H. Birkholz
Internet-Draft                                            Fraunhofer SIT
Intended status: Standards Track                               O. Steele
Expires: 5 September 2024                                      Transmute
                                                               J. Geater
                                                         DataTrails Inc.
                                                            4 March 2024


                          SCITT Reference APIs
                       draft-ietf-scitt-scrapi-01

Abstract

   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.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-scitt-scrapi/.

   Discussion of this document takes place on the SCITT Working Group
   mailing list (mailto:scitt@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/scitt/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/scitt/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-scitt/draft-ietf-scitt-scrapi.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.






Birkholz, et al.        Expires 5 September 2024                [Page 1]

Internet-Draft                   SCRAPI                       March 2024


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Mandatory . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.1.  Transparency Configuration  . . . . . . . . . . . . .   5
       2.1.2.  Signed Statement Registration . . . . . . . . . . . .   6
     2.2.  Optional Endpoints  . . . . . . . . . . . . . . . . . . .   9
       2.2.1.  Issue Statement . . . . . . . . . . . . . . . . . . .  10
       2.2.2.  Resolve Statement . . . . . . . . . . . . . . . . . .  11
       2.2.3.  Resolve Signed Statement  . . . . . . . . . . . . . .  11
       2.2.4.  Resolve Receipt . . . . . . . . . . . . . . . . . . .  12
       2.2.5.  Resolve Issuer  . . . . . . . . . . . . . . . . . . .  13
       2.2.6.  Request Nonce . . . . . . . . . . . . . . . . . . . .  14
       2.2.7.  Resolve Issuer DID  . . . . . . . . . . . . . . . . .  15
   3.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  17
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     5.1.  URN Sub-namespace for SCITT (urn:ietf:params:scitt) . . .  17
     5.2.  Well-Known URI for Issuers  . . . . . . . . . . . . . . .  17
     5.3.  Well-Known URI for Transparency Configuration . . . . . .  18
     5.4.  Media Type Registration . . . . . . . . . . . . . . . . .  18
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20



Birkholz, et al.        Expires 5 September 2024                [Page 2]

Internet-Draft                   SCRAPI                       March 2024


1.  Introduction

   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).

   *  Issuance of Signed Statements

   *  Verification of Signed Statements

   *  Registration of Signed Statements

   *  Issuance of Receipts

   *  Verification of Receipts

   *  Production of Transparent Statements

   *  Verification of Transparent Statements

   In addition to defining concrete HTTP endpoints for these operations,
   this specification defines support for the following endpoints which
   support these operations:

   *  Resolving Verification Keys for Issuers

   *  Retrieving Receipts Asynchronously

   *  Retrieving Signed Statements from an Artifact Repository

   *  Retrieving Statements from an Artifact Repository

1.1.  Terminology

   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.

   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].

   This specification uses "payload" as defined in [RFC9052].





Birkholz, et al.        Expires 5 September 2024                [Page 3]

Internet-Draft                   SCRAPI                       March 2024


2.  Endpoints

   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.

   NOTE: '' line wrapping per RFC 8792 in HTTP examples.

   All messages are sent as HTTP GET or POST requests.

   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
   JSON problem details object ([RFC7807]) containing:

   *  type: A URI reference identifying the problem.  To facilitate
      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:".

   *  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.

   Error responses SHOULD be sent with the Content-Type: application/
   problem+json HTTP header.

   As an example, submitting a Signed Statement with an unsupported
   signature algorithm would return a 400 Bad Request status code and
   the following body:

   {
     "type": "urn:ietf:params:scitt:error:badSignatureAlgorithm",
     "detail": "Signing algorithm not support"
   }

   Most error types are specific to the type of request and are defined
   in the respective subsections below.  The one exception is the
   "malformed" error type, which indicates that the Transparency Service
   could not parse the client's request because it did not comply with
   this document:

   *  Error code: malformed (The request could not be parsed).

   Clients SHOULD treat 500 and 503 HTTP status code responses as
   transient failures and MAY retry the same request without
   modification at a later date.  Note that in the case of a 503
   response, the Transparency Service MAY include a Retry-After header



Birkholz, et al.        Expires 5 September 2024                [Page 4]

Internet-Draft                   SCRAPI                       March 2024


   field per [RFC7231] 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.

2.1.  Mandatory

   The following HTTP endpoints are mandatory to implement to enable
   conformance to this specification.

2.1.1.  Transparency Configuration

   Authentication SHOULD NOT be implemented for this endpoint.  This
   endpoint is used to discovery the capabilites of a transparency
   service implementing this specification.

   Request:

   GET /.well-known/transparency-configuration HTTP/1.1
   Host: transparency.example
   Accept: application/json

   Response:





























Birkholz, et al.        Expires 5 September 2024                [Page 5]

Internet-Draft                   SCRAPI                       March 2024


   HTTP/1.1 200 Ok
   Content-Type: application/json

   {
     "issuer": "https://transparency.example",
     "registration_endpoint": "https://transparency.example/entries",
     "nonce_endpoint": "https://transparency.example/nonce",

     "registration_policy": \
   "https://transparency.example\
   /statements/urn:ietf:params:scitt:statement\
   :sha-256:base64url:5i6UeRzg1...qnGmr1o",

     "supported_signature_algorithms": ["ES256"],
     "jwks": {
       "keys": [
         {
           "kid": "urn:ietf:params:oauth:\
   jwk-thumbprint:sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo",
           "alg": "ES256",
           "use": "sig",
           "kty": "EC",
           "crv": "P-256",
           "x": "p-kZ4uOASt9IjQRTrWikGnlbGb-z3LU1ltwRjZaOS9w",
           "y": "ymXE1yltJPXgjQSRe9NweN3TLlSUALYZTzy83NVfdg0"
         },
         {
           "kid": "urn:ietf:params:oauth:\
   jwk-thumbprint:sha-256:4Fzx5HO1W0ob9CZNc3RJx28Ixpgy9JAFM8jyXKW0ClE",
           "alg": "HPKE-Base-P256-SHA256-AES128GCM",
           "use": "enc",
           "kty": "EC",
           "crv": "P-256",
           "x": "Vreuil95vzR6ixutgBBf2ota-rj97MvKfuJWB4qqp5w",
           "y": "NkUTeaoNlLRRsVRxHGDA-RsA0ex2tSpcd3G-4SmKXbs"
         }
       ]
     }
   }

   Additional fields may be present.  Fields that are not understood
   MUST be ignored.

2.1.2.  Signed Statement Registration

   Authentication MUST be implemented for this endpoint.





Birkholz, et al.        Expires 5 September 2024                [Page 6]

Internet-Draft                   SCRAPI                       March 2024


   The following is a non-normative example of a HTTP request to
   register a Signed Statement:

   Request:

   POST /entries HTTP/1.1
   Host: transparency.example
   Accept: application/json
   Content-Type: application/cose
   Payload (in CBOR diagnostic notation)

   18([                            / COSE Sign1         /
     h'a1013822',                  / Protected Header   /
     {},                           / Unprotected Header /
     null,                         / Detached Payload   /
     h'269cd68f4211dffc...0dcb29c' / Signature          /
   ])

   The Registration Policy for the Transparency Service MUST be applied
   to the payload bytes, before any additional processing is performed.

   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.

   If registration succeeds the following identifier MAY be used to
   refer to the Signed Statement that was accepted:

   urn:ietf:params:scitt:signed-statement:sha-
   256:base64url:5i6UeRzg1...qnGmr1o

   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:

   urn:ietf:params:scitt:statement:sha-256:base64url:5i6UeRzg1...qnGmr1o

   Response:

   One of the following:

2.1.2.1.  Status 201 - Registration is successful






Birkholz, et al.        Expires 5 September 2024                [Page 7]

Internet-Draft                   SCRAPI                       March 2024


   HTTP/1.1 201 Ok

   Location: https://transparency.example/receipts\
   /urn:ietf:params:scitt:signed-statement\
   :sha-256:base64url:5i6UeRzg1...qnGmr1o

   Content-Type: application/cose

   Payload (in CBOR diagnostic notation)

   18([                            / COSE Sign1         /
     h'a1013822',                  / Protected Header   /
     {},                           / Unprotected Header /
     null,                         / Detached Payload   /
     h'269cd68f4211dffc...0dcb29c' / Signature          /
   ])

   The response contains the Receipt for the Signed Statement.  Fresh
   receipts may be requested through the resource identified in the
   Location header.

2.1.2.2.  Status 202 - Registration is running

   HTTP/1.1 202 Ok

   Location: https://transparency.example/receipts\
   /urn:ietf:params:scitt:signed-statement\
   :sha-256:base64url:5i6UeRzg1...qnGmr1o

   Content-Type: application/json
   Retry-After: <seconds>

   {

     "receipt": "urn:ietf:params:scitt:receipt\
   :sha-256:base64url:5i6UeRzg1...qnGmr1o",

   }

   The response contains a reference to the receipt which will
   eventually be available for the Signed Statement.

   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.






Birkholz, et al.        Expires 5 September 2024                [Page 8]

Internet-Draft                   SCRAPI                       March 2024


2.1.2.3.  Status 400 - Invalid Client Request

   One of the following errors:

   {
     "type": "urn:ietf:params:scitt:error\
   :signed-statement:algorithm-not-supported",
     "detail": \
   "Signed Statement contained an algorithm that is not supported."
   }

   {
     "type": "urn:ietf:params:scitt:error\
   :signed-statement:payload-missing",
     "detail": \
   "Signed Statement payload must be attached (must be present)"
   }

   {
     "type": "urn:ietf:params:scitt:error\
   :signed-statement:payload-forbidden",
     "detail": \
   "Signed Statement payload must be detached (must not be present)"
   }

  {
    "type": "urn:ietf:params:scitt:error\
  :signed-statement:rejected-by-registration-policy",
    "detail": \
  "Signed Statement was not accepted by the current Registration Policy"
  }

   {
     "type": "urn:ietf:params:scitt:error\
   :signed-statement:confirmation-missing",
     "detail": \
   "Signed Statement did not contain proof of possession"
   }

   TODO: other error codes

2.2.  Optional Endpoints

   The following HTTP endpoints are optional to implement.







Birkholz, et al.        Expires 5 September 2024                [Page 9]

Internet-Draft                   SCRAPI                       March 2024


2.2.1.  Issue Statement

   Authentication MUST be implemented for this endpoint.

   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.

   Request:

   POST /signed-statements/issue HTTP/1.1
   Host: transparency.example
   Accept: application/json
   Content-Type: application/vc+ld+json
   Payload

   {
     "@context": [
       "https://www.w3.org/ns/credentials/v2",
       "https://www.w3.org/ns/credentials/examples/v2"
     ],
     "id": "https://transparency.example/credentials/1872",
     "type": ["VerifiableCredential", "SensorCredential"],
     "issuer": "https://transparency.example/device/1234",
     "validFrom": "2010-01-01T19:23:24Z",
     "credentialSubject": {
       "type": "Feature",
       "geometry": {
         "type": "Point",
         "coordinates": [125.6, 10.1]
       },
       "properties": {
         "name": "Dinagat Islands"
       }
     }
   }

   Response:











Birkholz, et al.        Expires 5 September 2024               [Page 10]

Internet-Draft                   SCRAPI                       March 2024


   HTTP/1.1 200 Ok
   Content-Type: application/cose

   Payload (in CBOR diagnostic notation)

   18([                            / COSE Sign1         /
     h'a1013822',                  / Protected Header   /
     {},                           / Unprotected Header /
     null,                         / Detached Payload   /
     h'269cd68f4211dffc...0dcb29c' / Signature          /
   ])

2.2.2.  Resolve Statement

   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:

   GET /statements/urn...qnGmr1o HTTP/1.1
   Host: transparency.example
   Accept: application/pdf

   Response:

   HTTP/1.1 200 Ok
   Content-Type: application/pdf
   Payload (pdf bytes)

2.2.3.  Resolve Signed Statement

   Authentication SHOULD be implemented for this endpoint.

   This endpoint enables Transparency Service APIs to act like Artifact
   Repositories, and serve Signed Statements directly, instead of
   indirectly through Receipts.

   Request:

   GET /signed-statements/urn...qnGmr1o HTTP/1.1
   Host: transparency.example
   Accept: application/cose

   Response:




Birkholz, et al.        Expires 5 September 2024               [Page 11]

Internet-Draft                   SCRAPI                       March 2024


   HTTP/1.1 200 Ok
   Content-Type: application/cose

   Payload (in CBOR diagnostic notation)

   18([                            / COSE Sign1         /
     h'a1013822',                  / Protected Header   /
     {},                           / Unprotected Header /
     null,                         / Detached Payload   /
     h'269cd68f4211dffc...0dcb29c' / Signature          /
   ])

2.2.4.  Resolve Receipt

   Authentication SHOULD be implemented for this endpoint.

   Request:

   GET /receipts/urn...qnGmr1o HTTP/1.1
   Host: transparency.example
   Accept: application/cose

   Response:

   If the Signed Statement requested is already included in the Append-
   Only Log:

   HTTP/1.1 200 Ok
   Location: https://transparency.example/receipts/urn...qnGmr1o
   Content-Type: application/cose

   Payload (in CBOR diagnostic notation)

   18([                            / COSE Sign1         /
     h'a1013822',                  / Protected Header   /
     {},                           / Unprotected Header /
     null,                         / Detached Payload   /
     h'269cd68f4211dffc...0dcb29c' / Signature          /
   ])

   If the Signed Statement requested is not yet included in the Append-
   Only Log:









Birkholz, et al.        Expires 5 September 2024               [Page 12]

Internet-Draft                   SCRAPI                       March 2024


   HTTP/1.1 202 Ok
   Location: https://transparency.example/receipts/urn...qnGmr1o
   Content-Type: application/json
   Retry-After: <seconds>

   {
     "receipt": "urn:ietf:params:scitt:receipt\
       :sha-256:base64url:5i6UeRzg1...qnGmr1o",
   }

   Additional eventually consistent operation details MAY be present.
   Support for eventually consistent Receipts is implementation
   specific, and out of scope for this specification.

2.2.5.  Resolve Issuer

   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.

   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:

   Request:

   GET /.well-known/issuer/tenant/1234 HTTP/1.1
   Host: transparency.example
   Accept: application/json

   Response:



















Birkholz, et al.        Expires 5 September 2024               [Page 13]

Internet-Draft                   SCRAPI                       March 2024


   HTTP/1.1 200 Ok
   Content-Type: application/json

   {
     "issuer": "https://transparency.example/tenant/1234",
     "jwks": {
       "keys": [
         {
           "kid": "urn:ietf:params:oauth\
   :jwk-thumbprint:sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo",
           "alg": "ES256",
           "use": "sig",
           "kty": "EC",
           "crv": "P-256",
           "x": "p-kZ4uOASt9IjQRTrWikGnlbGb-z3LU1ltwRjZaOS9w",
           "y": "ymXE1yltJPXgjQSRe9NweN3TLlSUALYZTzy83NVfdg0"
         },
         {
           "kid": "urn:ietf:params:oauth\
   :jwk-thumbprint:sha-256:4Fzx5HO1W0ob9CZNc3RJx28Ixpgy9JAFM8jyXKW0ClE",
           "alg": "HPKE-Base-P256-SHA256-AES128GCM",
           "use": "enc",
           "kty": "EC",
           "crv": "P-256",
           "x": "Vreuil95vzR6ixutgBBf2ota-rj97MvKfuJWB4qqp5w",
           "y": "NkUTeaoNlLRRsVRxHGDA-RsA0ex2tSpcd3G-4SmKXbs"
         }
       ]
     }
   }

2.2.6.  Request Nonce

   This endpoint in inspired by
   [I-D.draft-demarco-oauth-nonce-endpoint].

   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.

   Request:

   GET /nonce HTTP/1.1
   Host: transparency.example
   Accept: application/json




Birkholz, et al.        Expires 5 September 2024               [Page 14]

Internet-Draft                   SCRAPI                       March 2024


   Response:

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "nonce": "d2JhY2NhbG91cmVqdWFuZGFt"
   }

2.2.7.  Resolve Issuer DID

   This endpoint enables the use of the DID Web Decentralized Identifier
   Method, as an alternative expression of the Issuer Metadata endpoint.

   This endpoint is DEPRECATED.

   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:

   Request:

   GET /tenant/1234/did.json HTTP/1.1
   Host: transparency.example
   Accept: application/did+ld+json

   Response:

   HTTP/1.1 200 Ok
   Content-Type: application/did+ld+json

   {
     "@context": [
       "https://www.w3.org/ns/did/v1",
       {
         "@vocab": "https://vocab.transparency.example#"
       }
     ],
     "id": "did:web:transparency.example:tenant:1234",
     "verificationMethod": [
       {
         "id": "did:web:transparency.example:tenant:1234\
           #urn:ietf:params:oauth:jwk-thumbprint\
           :sha-256:5b30k1hBWBMcggA9GIJImUqj4pXqrJ9EOWV6MDdcstA",
         "type": "JsonWebKey",
         "controller": "did:web:transparency.example:tenant:1234",
         "publicKeyJwk": {
           "kid": "urn:ietf:params:oauth:jwk-thumbprint\



Birkholz, et al.        Expires 5 September 2024               [Page 15]

Internet-Draft                   SCRAPI                       March 2024


             :sha-256:5b30k1hBWBMcggA9GIJImUqj4pXqrJ9EOWV6MDdcstA",
           "alg": "ES256",
           "use": "sig",
           "kty": "EC",
           "crv": "P-256",
           "x": "9ptuW0PBHSTN7bVexWd7xM5kmSPGRaCu-K3SLtJyvNc",
           "y": "l7NvF6QbovicSciZqu_W_xy4JTZwtnUbn2SNdMKoaAk"
         }
       },
       {
         "id": "did:web:transparency.example:tenant:1234\
           #urn:ietf:params:oauth:jwk-thumbprint\
           :sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo",
         "type": "JsonWebKey",
         "controller": "did:web:transparency.example:tenant:1234",
         "publicKeyJwk": {
           "kid": "urn:ietf:params:oauth:jwk-thumbprint\
             :sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo",
           "alg": "ES256",
           "use": "sig",
           "kty": "EC",
           "crv": "P-256",
           "x": "p-kZ4uOASt9IjQRTrWikGnlbGb-z3LU1ltwRjZaOS9w",
           "y": "ymXE1yltJPXgjQSRe9NweN3TLlSUALYZTzy83NVfdg0"
         }
       },
       {
         "id": "did:web:transparency.example:tenant:1234\
           #urn:ietf:params:oauth:jwk-thumbprint\
           :sha-256:4Fzx5HO1W0ob9CZNc3RJx28Ixpgy9JAFM8jyXKW0ClE",
         "type": "JsonWebKey",
         "controller": "did:web:transparency.example:tenant:1234",
         "publicKeyJwk": {
           "kid": "urn:ietf:params:oauth:jwk-thumbprint\
             :sha-256:4Fzx5HO1W0ob9CZNc3RJx28Ixpgy9JAFM8jyXKW0ClE",
           "alg": "HPKE-Base-P256-SHA256-AES128GCM",
           "use": "enc",
           "kty": "EC",
           "crv": "P-256",
           "x": "Vreuil95vzR6ixutgBBf2ota-rj97MvKfuJWB4qqp5w",
           "y": "NkUTeaoNlLRRsVRxHGDA-RsA0ex2tSpcd3G-4SmKXbs"
         }
       }
     ],
     "assertionMethod": [
       "did:web:transparency.example:tenant:1234\
         #urn:ietf:params:oauth:jwk-thumbprint\
         :sha-256:5b30k1hBWBMcggA9GIJImUqj4pXqrJ9EOWV6MDdcstA",



Birkholz, et al.        Expires 5 September 2024               [Page 16]

Internet-Draft                   SCRAPI                       March 2024


       "did:web:transparency.example:tenant:1234\
         #urn:ietf:params:oauth:jwk-thumbprint\
         :sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo"
     ],
     "authentication": [
       "did:web:transparency.example:tenant:1234\
         #urn:ietf:params:oauth:jwk-thumbprint\
         :sha-256:5b30k1hBWBMcggA9GIJImUqj4pXqrJ9EOWV6MDdcstA",
       "did:web:transparency.example:tenant:1234\
         #urn:ietf:params:oauth:jwk-thumbprint\
         :sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo"
     ],
     "keyAgreement": [
       "did:web:transparency.example:tenant:1234\
         #urn:ietf:params:oauth:jwk-thumbprint\
         :sha-256:4Fzx5HO1W0ob9CZNc3RJx28Ixpgy9JAFM8jyXKW0ClE"
     ]
   }

3.  Privacy Considerations

   TODO

4.  Security Considerations

   TODO

   TODO: Consider negotiation for receipt as "JSON" or "YAML".  TODO:
   Consider impact of media type on "Data URIs" and QR Codes.

5.  IANA Considerations

5.1.  URN Sub-namespace for SCITT (urn:ietf:params:scitt)

   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]:

      Registry name:  scitt
      Specification:  [RFCthis]
      Repository:  http://www.iana.org/assignments/scitt
      Index value:  No transformation needed.

5.2.  Well-Known URI for Issuers

   The following value is requested to be registered in the "Well-Known
   URIs" registry (using the template from [RFC5785]):



Birkholz, et al.        Expires 5 September 2024               [Page 17]

Internet-Draft                   SCRAPI                       March 2024


   URI suffix: issuer Change controller: IETF Specification document(s):
   RFCthis.  Related information: N/A

5.3.  Well-Known URI for Transparency Configuration

   The following value is requested to be registered in the "Well-Known
   URIs" registry (using the template from [RFC5785]):

   URI suffix: transparency-configuration Change controller: IETF
   Specification document(s): RFCthis.  Related information: N/A

   TODO: Register them from here.

5.4.  Media Type Registration

   This section requests registration of the "application/
   scitt.receipt+cose" media type [RFC2046] in the "Media Types"
   registry in the manner described in [RFC6838].

   To indicate that the content is a SCITT Receipt:

   *  Type name: application

   *  Subtype name: scitt.receipt+cose

   *  Required parameters: n/a

   *  Optional parameters: n/a

   *  Encoding considerations: TODO

   *  Security considerations: TODO

   *  Interoperability considerations: n/a

   *  Published specification: this specification

   *  Applications that use this media type: TBD

   *  Fragment identifier considerations: n/a

   *  Additional information:

      -  Magic number(s): n/a

      -  File extension(s): n/a

      -  Macintosh file type code(s): n/a



Birkholz, et al.        Expires 5 September 2024               [Page 18]

Internet-Draft                   SCRAPI                       March 2024


   *  Person & email address to contact for further information: TODO

   *  Intended usage: COMMON

   *  Restrictions on usage: none

   *  Author: TODO

   *  Change Controller: IESG

   *  Provisional registration?  No

6.  References

6.1.  Normative References

   [I-D.draft-ietf-scitt-architecture]
              Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
              Y., and S. Lasker, "An Architecture for Trustworthy and
              Transparent Digital Supply Chains", Work in Progress,
              Internet-Draft, draft-ietf-scitt-architecture-05, 9
              February 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-scitt-architecture-05>.

   [IANA.params]
              IANA, "Uniform Resource Name (URN) Namespace for IETF
              Use", <http://www.iana.org/assignments/params>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC3553]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
              IETF URN Sub-namespace for Registered Protocol
              Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
              2003, <https://www.rfc-editor.org/rfc/rfc3553>.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              DOI 10.17487/RFC5785, April 2010,
              <https://www.rfc-editor.org/rfc/rfc5785>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/rfc/rfc7231>.




Birkholz, et al.        Expires 5 September 2024               [Page 19]

Internet-Draft                   SCRAPI                       March 2024


   [RFC7807]  Nottingham, M. and E. Wilde, "Problem Details for HTTP
              APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
              <https://www.rfc-editor.org/rfc/rfc7807>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9052>.

6.2.  Informative References

   [I-D.draft-demarco-oauth-nonce-endpoint]
              De Marco, G. and O. Steele, "OAuth 2.0 Nonce Endpoint",
              Work in Progress, Internet-Draft, draft-demarco-oauth-
              nonce-endpoint-00, 6 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-demarco-
              oauth-nonce-endpoint-00>.

   [I-D.draft-ietf-oauth-sd-jwt-vc]
              Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based
              Verifiable Credentials (SD-JWT VC)", Work in Progress,
              Internet-Draft, draft-ietf-oauth-sd-jwt-vc-02, 27 February
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              oauth-sd-jwt-vc-02>.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <https://www.rfc-editor.org/rfc/rfc2046>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/rfc/rfc6838>.

Authors' Addresses

   Henk Birkholz
   Fraunhofer SIT
   Rheinstrasse 75
   64295 Darmstadt
   Germany
   Email: henk.birkholz@sit.fraunhofer.de




Birkholz, et al.        Expires 5 September 2024               [Page 20]

Internet-Draft                   SCRAPI                       March 2024


   Orie Steele
   Transmute
   Email: orie@transmute.industries


   Jon Geater
   DataTrails Inc.
   United States
   Email: jon.geater@datatrails.ai










































Birkholz, et al.        Expires 5 September 2024               [Page 21]