# Gordian Envelope Introduction Video

by Wolf McNally, Blockchain Commons
July 23, 2024 DRAFT

*This is the narration of a forthcoming video. Each short paragraph is approximately one slide or visual that the video will contain, so be sure to use your visual imagination as you read it.*

## Links

- [https://www.blockchaincommons.com/introduction/Envelope-Intro/](An Introduction to Gordian Envelope)
- [https://www.blockchaincommons.com](Blockchain Commons)
- [https://www.blockchaincommons.com/home/sponsors.html](Sustaining Sponsors)
- [https://github.com/sponsors/BlockchainCommons](GitHub Sponsorship)
- [https://btcpay.blockchaincommons.com/](Donate via BTCPay)

## Introduction

---

I’m Wolf McNally, Lead Researcher for Blockchain Commons.

If you are a developer, system architect, or CIO, then this video is for you. I’m going to give you a high-level, visual introduction to the Gordian Envelope format.

---

Gordian Envelope is a “smart document” architecture, designed to fulfill a number of current and emerging requirements for storing and transporting data in ways that are secure, verifiable, and privacy-respecting.

---

In this video, we'll start with a conceptual overview, to ground you in the concepts upon which Envelope is built,

Then we'll touch on the high-level architecture of Envelope,

And finally we'll review a number of the exciting features that Envelope supports.

By then end of this video, you should have a good idea of the many ways Envelope can be applied to various applications.

Blockchain Commons has a wealth of additional documentaion, and examples of practical use cases for Envelope. Links are in the video description, or you can scan the QR codes that appear throughout this video, like this one.

---

Blockchain Commons is proudly a “not-for-profit” social benefit corporation, domiciled in Wyoming but operating world-wide. We have a strong commitment to open source and a defensive patent strategy: anyone can use or improve our tools, and no one can take them away.

---

We work with developer communities to develop and publish specifications, reference implementations, and tooling that support secure and compassionate decentralized architectures and tools for digital assets and digital identity.

---

Please help support Blockchain Commons by becoming a becoming a sustaining sponsor, GitHub sponsor, or making a BTCPay donation.

---

## The Envelope Metaphor

So first, I want to explain why we chose the "envelope" as the central metaphor for next-generation digital smart documents.

---

An envelope is a pretty simple thing we’re all familiar with. So why did we choose the *envelope* as a metaphor for the next generation of smart documents?

---

An envelope is a pretty simple thing we’re all familiar with. But envelopes have a lot of capabilities we might easily overlook!

---

We think of envelopes as simple document containers, and that's definitely a primary purpose.

---

Of course, we can write _on_ them. In this sense, envelopes don’t just *contain* documents, they are _themselves_ documents.

---

In fact, the exterior can be as complex as needed, including routing information.

---

The exterior hides the contents, but can also verify the credentials of the sender.

---

Or it can give you a just a peek at just some of the information it contains.

---

We often think of envelopes as holding only small amounts of information.

---

But the capacity of digital envelopes is unlimited.

---

And that information can be eassily be encrypted to specific receivers…

---

Or can be readable by anyone, except for parts that are specifically redacted.

---

But even when redacted, you can still verify a document’s credentials and signatures.

---

Envelopes can hold goods of monetary value…

---

And highly sensitive personal information.

---

Obviously, you want to use envelopes that can keep important things secure.

---

And envelopes can even contain other envelopes from different senders, with different credentials and contents.

---

Depending on your application, you might need special-purpose envelopes that can combine any of these capabilities exactly the way you need.

---

Wouldn’t it be nice to have a digital envelope that lets you easily do _any_ of these things?

---

It exists right now! Welcome to **Gordian Envelope**.

---

## Key Concepts

In this section we're going to cover a few key concepts you should understand before we get into the details of Gordian Envelope itself. They are:

Hash Algorithms,

Elision and redaction,

Determinism, and

dCBOR.

---

### Hash Algorithms

A key concept for understanding Gordian Envelope is cryptographic hash functions.

---

One of the most common and secure hash algorithms is SHA-256.

Such functions take an input of any size called the *image*...

and produce a fixed-size string of numbers called a *digest*, or *hash*.

Here we're showing the hex representation of hashing the text string. With SHA-256 a digest is always 256 bits (or 32 bytes) long.

But throughout this video, we'll often represent hashes not as long strings of numbers, but as unique icons like this,

called a LifeHash. LifeHash is another Blockchain Commons open source tool, and you can learn more about it by visiting LifeHash.info.

---

Cryptographic hash functions have a number of useful properties.

First of all, they are *deterministic*.

If you put the same image in, you always get exactly the same digest out.

We'll have more to say about determinism later in the video.

---

But even the tiniest change in the image, like capitalizing a letter...

---

...drastically changes the entire digest. In this case all but two of the original digits of the digest are different, and the LifeHash also looks completely different. Big changes in output from small changes in input like this are known as the

*avalanche effect*.

---

In addition, it’s impossible to reverse the process and use the digest to find the original image. This is called

*pre-image resistance*.

---

And a good hash algorithm also has the property that if you know an image and the digest it produces,

it's essentially impossible to find a *different* image

that yields the *same* output.

This property is known as *Second pre-image resistance*

---

Finally, it’s astronomically unlikely for two different inputs to produce the same output. This is called

*collision resistance*.

---

This combination of features makes it possible to use document digests as unique “fingerprints.” Digests are essential for verifying that a document has remained unaltered through transmission, encryption, digital signing, compression, and elision.

---

### Elision and Redaction

But what is “elision”?

---

You’ve certainly seen documents with black bars over parts of the text.

This is *redaction*: the deliberate removal or obscuring of information to prevent the disclosure of sensitive or confidential content. In documents, redaction is primarily used for security, privacy, or legal reasons.

---

*Elision* is a more general term. To "elide" something is an intentional omission of information, without giving a specific reason.

---

For example, information might be elided that is considered redundant of irrelevant for the purpose at hand.

---

Or a long document might be elided to shorten or simplify it, either to save storage space or target it at a particular audience— hopefully without altering the overall meaning too much. So they’re basically the same operation: removing information.

---

But while redaction is about confidentiality and security,

elision can be for any number of reasons including redaction. This is why Gordian Envelope adopts the general term "elision", and you can use elision for any purpose you choose

---

The use of elision will frequently be redaction. For example, the set of informaion on a typical printed document

might be a lot more than is needed for a particular purpose.

---

And digital documents may contain much more sensitive personal information and details than a printed document can hold. Because it's digital, once it is copied it's very easy to lose control of it.

---

But Gordian Envelope is a smart digital document that makes it easy for the holder to *elide* any part of it, whether brevity or privacy.

---

Elision upholds the principle of *minimal disclosure*, which is the practice of revealing only the necessary information required for a specific purpose while keeping all other details hidden, thereby reducing the risk of unauthorized access or misuse of the remaining data.

The cool thing about elision with Gordian Envelope is that the holder can elide parts of the document that have been digitally signed *without* invalidating signatures. How does this work?

---

Every part of a Gordian Envelope is node in a tree,

---

and every node in that tree has a unique digest,

---

including the root of the tree, which is the digest representing the envelope as a whole.

---

It is this digest that is signed.

---

Now when parts of an envelope are elided, the information itself is removed, but the digests of the elided data are left behind.

So the receiver can verify that the signature is valid without knowing everything that was signed.

---

At a later date, a document holder can choose to reveal more of the document covered by the signature,

---

proving additional claims about the signed content.

---

One important thing to note is that since hash algorithms are deterministic, a simple piece of data like a field name

or a person's first name

will always have a unique digest.

This means an assertion like this will also have a unique digest.

If the space of possibilities is small enough, then an attacker might be able to guess what has been elided by just knowing the digest.

This property is called *correlation*.

There are times when correlation is desirable. But sometimes like in this case, not so much. In a few minutes, we'll discuss a mechanism Envelope provides for removing the possibility of this sort of "educated guessing" at what has been elided.

---

### Determinism

One concept you’ll hear discussed around Gordian Envelope is *determinism*. This concept is crucial for systems where consistent, reproducible results are necessary, such as in cryptographic applications, distributed systems, and secure document exchange. A deterministic algorithm, when executed with a given input, will always follow the same sequence of operations and produce the same output.

---

Hash functions like SHA-256 are deterministic:

given a specific binary input,

the *digest* will always be the same.

---

Complex data structures like documents can also be designed to maintain deterministic behavior.

---

The basic idea is that two agents, separated in time or space,

when given the same information,

---

and even when the information is presented in a different order,

will arrive at exactly the same encoding, and hence produce the same digest.

---

One example of a deterministic structure would be the Merkle Tree.

Merkle Trees are used in blockchain and other cryptographic systems,

In a Merkle Tree a set of documents like transactions are hashed,

And then those first level digests are themselves hashed together,

And this continues until there is only a single digest: the root.

Since this process is deterministic, another agent with the same set of transactions would always come up with the same Merkle tree.

---

And if another agent only has the root hash and a transaction but not the full list of transactions,

---

It could ask another agent that has all the transaction to proove that the transaction is definitely in the tree,

just by sending the minimal digests required to show that the transaction must exist in the block.

This is called a Merkle Proof.

---

Popular formats for encoding structured data like JSON present a number of obstacles when trying to implement determinism.

If you want to encode a JSON document such that it produces a deterministic digest,

---

even a tiny change in the placement of whitespace or how a number is written— changes that have no impact on the document’s semantics— completely change the digest.

To use JSON in a deterministic way, a separate process called *canonicalization* must be applied, which transforms the document into a specific form.

Things like normalizing how numeric values are expressed...

---

How Unicode strings are written...

---

The order that dictionary keys are listed...

---

And of course, removing all the whitespace...

---

To finally arrive at a canonical version of the document that can be hashed deterministically.

---

Unfortunately, there isn’t a single agreed-upon standard for canonicalizing JSON. Various specifications and libraries exist, but they differ in details regarding how they handle numeric precision, special floating-point values, the normalization of strings, and many other edge cases.

---

Goridian Envelope is designed to support determinism at every level.

It's designed around a tree structure similar to a Merkle Tree, in that every node has an associated digest. But in an Envelope, the leaves of the tree can be any data type, while the internal nodes of the tree provide structure, like grouping a predicate and object of an assertion, or grouping the envelope's subject with its assertions.

And everything that *can* have an order, such as the order of assertions, and how numeric values and strings are normalized, is well-defined and handled automatically.

---

Every node in an envelope has a digest, but the only time a digest is actually serialized as part of an envelope are in cases like elision,

where the transformation of the document preserves the digest tree. This is how Envelope allows elision, encryption, or compression of parts of the document while preserving digital signatures.

With Gordian Envelope, no separate canonicalization step is ever necessary: when you encode the same semantics, you reliably get the same digest tree.

Many applications don’t require determinism, and Gordian Envelope is designed such that if your application doesn’t need it, it doesn’t cost you anything. In fact, this is an important aspect of Envelope’s design philosophy: you only pay for what you use.

---

### CBOR and dCBOR

Gordian Envelope is built on CBOR: the Concise Binary Object Representation.

---

CBOR is a standard data format similar to JSON but designed for binary encoding, making it more compact and efficient to process. CBOR also offers a richer type system, including a wealth of community-defined tagged data types.

---

CBOR tags are a namespace of numbers that identify data types. IANA, the Internet Assigned Numbers Authority, keeps the registry of CBOR tags. Gordian Envelope and dCBOR have been issued tag 200 and 201, both of which are used in Envelope's formal specification.

---

Since CBOR is a binary format, you can't just open it in a text editor and make sense of it, like JSON.

---

But tools and libraries exist for every operating system and programming language for decoding and encoding CBOR.

---

And CBOR defines a JSON-like "diagnostic notation" which *is* human readable.

---

CBOR also supports binary data directly, eliminating the need for workarounds like Base64 encoding used with JSON.

---

However, like JSON, standard CBOR doesn't directly support deterministic encoding.

Determinism isn’t an easy goal to achieve, so Gordian Envelope is designed to support determinism at every level, starting with dCBOR.

dCBOR is a set of opinionated restrictions on CBOR that support deterministic encoding. All dCBOR is valid CBOR that can be read by any CBOR decoder, and written by any CBOR encoder as long as the additional restrictions of dCBOR’s profile are followed.

---

dCBOR specifies rules for how certain kinds of commonly used data like numbers and strings must be encoded to help ensure that the same semantic content always produces the same binary output. Importantly, it also requires that the rules are enforced on encoding *and* decoding, to ensure that only properly encoded dCBOR is processed.

Naturally, Envelope and documents created with Envelope further restrict the type of data that is allowed in any particular field, but dCBOR helps reduce the cognitive burden on document designers, therefore reducing the likelihood of costly interoperability errors.

---

### Knowledge Representation

Now that we've laid the conceptual foundation for Envelope, let's explore more specifics of Envelope's architecture.

---

At its core, Gordian Envelope represents knowledge using a simple yet powerful structure:

a *subject* with a set of *assertions* about it.

---

Since Envelope is a binary format, its tools provide a human-readable *Envelope Notation*. In this notation, the subject is always first, followed by an optional list of one or more assertions in square brackets.

---

An assertion is a statement about the subject, consisting of a *predicate* (a property or relationship) and an *object* (the value or related entity). In Envelope Notation, the predicate and object of each assertion are separated by a colon.

---

This structure is similar to "subject-predicate-object" triples used in semantic web technologies like RDF, making Envelope familiar to those working with linked data.

---

Here's what a similar structure would look like in Envelope Notation.

---

Think of an envelope as a whole: a subject with an optional list of assertions.

Now here's the cool part: each part of an envelope: it’s subject, it’s assertions, and the specific predicates and objects of its assertions, are also *themselves* envelopes that are can be as simple as strings, but that can also be as complex as necessary, providing for rich metadata and as much complexity as you need for your application.

---

What do we mean by rich metadata? Here's an example of an envelope containing information about a written work. Notice that there is more than one `hasName` assertion, and each of the names of the book contains its own assertion declaring the language of the title string itself.

---

This is the same envelope viewed as a tree.

As you can see, Envelope is a recursive structure, where envelopes contain other envelopes, creating a hierarchical representation of arbitrarily complex information.

Each node of the tree, and the envelope as a whole, are characterized by a unique digest. This is similar to a Merkle tree, but the leaves of an envelope can be any dCBOR data, and the internal nodes provide its structure.

But Gordian Envelope’s design doesn’t limit it to trees: Envelope can be used to represent everything from simple lists of key-value pairs— to collections of related documents containing signed claims, attestations, and selective redactions— to complex, interconnected knowledge graphs.

---

## The Structure of Gordian Envelope

Let’s look a bit at the elegant but powerful architecture of the Envelope data type itself.

---

At its core, Gordian Envelope is implemented as an enumerated type with just five cases:

Leaf, Node, Assertion, Elided, and Wrapped.

Every one of these cases can stand alone as a complete envelope, or participate in the structure of a more complex envelope.

In addition, documented extensions to the Envelope base specification add three additional cases:

Encrypted, Known Value, and Compressed,

for a total of eight.

---

Notice that three of these cases are drawn with a fuzzier border. These are the "obscured" cases; called that because the original data has been transformed in such a way as to not be directly accessible. These three cases are the only ones that actually declare the digest of the original data.

In the Elided case, the original data is entirely absent from the envelope.

In the Encrypted case, the data is present, but has been encrypted using a symmetric key and the digest of the original data is declared as "authenticated data", which means it can be read but can't be altered without being detectable.

And in the Compressed case, the data has been compressed and the declared digest can be checked by decompressing the data and recomputing the digest.

These three transformations preserve the digest tree and make it impossible to tamper with their contents without invalidating signatures.

They are also completely reversible: by replacing the original data in the Elided case, decrypting it in the Encrypted case, and uncompressing it in the Compressed case.

---

In the discussion that follows, text of this kind indicates that *any* of these eight cases may appear where you see it.

---

So now let's look at the cases in the base specification. We'll come back to the other three cases when we talk about extensions.

---

First there's the *leaf* case. Leaves hold any valid dCBOR data, allowing Envelope to encapsulate a wide range of information types.

---

For example, the CBOR diagnostic notation a leaf holding a string is just the CBOR string tagged 201, representing dCBOR. In Envelopes, all leaves are tagged 201, and this tag is what distinguishes leaves from the other cases.

---

To make this a complete envelope, just tag the leaf 200, representing Gordian Envelope.

---

That's it! A complete, simple Gordian Envelope that adds only 4 bytes to the CBOR text string it encapsulates.

---

When this envelope is printed in Envelope Notation, it just displays as a string.

---

In the general case, the tagged dCBOR is displayed in CBOR diagnostic notation.

---

The *node* case groups a subject, which can be any envelope case called the *subject*, and one or more assertions. The Node case forms the backbone of Envelope's hierarchical knowledge representation structure.

The CBOR for a Node is simply a CBOR array with the subject as its first element, and each assertion as a subsequent element. To ensure determinism, assertions are always sorted in order by their computed digest.

In Envelope Notation, the subject is displayed before a pair of square brackets, with the assertions inside the brackets. In Envelope Notation, the assertions are sorted for easier reading, and not according to their digest.

---

The *assertion* case groups two other envelopes: its *predicate* and *object*.

Together the predicate and object make a statement of fact about the subject of the Node that contains them.

The CBOR for an assertion is just a CBOR map, analogous to a JSON dictionary, with the predicate as the key and the object as the value. Like JSON dictionaries, CBOR maps can have multiple entries, but in Envelope's Assertion case, it always has exactly one.

In Envelope Notation, an Assertion is printed with the predicate, then a colon, then the object.

---

The *elided* case is a placeholder for information that has been removed, represented by its digest.

The CBOR for the Elided case is a binary string containing the digest of the elided case. This digest is a cryptographic commitment to everything that the node and its child nodes (if any) contain.

In Envelope Notation, this case is simply displayed as the word ELIDED.

---

Finally, the *wrapped* case encapsulates an entire Envelope, enabling the addition of meta-statements about entire nested document structure.

---

Recall that each assertion makes a statement of fact or claim about the subject of an envelope.

---

So adding a new signature assertion this this envelope would only sign the subject.

But in this case we don't want to sign only the subject, but the subject and all of its assertions.

---

We do this by first *wrapping* this envelope in a new, outer envelope.

---

---

Now that the envelope is wrapped, the subject is literally the entire envelope, which currently has no assertions of its own.

---

So when we add a new assertion with our signature, the entire original envelope, including its assertions, are signed.

---

And now nothing in the wrapped envelope can be altered without invalidating the signature.

---

Recall that an envelope case when tagged 200 becomes a complete Envelope.

---

The CBOR for the Wrapped case is composed by simply wrapping that in *another* 200 tag.

And in Envelope Notation, the Wrapped case is printed by enclosing the indented text of the wrapped case in curly braces.

---

That's it! Now you know the essentials of how Gordian Envelopes are structured.

---

## Specifications

The specifications for dCBOR and Gordian Envelope are in the early stages of standardization, and are currently published as IETF Internet Drafts (I-Ds), with the aim of publishing them later as RFCs. While we expect these specifications will undergo further refinements on this path, we consider them both to be stable and ready for use.

## Reference Implementations

Blockchain Commons currently has open source reference implementations of Envelope in Rust and Swift that implement the full base specification as well as the extensions described later. Parts of our stack have already been ported to other languages by the open source community, and we rely on our community and our donors to make our ongoing research and development efforts possible.

## Tooling

The `envelope` command line tool is written in Rust and can be used to construct, investigate the contents of, and extract information from envelopes, either by typing commands directly or in complex shell scripts.

## Envelope Extensions

Numerous extensions to the base Envelope specification are documented in the Blockchain Commons `Research` repo on GitHub, and we’ll briefly show you some of them here.

### Digital Signatures

Envelopes may be signed by one or more private keys, and verified by the corresponding public keys.

To sign a whole envelope including its assertions, first wrap the envelope, then sign it.

Now even though parts of the wrapped envelope can still be *elided* by the holder, no part of the wrapped envelope can actually be *modified* without invalidating the signatures on the envelope.

### Symmetric Encryption

Envelopes can be encrypted using a symmetric key. Encrypting an envelope leaves its digest declared in a tamper-proof way, which means that like elision, signatures on envelopes can remain valid even when a branch of the tree has been encrypted.

### Public Key Encryption

By using the public keys of one or more recipients, assertions may be added to an encrypted envelope that allow only those recipients, using their private keys, to retrieve the symmetric key used to encrypt the envelope.

### Compression

Envelopes may be easily compressed using the DEFLATE algorithm, which is the core compressor of the open source Zip format.

For branches of large envelopes where you prefer space savings over immediate access, you can simply compress those branches.

And like elision and symmetric encryption, a compressed envelope declares the digest of the decompressed content.

Thus, elision, encryption, and compression are all ways to transform parts of an envelope without invalidating signatures, or other references to an envelope that depend on its overall digest tree.

### Decorrelation

But sometimes you *want* to encrypt or elide something, and ensure that the digest left behind does not inadvertently match known data. This potential matching of data to digest is called *correlation* and is often, but not always desirable.

For instance, a short “first name” field like “John” will have an easily guessable digest. Of course, the larger the branch of the Envelope tree you’re considering the more variance there is likely to be in the data, hence making the elided branch harder to guess from its digest alone.

But when you want to avoid correlation entirely, envelope provides a simple extension for *decorrelation* by adding assertions called *salts* that contain random data.

Because the data is random, it ensures that the branch of the Envelope tree containing the salt, all the way back to the root, is universally unique. As long as the salt itself is part of what is elided or encrypted, nobody can correlate the remaining digest to its content.

### Known Values

Envelope is based on a semantic subject-predicate-object format. In formats used for knowledge representation like RDF, ontological concepts like relationships, classes, and properties are often represented using URIs, but these can be verbose and potentially manipulated or stated in semantically equivalent ways that break determinism.

Known Values offer a compact, deterministic alternative by assigning values from a space of 64-bit integers to represent various concepts.

Using Known Values in Envelopes reduces the size of encoded data and enhances security by eliminating the surface for URI manipulation attacks, as well as making it simpler to implement determinism.

The Gordian Envelope Known Values extension provides for efficient representation of common predicates and concepts.

For example, the concept of "type" (analogous to RDF's "rdf:type") can be represented by the Known Value '1' or 'isA'. Declaring a type is so common it only takes a single byte to encode.

Known Values assignments are managed through a centralized registry, ensuring consistency across different systems and applications. Over time we plan to expand the registry to include values from various major ontologies like RDF and OWL as well as allow third parties to register Known Values for domain-specific ontologies.

Known Values can be used in any part of an Envelope: as subjects, predicates, or objects, providing flexibility in knowledge representation.

### Attachments

Gordian Envelope's attachment extension allows for the addition of vendor-specific information to an Envelope without altering its core structure or content. Designers of envelope-based schemas may declare that they support attachments.

Attachments serve as a method to extend the functionality of Envelopes in domain-specific ways while maintaining interoperability with systems that may not understand these extensions.

The attachment mechanism uses a standardized format within the Envelope structure. It includes a payload, which can be any valid Envelope content, along with metadata identifying the vendor and optionally specifying the format of the attachment.

Multiple attachments from different vendors can coexist within a single Envelope, allowing for complex, multi-party interactions like attestations and supply chain tracking, while maintaining the integrity of the core data.

Importantly, attachments inherit Gordian Envelope's privacy and security features. They can be selectively shared, encrypted, or elided without invalidating the digest tree, providing fine-grained control over the disclosure of such additional information.

### Existence Proofs

A top-level digest of a completely elided envelope is unique and therefore a cryptographic commitment to everything inside it.

After having sent such an elided envelope, the sender may use this extension to construct an *existence proof*, which is analogous to a Merkle proof.

The existence proof reveals only the minimal digests in the tree leading to the data which is to be proved. When the proof is applied to the original commitment, it shows that the information *must* be present at the described position in the original unelided envelope.

### Envelope Diffing

Given two envelopes A and B, the *diff* A → B is an incremental set of transformations that transform A into B.

The Diffing extension provides a way to compare two envelopes and produce a diff (which is also an envelope) and then apply a received diff to the source envelope to transform it into the target.

### SSKR: Sharded Secret Key Reconstruction

SSKR can be used to implement social recovery of sensitive information using Shamir’s Secret Sharing.

Any envelope can be *sharded* to a set of *shares*, each of which contains the encrypted envelope and a single share of the key used to encrypt it. These shares are then sent to trustees in the event of loss of the original information.

No single share can be used to recover the original data. Rather, a quorum of shares (for example, 3 of 5) must be recovered in order to recover the key and hence the entire original envelope.

### GSTP: Gordian Sealed Transaction Protocol

Gordian Sealed Transaction Protocol (GSTP), is a secure message-passing architecture that combines numerous features of Gordian Envelope to enable secure, scalable and efficient communication between peers, or clients and servers.

The system utilizes encrypted and signed requests and responses, encrypted state continuations (ESC), and idempotent actions to provide a robust and scalable communication model.

It also includes mechanisms to prevent the misuse, malicious manipulation, or replay of responses.

GSTP is channel agnostic, and can be used in secure communication protocols that switch channels between Internet, NFC, Bluetooth, and even QR codes.

## Use Cases

The functionality of Gordian Envelope can be used to support numerous data-management use cases. We've worked the most closely so far on use cases for health care, journalism, credentials, and software releases.

Health care deals with incredibly sensitive and personal data. Gordian Envelope allows for the encryption of health data when it's sent to providers and the redaction of personally identifiable information when data is submitted to clinical studies or for other public health purposes. Yet, all of this data remains provable, allowing providers or clinical studies to ensure the validity of the content.

Journalism can often be dangerous for sources and journalists alike. Gordian Envelope can redact personally identifying information, from a source's name to the location where a picture was taken. Again, the data remains provable for checks made by a publisher (and later for court cases, if needed).

Digital credentials are growing increasingly important, but they often contain an excess of personally identifiable information. Gordian Envelope allows a holder of a credential to redact information to allow data minimization, releasing only the data actually needed from the credential. Gordian Envelopes also allow for the creation of herd privacy, where a credential is released as part of a large set and only acknowledged and used by a the credential's subject if they so desire.

Software releases create issues of trust, where a release administrator might want to hide their personally identifiable information, but later acknowledge it, or where one release administrator might want to empower another. Gordian Envelope enables the first through its provable redaction and the second through its signatures of keys.

Overall, any use case where some data is sensitive or where it is personal, where data minimization is desired, or where trust is important might be improved by Gordian Envelope. These are just the tip of the iceberg.

## Summary

**Forthcoming**