From 852a06c7077dcf0ff650e02388639d425ccd63bc Mon Sep 17 00:00:00 2001 From: ID Bot Date: Tue, 5 Dec 2023 22:32:23 +0000 Subject: [PATCH] Script updating gh-pages from 897f6c8. [ci skip] --- index.html | 9 + .../draft-birkholz-scitt-scrapi.html | 1843 +++++++++++++++++ .../draft-birkholz-scitt-scrapi.txt | 480 +++++ steve/datatrails-branding/index.html | 45 + 4 files changed, 2377 insertions(+) create mode 100644 steve/datatrails-branding/draft-birkholz-scitt-scrapi.html create mode 100644 steve/datatrails-branding/draft-birkholz-scitt-scrapi.txt create mode 100644 steve/datatrails-branding/index.html diff --git a/index.html b/index.html index 5cf6bbe..8e6471e 100644 --- a/index.html +++ b/index.html @@ -24,6 +24,15 @@

Editor's drafts for main branch of steve

+

Preview for branch steve/datatrails-branding

+ + + + + + +
SCRAPIplain textdiff with main
+ + diff --git a/steve/datatrails-branding/draft-birkholz-scitt-scrapi.txt b/steve/datatrails-branding/draft-birkholz-scitt-scrapi.txt new file mode 100644 index 0000000..ea98eef --- /dev/null +++ b/steve/datatrails-branding/draft-birkholz-scitt-scrapi.txt @@ -0,0 +1,480 @@ + + + + +TBD H. Birkholz +Internet-Draft Fraunhofer SIT +Intended status: Standards Track O. Steele +Expires: 7 June 2024 Transmute + J. Geater + DataTrails Inc. + 5 December 2023 + + + SCITT Reference APIs + draft-birkholz-scitt-scrapi-latest + +Abstract + + 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]. + +Discussion Venues + + This note is to be removed before publishing as an RFC. + + Source for this draft and an issue tracker can be found at + https://github.com/ietf-scitt/draft-birkholz-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/. + + 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 7 June 2024. + +Copyright Notice + + Copyright (c) 2023 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 + 1.1. Requirements Notation + 2. Relation to Identity + 2.1. Authenticating Clients + 2.2. Discovering Federation + 2.3. Discovering Feeds + 3. SCITT Reference REST API + 3.1. Messages + 3.1.1. Register Signed Statement + 3.1.2. Retrieve Operation Status + 3.1.3. Retrieve Signed Statement + 3.1.4. Retrieve Registration Receipt + 4. Privacy Considerations + 5. Security Considerations + 6. IANA Considerations + 6.1. URN Sub-namespace for SCITT (urn:ietf:params:scitt) + 6.2. Media Types + 6.3. Well Known URIs + 6.4. Media Type Registration + 7. References + 7.1. Normative References + 7.2. Informative References + Appendix A. Attic + Authors' Addresses + +1. Introduction + + This API definition MAY be exposed externally as part of a suite of + APIs, or be encapsulated internally and exposed indirectly via + proprietart APIs. + +1.1. Requirements Notation + + 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. Relation to Identity + + 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. Authenticating Clients + + TBD (comments on OAuth / Client Attestation). + +2.2. Discovering Federation + + TBD (comments on GAIN / OIDC). + +2.3. Discovering Feeds + + TBD (comments on URLs / QR Codes). + +3. SCITT Reference REST API + +3.1. Messages + + 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": "The Statement was signed with an unsupported algorithm" + } + + 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 + 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. + +3.1.1. Register Signed Statement + +3.1.1.1. Request + + POST /entries + + Headers: + + * Content-Type: application/cose + + Body: SCITT COSE_Sign1 message + +3.1.1.2. Response + + One of the following: + + * Status 201 - Registration is successful. + + - Header Location: /entries/ + + - Header Content-Type: application/json + + - Body { "entryId": " } + + * Status 202 - Registration is running. + + - Header Location: /operations/ + + - Header Content-Type: application/json + + - (Optional) Header: Retry-After: + + - Body { "operationId": "", "status": "running" } + + * Status 400 - Registration was unsuccessful due to invalid input. + + - Error code badSignatureAlgorithm + + - TBD: more error codes to be defined + + 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. + +3.1.2. Retrieve Operation Status + +3.1.2.1. Request + + GET /operations/ + +3.1.2.2. Response + + One of the following: + + * Status 200 - Registration is running + + - Header: Content-Type: application/json + + - (Optional) Header: Retry-After: + + - Body: { "operationId": "", "status": "running" } + + * Status 200 - Registration was successful + + - Header: Location: /entries/ + + - Header: Content-Type: application/json + + - Body: { "operationId": "", "status": "succeeded", + "entryId": "" } + + * Status 200 - Registration failed + + - Header Content-Type: application/json + + - Body: { "operationId": "", "status": "failed", + "error": { "type": "", "detail": "" } } + + - Error code: badSignatureAlgorithm + + * Status 404 - Unknown Operation ID + + - Error code: operationNotFound + + - This can happen if the operation ID has expired and been + deleted. + + If an operation failed, then error details SHOULD be embedded as a + JSON problem details object in the "error" field. + + 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. + +3.1.3. Retrieve Signed Statement + +3.1.3.1. Request + + GET /entries/ + + Query parameters: + + * (Optional) embedReceipt=true + + 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. + +3.1.3.2. Response + + One of the following: + + * Status 200. + + - Header: Content-Type: application/cose + + - Body: COSE_Sign1 + + * Status 404 - Entry not found. + + - Error code: entryNotFound + +3.1.4. Retrieve Registration Receipt + +3.1.4.1. Request + + GET /entries//receipt + +3.1.4.2. Response + + One of the following: + + * Status 200. + + - Header: Content-Type: application/cbor + + - Body: SCITT_Receipt + + * Status 404 - Entry not found. + + - Error code: entryNotFound + + The retrieved Receipt may be embedded in the corresponding COSE_Sign1 + document in the unprotected header. + +4. Privacy Considerations + + TODO + +5. Security Considerations + + TODO + +6. IANA Considerations + +6.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. + +6.2. Media Types + + TODO: Register them from here. + +6.3. Well Known URIs + + For discovering scitt configuration. + + TODO: Register them from here. + +6.4. Media Type Registration + + This section requests registration of the "application/receipt+cose" + media type [RFC2046] in the "Media Types" registry in the manner + described in [RFC6838]. + + TODO: Consider negotiation for receipt as "JSON" or "YAML". TODO: + Consider impact of media type on "Data URIs" and QR Codes. + + To indicate that the content is a SCITT Receipt: + + * Type name: application + + * Subtype name: 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 + + * Person & email address to contact for further information: TODO + + * Intended usage: COMMON + + * Restrictions on usage: none + + * Author: TODO + + * Change Controller: IESG + + * Provisional registration? No + +7. References + +7.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-04, 23 + October 2023, . + + [IANA.params] + IANA, "Uniform Resource Name (URN) Namespace for IETF + Use", . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [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, . + + [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, + . + + [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP + APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +7.2. Informative References + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + DOI 10.17487/RFC2046, November 1996, + . + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + . + +Appendix A. Attic + + Not ready to throw these texts into the trash bin yet. + +Authors' Addresses + + Henk Birkholz + Fraunhofer SIT + Rheinstrasse 75 + 64295 Darmstadt + Germany + Email: henk.birkholz@sit.fraunhofer.de + + + Orie Steele + Transmute + Email: orie@transmute.industries + + + Jon Geater + DataTrails Inc. + United States + Email: jon.geater@datatrails.ai diff --git a/steve/datatrails-branding/index.html b/steve/datatrails-branding/index.html new file mode 100644 index 0000000..9229190 --- /dev/null +++ b/steve/datatrails-branding/index.html @@ -0,0 +1,45 @@ + + + + ietf-scitt/draft-birkholz-scitt-scrapi steve/datatrails-branding preview + + + + +

Editor's drafts for steve/datatrails-branding branch of ietf-scitt/draft-birkholz-scitt-scrapi

+ + + + + + +
SCRAPIplain textsame as main
+ + +