Merge pull request #1 from transmute-industries/post-ietf-117-thoughts

Thoughts after 117

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
@@ -54,6 +58,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
@@ -79,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).
 
@@ -120,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
@@ -217,6 +244,38 @@ Security Considerations
 
 Maybe
 
+## 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
+
+
 --- back
 
 # Attic