Internal review #1
Conversation
| @@ -0,0 +1,250 @@ | |||
| --- | |||
| CIP: 1904 | |||
| Title: Verifiable supply chain records | |||
There was a problem hiding this comment.
I want to instead keep this broad and not limited to proof of origin, since it can cover more than we did.
| Authors: | ||
| - Fergal O'Connor <[email protected]> | ||
| - Darlisa Consoni <[email protected]> | ||
| Implementors: ["Cardano Foundation"] |
| |`v` for version|The version of the specification.|string|1| | ||
| |`cid`|The Content Identifier of the off-chain data as defined by [Multiformats](https://github.com/multiformats/cid).|string|| | ||
| |`d` for verification data|Map of `producerID`s to their respective verfication information.|map|| | ||
| |`pk` for public key|The public key belonging to `producerID`. The field accepts the direct byte stream of the public key (embedded), or alternatively accepts a URL to the public key. The public key URL when resolved must serve the raw bytes using a HTTP Content-Type of `application/octet-stream`. Public keys must be verified by some predefined process relevant to the subtype. In case a particular producer performs a key rotation within a single transaction, `pk` can accept an array of URLs or byte streams. In this scenario, `h` must also be converted into an array of headers, and `s` must be converted into an array of arrays, where each top-level array represents all signatures for a given public key.|byte-stream or array of byte-streams|| |
There was a problem hiding this comment.
This is no longer limited to Ed25519. If it needs to be limited, the subtype can limit it.
For now, it's only limited broadly to what JSON Web Signatures support.
| ## Path to Active | ||
|
|
||
| ### Acceptance Criteria | ||
| <todo> |
There was a problem hiding this comment.
Not sure if this needs to be a reference impl. If not, I don't know what to put here other than CF did it so it should be ready to go.
| [ | ||
| { | ||
| "st": "georgianWine", | ||
| "description": "The National Wine Agency of Georgia oversees the production and quality control of bottles of wine produced in the country. This subtype is used for proof-of-origin and quality control on individual bottles. Supply Chain Management data follows an extended version of the OIV Standard - https://www.oiv.int/standards/international-standard-for-the-labelling-of-wines - and Certificates of Conformity are signed directly by the National Wine Agency. For more information on transaction verification, please see https://cardano-foundation.github.io/cf-georgian-wine-resolver." |
There was a problem hiding this comment.
In theory this could just be a link to the outside documentation but I think some description is useful in case of link rot.
This seems a bit long though
| |---|---|---|---| | ||
| |`t` for type|The type defines the structure of the data.|string|scm| | ||
| |`st` for subtype|This **optional** field can be used to specify/describe a use-case. Please see the Subtypes section for more information.|string|| | ||
| |`v` for version|The version of the specification.|string|1| |
There was a problem hiding this comment.
This really is a string and not an int - used to be v1 and never converted it to a uint.
We're already live so not much we can do - but a string is fine I think - at least leaves us open to go something like "1" -> "1.1" in case the change is minor or something... only put "1" instead of "1.0.0" as it's shorter.
| ##### On-chain format | ||
| The following field labels are used within the on-chain metadata: | ||
|
|
||
| |**Field**|**Description**|**Type**|**Set Value**| |
There was a problem hiding this comment.
I only put the table in once since it the others use a subset of these fields. But maybe I should move this to higher up before the SCM section to be more "common" and just be a master list of supported fields?
The other "subtypes" generally should just dictate off-chain and how to resolve keys/data etc, and not impact this structure.
Really there's just 2 formats here: batching with sigs from multiple parties (wineries SCM), and batching with sigs from a single party (NWA certs).
No description provided.