---
robots: noindex, nofollow
---

# Letter to SCITT
###### tags: `letters`

(sent, at ietf list archive TBD)

Members of SCITT,

We have recently submitted an Internet-Draft that we think may be of interest to the SCITT community. It's "The Envelope Structured Data Format", which is available at https://datatracker.ietf.org/doc/draft-mcnally-envelope/

> ABSTRACT: The envelope protocol specifies a structured format for hierarchical binary data focused on the ability to transmit it in a privacy-focused way. Envelopes are designed to facilitate "smart documents" and have a number of unique features including easy representation of a variety of semantic structures, a built-in Merkle-like digest tree, deterministic representation using CBOR, and the ability for the holder of a document to selectively encrypt or elide specific parts of a document without invalidating the document structure including the digest tree, or any cryptographic signatures that rely on it.

Our primary goal with this draft is to enable us to register our CBOR tags with IANA, so that we don't collide with other emerging or experimental CBOR specs and implementations. However, we think that supply-chain developers are among those who might be able to further leverage Gordian Envelopes and would welcome participation or feedback from group members if there's interest.

We think that Gordian Envelope might be useful for supply-chain use cases because it can present structured data, authenticate the contents of that data through signatures, repackage existing data without invalidating it, and elide (or encrypt) some of all of the data again without invalidating signatures. (The last is certainly its biggest innovation!) This allows for use cases such as the following.

Simple distribution:

1. A manufacturer can create & sign an itemized list of products shipped.
2. Any number of distributors or middle-men can repackage the list with their own signature to verify that the shipment continues to be complete.
3. As part of that repackaging, any distributor or middle-man can note damage or make other comments in a structured way using metadata.
4. Alternatively, a distributor or middle-man can create and sign a new version of the manifest, if some items were missing from previous listings. They can package it alongside the original to maintain the history of the entire shipment.
5. Purchaser can verify the entire supply chain and contents.

Discrete distribution (using elision):

1. A manufacturer can create & sign an itemized list of products shipped.
2. The manufacturer can elide some information about items requiring more discretion.
3. Distributors and middle-men can continue to sign off on shipments provided overall quantities remain visible in the manifest.
4. Customs officers can be given proofs of inclusion that let them verify elided data, as required.
5. Manufacturer can supply purchaser with an unelided copy of a manifest, whose hashes and signatures match the elided version; the purchaser can then merge that with the supply-chain manifest to verify the entire supply chain and contents.

We believe that use cases such as this could fulfill most or all of SCITT's needs regarding Statements, Receipts, and to a lesser extent Registries. We also suspect that there are more complex supply-chain use cases for this data format and its tools such as authentication, elision, and proof of inclusion. We'd love to hear your thoughts, particularly for use cases where you'd like to know if Gordian Envelope could provide solutions.

If you'd like more information on this spec, we have a substantial amount of documentation, videos, libraries, and a reference implementation. Much of this is linked through our Gordian Envelope Intro page: https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Envelope-Intro.md. Let me know if you have questions or would like join the group of third-party developers who is more involved with the development of the spec.

Regards,

-- Christopher Allen