From 3732759fdb7ddc6431d6240ffdffbf85cdf0c502 Mon Sep 17 00:00:00 2001 From: Orie Steele Date: Mon, 31 Jul 2023 13:02:54 -0500 Subject: [PATCH 1/2] Thoughts after 117 --- draft-birkholz-scitt-scrapi.md | 60 ++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/draft-birkholz-scitt-scrapi.md b/draft-birkholz-scitt-scrapi.md index 064724d..b3543a7 100644 --- a/draft-birkholz-scitt-scrapi.md +++ b/draft-birkholz-scitt-scrapi.md @@ -54,6 +54,27 @@ Introduction Text {::boilerplate bcp14-tagged} +# 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. + +## Authenticating Clients + +TBD (comments on OAuth / Client Attestation). + +## Discovering Federation + +TBD (comments on GAIN / OIDC). + +## Discovering Feeds + +TBD (comments on URLs / QR Codes). + + # SCITT Reference REST API ## Messages @@ -217,8 +238,47 @@ Security Considerations Maybe +## Media Type Registration + +This section requests registration of the "application/receipt+cose" media type [@RFC2046] in +the "Media Types" registry [@IANA.MediaTypes] 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 + --- back + + + + Media Types + + + # Attic Not ready to throw these texts into the trash bin yet. From da8fbe0a6890275689f96a595b44169cdc2be5e9 Mon Sep 17 00:00:00 2001 From: Orie Steele Date: Mon, 31 Jul 2023 13:19:08 -0500 Subject: [PATCH 2/2] cleaning and lint --- draft-birkholz-scitt-scrapi.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/draft-birkholz-scitt-scrapi.md b/draft-birkholz-scitt-scrapi.md index b3543a7..bd52c30 100644 --- a/draft-birkholz-scitt-scrapi.md +++ b/draft-birkholz-scitt-scrapi.md @@ -5,6 +5,7 @@ docname: draft-birkholz-scitt-scrapi-latest stand_alone: true ipr: trust200902 area: Security +submissiontype: IETF wg: TBD kw: Internet-Draft cat: std @@ -40,6 +41,9 @@ normative: informative: + RFC2046: + RFC6838: + --- abstract Abstract Text @@ -100,7 +104,8 @@ As an example, submitting a Signed Statement with an unsupported signature algor ~~~ 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: +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). @@ -141,7 +146,8 @@ One of the following: - 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. +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. ### Retrieve Operation Status @@ -240,9 +246,8 @@ Maybe ## Media Type Registration -This section requests registration of the "application/receipt+cose" media type [@RFC2046] in -the "Media Types" registry [@IANA.MediaTypes] in the manner described -in [@RFC6838]. +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. @@ -256,7 +261,7 @@ To indicate that the content is a SCITT Receipt: * Encoding considerations: TODO * Security considerations: TODO * Interoperability considerations: n/a -* Published specification: [[ this specification ]] +* Published specification: this specification * Applications that use this media type: TBD * Fragment identifier considerations: n/a * Additional information: @@ -270,14 +275,8 @@ To indicate that the content is a SCITT Receipt: * Change Controller: IESG * Provisional registration? No ---- back - - - - Media Types - - +--- back # Attic