PDaSP NSF Proposal #2 - SUBMISSION

--- robots: noindex, nofollow --- # PDaSP NSF Proposal #2 - SUBMISSION ## Gordian Envelope Toolkit ### Project Summary (1 page) Here is a brief write-up intended to inspire some headline about the broader potential downstream impacts.  -> Delete or modify as you see fit. If you see some fuzzy approximation of meaning and would like me to rewrite part/wholes of it; please provide a quick comment or ask and I will do so. My colleague  has offered to take a quick look. Impact Abstract: For the last fifty years, emerging global systems have been hamstrung by trust. In particular a binary signature construct has meant that trust has remained stuck in the feudal castle and moat mentality. This has forced corporations and individuals to rely on staff labor, expensive contractual agreements and 3rd party software management tools to live in a world where digital identity has been ‘broken’ leaving individuals and enterprises left to pull together the shards for bespoke purposes ab initio each time. More generally, the internet is today a ‘trust no one’ kind of dark alley. There is no illumination or way to know whether a website is what it claims to be and this leads to massive opportunities for nefarious actors which in turn requires significant economic friction across all scales of social economic systems. From spear phishing to national misinformation campaigns there are few problems that aren’t traceable to our current inability to create networks of trust outside of analog institutional foundations that would be familiar to kings with armies in castles. ### Gordian envelops promise to replace the need for legal enforcement with programmatic trust. While the advent of the DIDs as a IETF/W3C standard opens up possibilities for individuals to manage their own identity and for groups to create shared identity, the latter remains limited by the inability to articulate human social constructs of trust digitally. Most broadly understood, the tragedy of the commons that is our emerging age of consequences is a direct result of lacking accountability in well regulated networks for payments that lack facilities to prevent true total social accounting of local economic activities. Gordian envelopes, as a recursive structure, can build on the DID to reduce the friction of identity and trust management while simultaneously providing a foundation and path for addressing the grand wicked challenge of evolving our economic to a sustainable modality where the collective and community global to local interests can be reflected programmatically in individual to individual transactions. **Overview** Gordian Envelope is a scalable privacy-preserving data-interchange format for data-at-rest that allows holders of data to secure credentials, digital assets, and other sensitive data and also to redact some or all of their contents to maintain privacy and ensure data minimization. Even after data is redacted, the existence of that redacted data can still be proven and signatures that were made across that data remain valid. This Track 3 PDaSP project will facilitate widespread adoption and testing of Gordian Envelope’s privacy features via publicly accessible toolkits and testbeds. It will allow developers and users to learn about herd privacy and to experiment with the privacy elements of their data sets with a focus on real-world deployments for verifiable peer credentials, secure software releases, and validated AI model training data. **Intellectual Merit** Gordian Envelope offers an innovative methodology for data interchange that maximizes individual privacy. It allows practical usage of data minimization, supports variable levels of correlation, enables user redaction of validated data, and facilitates individual creation of inclusion proofs for redacted data—offering a system where data can simultaneously be publicly hidden and privately proven or revealed. The Gordian Envelope Toolkit that is the heart of this NSF project will translate Gordian Envelope functionality into a robust, user-friendly testbed for researchers and developers, supporting hands-on experimentation with scalable, privacy-preserving techniques for data sharing. Enhancing Envelope’s viability for mainstream deployment is crucial for advancing practical, real-world applications in privacy-centric environments as much of this capability is not currently widely available. In particular, herd privacy, an innovative privacy method incorporated into Gordian Envelope that enhances privacy by masking individual data within a larger aggregated dataset while preserving verifiable proofs, has been little studied and is of considerable intellectual interest. **Broader Impacts** Anyone possessing a Gordian Envelope can redact some or all of the data stored within. This creates the real-world opportunity for data minimization—a privacy measure that is strongly suggested but rarely sufficiently defined and almost never mandated in the current information ecosystem. When individuals can choose what of their own data to distribute, they can leverage its power as they see fit, rather than large corporations being the only ones to benefit. Gordian Envelope’s data security features, including selective redaction and encryption, can also give businesses a competitive edge in navigating stringent current and emerging data protection laws while enhancing user trust. ### ### Project Description (15 pages max) **Introduction to Gordian Envelope** Gordian Envelope, which has been developed by Christopher Allen and Blockchain Commons over the last few years, is a scalable and secure privacy-preserving data format. It lies at the data-interchange layer between systems and focuses on data-at-rest. It’s the next step in ensuring the privacy of data on the internet. In the ‘90s, Christopher Allen’s work as the coauthor of the IETF TLS international standard created a global privacy best-practice for data-in-transit. Gordian Envelope similarly aims to set a global benchmark for privacy-preserving technologies in data-at-rest, ensuring comprehensive protection across diverse industry sectors. It also empowers the individual user (not just the data issuer), by supporting their ability to make privacy and data minimization choices, giving them the ability to redact Envelope-encoded data while still maintaining proofs and validation for that data. Gordian Envelope is not a database. Instead, it is a data-interchange security format that ensures the integrity, privacy, and controlled disclosure of that data. It excels in scenarios requiring a careful balance between transparency and confidentiality, such as employment, healthcare, finance, and cross-jurisdictional data exchange. Gordian Envelope stores data as a series of semantic triples: subject-predicate-object. The model is recursive: new assertions of predicates and objects can be added to any element within an Envelope: to the subject, the predicate, the object, an assertion as a whole, or the envelope as whole. This creates a simple but elegant and deep structure that allows Gordian Envelope to provide a superset of functionality encompassing a variety of different data models, including simple graphs, RDF graphs, and many others. It can also emulate JSON-LD, providing compatibility with existing applications. The semantic triples of Gordian Envelope are represented as a Merkle-like Tree (a binary hash tree), which is then encoded with dCBOR, our own deterministic application profile for the IETF CBOR standard. Each element of a triple, as well as a hash of that data, is embedded as a leaf within the tree. Nodes then combine hashes of their leaves, up to the root hash, which provides a hash for the tree (and Envelope) as a whole. Signatures used to ensure the validity of the data are made across the hashes, not the data itself. When data is redacted (or optionally, compressed or encrypted), the hash is not affected. This means that signatures can still be verified, and thus the data can still be validated. This allows any holder of data to make their own privacy decisions by redacting whichever data they want. This is the heart of Gordian Envelope’s user-focused data privacy system. Any data holder can redact data, including the issuer of the data, the subject of the data, and any number of entities properly using the data. They each will have different requirements and different needs. Gordian Envelope ensures that each entity’s data redaction represents those specific needs. This enhances each user’s individual capabilities, granting them powers that they do not have now, whether it be to reduce their liabilities or increase their privacy. This also largely matches the principles of privacy by demand: it supports transparent user-centric privacy decisions that are proactive and preventive. Even after data has been redacted, its existence can still be proven thanks to Gordian Envelope’s hashed data-elision system. This allows data to remain valuable and relevant while still maintaining privacy as preferred by the data holder, based on their own requirements and needs. Several interrelated privacy features are of note in this system. * **Correlation.** If multiple parties know the contents of an Envelope, they can prove those contents using correlation simply by hashing the known data and comparing it to the hash in a redacted Envelope. This allows for proof of existence without sharing the actual data, which can be quite beneficial for compliance situations, for example between a student loan company and a university. * **Anti-Correlation. **Sometimes, the ability to correlate by “guessing” the contents of an Envelope via correlation is not desired. Gordian Envelope therefore balances its correlation ability with anti-correlation technology. Best practices suggest ways to structure an envelope to prevent correlation. Salting (the introduction of random numbers into the data structure) and other techniques can also foil correlation. * **Inclusion Proofs. **A data holder can prove the existence of some datum within a partially or fully redacted Gordian Envelope by demonstrating the datum in question, showing its hash, and then revealing the sequence of hashes that leads from a leaf in the tree with that hash up to a published hash for the tree (which might be the root hash or the hash for a redacted branch). Essentially, the data holder provides all the information needed for another user to correlate data within the Envelope. The methodology to create an inclusion proof is straightforward, but technical. Therefore, making it easy to create an inclusion proof is one of the clear requirements for a Toolkit that would make Gordian Envelope technology more accessible. * **Herd Privacy. **Aggregating data in large packets and then only publishing the root hash of that data packet supports “herd privacy”, where individual data is entirely redacted, but where individuals are given inclusion proofs so that they can demonstrate their participation in the data set only if and when they want to. Credentials are a prime example where herd privacy could be used: all graduates of a college or takers of a course could be collected into a single data packet in a Gordian Envelope. * **Progressive Trust. **Not all data revelation will come through inclusion proofs. A user can also progressively transmit less-redacted Envelopes (containing more unredacted data). This process is called “progressive trust”, where more information is revealed as participants in a conversation become more comfortable with each other (and with the proofs of who each entity is). Though the fundamental aspects of Gordian Envelope concentrate on its ability to store, redact, and transmit data, it is very extensible, with those extensions available for usage (or not) depending on an individual’s needs. Current extensions for Gordian Envelope include: compression, encryption, secret sharding, diffing, private attachments, functional expressions, and the Gordian Sealed Transaction Protocol for communication over insecure or unreliable protocols. More extensions can be added by either Blockchain Commons or by third parties at any time, future proofing the design of Gordian Envelope. This is all done in a very scalable manner. Gordian Envelope is built to run on very constrained devices. For example, its Encrypted State Continuation feature (an element of its Gordian Sealed Transaction Protocol) was built to support embedded systems that don’t have the resources to maintain local state. Meanwhile, Envelope’s more complex extensions and future-proofed design can (in the future) incorporate new encryption and signing algorithms, ZK-proofs, and emerging anti-correlation tech and also support high-end servers. A fundamental design principle of Gordian Envelope is that “You only pay for what you use”, meaning that extensions are available for those higher-end uses, but they don’t impact usage of Envelope on constrained devices. Gordian Envelope has been fully specified as an Internet-Draft available through the IETF and has gone through several revisions thanks to discussions with the CBOR Working Group in the IETF and with hardware designers and software developers at Blockchain Commons’ own Gordian Developer meetings. A command-line reference app demonstrating its functionality, called the envelope-cli, and an iOS app that incorporates Gordian Envelopes, called Gordian Seed Tool, are also available now for usage. However, the challenge with privacy-focused technologies is always to get them into widespread usage. Our proposal addresses this by bridging the gap between our current theoretical models and new proposed real-world implementations, in direct alignment with NSF 24-585’s goal of translating privacy technologies into scalable, practical applications. Our fundamental technology is relatively easy to deploy because it acts at the data-interchange layer and uses pragmatic cryptography (while also providing support for emerging cryptographic systems). We’ve already built reference libraries in a variety of languages to support this. Our next step is to create accessible tools and testbeds that are more accessible than our current command-line reference app—tools that not only demonstrate the usage of Envelope but also offer real-world application for software publication and peer credentials that can be put to immediate use. This is the foundation of the Gordian Envelope Toolkit that we are proposing for support from the NSF. **The Gordian Envelope Toolkit** The goal of this NSF project is to create web-based online testbeds & toolkits that will improve the adoption of Gordian Envelope by providing live demonstrations of Envelope functionality and creating the possibility for real-world usage in two important categories: peer credentials and software publication. Availability of this sort of playground has been very successful for other software deployments: the Verifiable Credentials Playground was used during the creation of the W3C Verificable Credentials standard to support learning about the emerging specification (today a full W3C recommended standard). The VC Playground reference implementation allowed developers to verify conformance and supported the formulation of accessible and shareable schemas and models that developers could use to test their own proofs of concept. It was a large driver in the design and later popularization of this credential format. We want to do the same for Gordian Envelope, but also to exemplify some of its real-world utility and some of its most innovative features, providing an on-ramp to our privacy-focused data-interchange model for users and developers alike. The core functionality of the web-based toolkit will make the privacy-focused capabilities of Envelope available via a web interface as part of an Envelope Playground. It will: 1. **Create Credentials. **The Toolkit will allow the creation of simple credentials that can refer to a person’s qualifications, relationships, publications, personhood, or other topics. 2. **Salt Credentials. **Individual credentials can have salt applied appropriately where there are concerns over correlation. 3. **Sign Credentials. **For credentials to be meaningful, they need to be signed, offering the signer’s validation of the credentials. The Toolkit will allow signing using a variety of methods including: private key created by the Toolkit, private key held by the user, and passing of a credential to another user for signing with their own private key. As always, the goal will be to make these methods simple and accessible. 4. **Redact Credentials.** The power of Gordian Envelope lies in the privacy and data minimization allowed through redaction of some or all of the credentials. The Gordian Envelope Toolkit will make these privacy-enhancing features intuitive and accessible via a user-friendly graphical interface, lowering barriers to adoption for both developers and end-users. 5. **Create Existence Proofs. **Users will be able to automatically create existence proofs for data they are redacting from their credentials. 6. **Format Outputs. **Envelopes and existence proofs will be output as QR codes, UR text (Uniform Resources, a URI-style format), CBOR binary objects, or as Envelope Diagnostic Descriptions. 7. **Verify Credentials. **Users will be able to upload credentials previously created by the Toolkit (or another Envelope-compatible app) to verify their completeness and to validate any signatures. 8. **Prove Existence. **Users can also upload an elided credential and an existence proof. In this case, the Toolkit will both say what the existence proof demonstrates and whether it is indeed part of the credential. With this core functionality in place, developers will have an accessible testbed that will allow them to experiment with Gordian Envelope, a best practice for how to deploy Envelopes, and a validation system that can be used to test their own work. However, our plans for the Toolkit go beyond that, with four overlays for the Toolkit that will empower two real-world usages of Envelopes, to further support actual deployment, and two more abstract usages of Envelope, to act as an advertisement and proof of concept for some of Envelope’s most innovative features and most cutting-edge usages. Real-World Usage: Peer Credentials (Pilot) The most closely-aligned overlay for the Toolkit will be a “peer credentials” website where users can attest to personhood, experience, skills, reputation, or jobs for others. Think of it as a White Pages that verifies real persons (as opposed to corporations or AI), a Linkedin that provides attestations for broader skill ranges, and a Trader’s Guild that can help spotlight trustworthy sellers on eBay, Amazon, or Facebook, all with validated (signed) content. Our goal will be to provide the basic functionality, and then orient it in the direction that is generating the most interest and attention. The creation and signing of credentials will require only a simple and superficial overlay atop the core Toolkit functionality, but three elements will require additional work. \ First, additional work will be required to truly train users in the use (and usefulness) of redaction. We expect that the common workflow will be either for a data subject to create a credential and get it signed or for an attestor to create and sign a credential for a data subject, and then for the credential subject to hold the credential until needed. Either process must be offered in a simple, automated way, giving the user clear guidance on the credential creation process and offering them clear choices. Further explanations of how, when, and why you would redact your credential need to also be displayed during this workflow—and possibly even as part of the credential metadata. The goal here is, after all, to promote the use of the privacy-focused elements of Envelope, not just its ability to encode data. Second, our ultimate expectation is that credentials will need to be redacted only when a subject is sending them out to people who need proof of the subject’s expertise: for privacy-protecting reasons, the subject will want to redact all data other than what is required for a recipient. The peer credentials site must also support this workflow by allowing credentials to be uploaded and then redacted, and perhaps even directly sent on. In turn, the new holders of the redacted data (for instance an employer) may choose to redact further. Third, a peer credentials site will only reach its maximum utility if it has good integration with Public-Key Infrastructure (PKI) so users can know who signed a credential. The Primary Investigator for this project was an architect in the design and development of the Decentralized Identifier (DID) international standard at W3C, so support will be offered for one or more DID methods. Integration with proof of control of accounts or websites may be another option (so, for example, a credential could be signed by the proven controller of a website, a Twitter account, or a Facebook account). Again, the goal is to make things very accessible, so the peer credentials website would need to allow that recipient to upload a credential and then to see who signed the credential and what DID, sites, or accounts they had proven control of. The result of this Toolkit overlay should be both a testbed for Envelopes and a real-world functional pilot for credentials created as part of a peer-to-peer web of trust. Real-World Usage: Software Releases (Pilot) Software releases are another field that clearly requires credentialing. GitHub, the top site for today’s open-source software projects, offers some minimal support of this through the association of signing keys with accounts. It allows users to see whether a particular commit was signed by a key associated with an account or not. However, more is needed, particularly for tagged releases. A second overlay built atop the Toolkit will support this through another real-world testbed. The software-release testbed website will allow users to tag and sign GitHub releases, checksum releases, and sign checksums, offering a powerful proof that a tagged release was created by a valid user and not someone who has since taken over a GitHub account. \ The main expansion over core Toolkit functionality will be a chained signed system. Linked command-line tools will allow a developer to create a fresh repo with an “inception commit” that includes a signature. Any signatures with that signing key will then be traceable to not just a GitHub user but also the original declaration of identity for the repo (essentially making it into a GitHub-focused DID method). The software-release website will then allow the upload of new public keys that have been signed by the inception key, or even new public keys that have been signed by previous keys that ultimately chain back to the inception key. The object is to allow for signing keys to change over time, while still providing validation that links back to the repo’s inception. This sort of chaining is crucial for open-source projects whose membership might change over time. The software-release testbed will incorporate Envelope’s privacy-focused functions as well. PI Christopher Allen is one of the co-editors of the Amira engagement model published by W3C. It imagines a software-release use case where a developer might wish to redact their Personally Identifiable Information (PII) for reasons of prejudice or for the safety of a family member living in a totalitarian regime, but where they might wish to reveal their link to their private developer ID at a later time. The software-release testbed will support the full empowerment of this privacy-based engagement model, allowing software signers to stay anonymous while validating releases and to later declare their anonymous identity if they wish. Abstract Usage: AI Provenance (Proof of Concept) The software release testbed will also offer parallel usage for AI models, with a proof of concept for AI usage to be published either as part of the software-release overlay or as a separate overlay site. Licensing data for model creation is becoming more important for AI systems in the face of current court cases. Ensuring that data is validated is also a growing issue, as shown by current Large Language Models (LLMs) that might tell you to put glue on a pizza due to the inclusion of a humor site or that more seriously might misidentify mushrooms for consumption due to false information found on the web. The Envelope system can provide ways to validate ownership and legitimacy of all parts of an AI data model while simultaneously protecting the actual content through redaction. This AI functionality is unlikely to be a real-world toolkit, like the software release toolkit, unless we reach an agreement with an interested AI developer during the course of the project. Instead the abstract proof-of-concept will discuss best-practice uses of the software for supporting AI models and will allow hashing of AI model training data, creation of validation and licensing statements, and signature of all those elements, creating simple, sample Envelopes that demonstrate provenance for AI models. Abstract Usage: Herd Privacy (Proof of Concept) The final overlay for the Toolkit will demonstrate the usage of Gordian Envelope to create Herd Privacy without an attempt to turn it into a real-world deployment site (as we expect Herd Privacy creation to be large-scale and beyond the scope of what we can support for actual usage). This overlay site will talk about herd privacy and its benefits and then support a live-demo of a multi-step process to enable Herd Privacy: 1. Upload a credential (possibly linking through to the peer credentials site to allow for the instantaneous creation then linking of a credential). 2. Multiply that credential by creating similarly structured sample/testbed credentials. 3. Demonstrate how different structuring can improve privacy through anticorrelation. 4. Demonstrate how salting can improve privacy through anticorrelation. 5. Fully elide credentials. 6. Publish a root hash. 7. Provide an inclusion proof for the user demonstrating how their original credential can be proven using the root hash. Unlike the pilot sites, the herd privacy toolkit is entirely intended as a reference testbed, but it should be a sufficiently developed testbed to both show why herd privacy would be useful (through strong documentation) and how it could be created using Gordian Envelope (though the above example). This live demonstration is intended as another means to improve the adoption and usage of Gordian Envelope as a privacy-focused data storage method. Documentations & Videos The Gordian Toolkit and its overlay websites will provide hands-on usage for the privacy-focused features of Gordian Envelope, but we also recognize the need to document it in ways that will make it even more accessible to end-users and to developers. \ For end-users, that means the integration of excellent how-tos, best practices, examples, testimonials, and other documentation into the sites themselves, to create an integrated experience that makes each site easy and accessible to use. For developers, that means doubling down on our existing developer documentation (which focuses more generally on Envelope) in order to highlight our new websites, why developers should be interested in them, and how developers can create their own credential, software-release, herd privacy, and AI provenance systems. Besides written documents, we also have extensive experience creating professional teasers and videos to highlight our software for people not content with written works. We’ll take full advantage of that to highlight the new Gordian Envelope Toolkit systems. Our scheduling for this project plans documentation throughout the development, but then focuses on closing out documentation over the several months after the Toolkit and all its overlay websites have been deployed. Metrics The Gordian Envelope Toolkit will maintain metrics on the core site and the testbeds that detail Envelope performance (e.g., how long it took to create or redact Envelopes or create inclusion proofs) and the usage of privacy-focused features (e.g., how much encryption is used, how much redaction is used, how many inclusion proofs are produced, etc.). By publishing this information as part of the core testbed, we can offer another argument for the adoption of Envelope, thanks to the rapidity of performance and hopefully due to strong usage of privacy-focused features. Timeline This project is laid out as a 2-3 year project. Engineering work is intended to span a two-year period. The last year is then dedicated to documentation and UX improvement, potentially responding to user interest and requirements. The rough timeline for engineering work is as follows: * Initial Toolkit Engineering (8 months) * Peer Credentials Pilot (6 months) * Software Releases Pilot (4 months) * AI Provenance Proof of Concept (3 months) * Herd Privacy Proof of Concept (3 months) Graphic design, UX design, and documentation are to follow each engineering release, with initial work (and deployment) for the initial toolkit to follow by 4-6 months and initial work (and deployment) for each overlay to follow by 2-3 months. At the end of the three-year period, the sites should be both stable and static. We hope to be able to maintain a production server for the testbeds into the immediate future, but in any case all of the source will be permanently available in open-source repos (GitHub), allowing for deployment by any interested party. Excluded Topics The Gordian Envelope Toolkit, as it will be supported by this NSF grant, will not include the following elements: * Post-Quantum Cryptography. Envelope does not currently support PQC, but its extensible architecture ensures future readiness, allowing easy integration of PQC when needed. We recently demonstrated this flexibility when we added SSH as an additional signature method past our core ECDSA and Schnorr signature schemes. * Non-Correlatable Signatures. Other emerging cryptographic privacy-preserving technologies such as ZK-proofs are not currently supported, but similarly could be added in the future. * Differential Privacy. Envelope is not designed to support aggregated or statistical analysis of its contents, but instead to redact data (or not) on an individual basis. Again, the architecture allows the support of DP as an extension in the future. * User Advocacy. Though there will be user-focused documentation on how to use the testbeds, there will not be advocacy encouraging users to adopt PETs beyond the specific pilot usages. Instead, this need will be met with developer-focused advocacy via international standards groups as well as integration of best practices and user-experience suggestions into the testbeds, to advocate for the creation of user-interface designs that are more likely to be used and therefore facilitate adoption. **Benefits of a Successful Project** We will have three criteria to measure the success of our project. 1. Widespread usage of the real-world-usage websites for creating peer credentials and supporting software releases. 2. Widespread developer usage of the abstract exemplar sites for herd privacy and AI provenance. 3. Developer deployment of new Envelope-based PET systems. Over the course of this project, we expect to tweak and adjust the specifics of our deployments if certain elements are more or less popular to users and to developers, in order to assure that we meet these criteria. The final goal represents the fact that we want to support the successful deployment not just of these websites, but of privacy technology generally. Here, we think that Blockchain Commons’ vision is very much in tune with the goals of NSF 24-585. We want people to control their own digital destiny and maintain their human dignity online, and we think that will happen through the real-world deployment of tools to assist users in making privacy-focused decisions. We want these privacy-focused decisions to be transparent and user-centric, and we think we can support that by expanding our extant and mature Gordian Envelope technology with practical, real-world deployments. Each of the five major elements of this project is intended to provide benefits that move us along that path. 1. The Gordian Envelope Toolkit. The core playground will make our Envelope specification available in an accessible, intuitive, easy-to-use fashion that will reach a much larger population than our existing command-line (CLI) toolkit. Developers will be able to use it to testbed ideas and to verify their own implementations as they advance Envelope into new industries. 2. The Peer Credentials Overlay. Our peer credentials website will offer a real-world deployment of Envelope that will offer the first opportunity for it to go into much wider usage through a well-received pilot. Developers will also be able to use this as the foundation of their own credential systems. 3. The Software Releases Overlay. We’ve identified a critical need for enhanced validation and security of open-source software releases. Gordian Envelope can directly address this by securing code review and other attestations and by allowing developers to naturally integrate this system into their release process. As with the peer credentials overlay, the software releases overlay will drive interest in the privacy-protecting features of Envelope through widespread user demand. We think it’s a particularly important testbed because we’ll be influencing developers who are actually creating systems. 4. The AI Provenance Overlay. AI is a hot topic, so we think addressing it is a great way to bring more developers into the fold. By demonstrating how to validate data within AI model training data while protecting its privacy, we’ll create a strong foundation for adoption and usage by any AI model creators. 5. The Herd Privacy Testbed. Herd Privacy is one of the most expansive innovations of Gordian Envelope and therefore an idea that will be innovative to many developers. The Herd Privacy testbed will specifically describe the idea and make it concrete through hands-on demonstration, turning it into an actual tool for many developers, giving them a reason to adopt Envelope and start partaking of all of its privacy-focused advantages. \ Overall, the intended benefit of the various elements of the Gordian Envelope Toolkit project is to increase the demand for privacy-protecting technology, since we know that’s the biggest stumbling block in privacy deployment: users, and even developers, don’t yet see the demand for this crucial methodology. But if we can show users how they can easily limit data disclosures to what’s required (peer credentials), if we can show developers how the security of their software publication can be ensured (software releases), if we can show developers how Envelope can integrate with important new AI content (AI provenance), and if we can show developers how to hide data among the masses (herd privacy), then we encourage them to use technology like Envelope. \ We think that these testbeds highlight some of the most compelling arguments for the privacy-protecting capabilities of Gordian Envelope that can be incorporated into widely used testbeds. There are certainly some even more compelling arguments for very specific industries such as journalism and supply-chain shipping logistics. We hope that partnership with these and other industries will come out of these more general testbeds, supplementing work we’ve already done in the healthcare and data-assets industries. However, that lies beyond the scope of this NSF project. For now, our goal is to provide the most general references that are more likely to attract and interest the largest groups of people, especially developers. We don’t believe that *all *of these deployments need to be widely successful in attracting public interest. If one or two of them are, that should have the intended benefit of bootstrapping Gordian Envelope up to the next level where additional external developers are building specific, deployable, real-world projects and gaining privacy-focused benefits in doing so. **Broader Impacts** The mass-market adoption of Gordian Envelope will be driven by clear benefits to data-driven companies, particularly in privacy-sensitive and confidential industries such as finance and healthcare. Gordian Envelope can support common situations where it’s crucial to consider what data is being stored and what data is being redacted, such as cross-border / cross-jurisdiction data transfers. It can also reduce the impact of data breaches, because when there is a breach, less data will be lost due to redaction. Gordian Envelope’s features are particularly advantageous in industries such as supply-chain logistics, where secure, privacy-preserving data exchanges are essential. Multiple parties can validate a data entry without needing to access its full contents, simultaneously ensuring confidentiality and transparency. The Envelope’s privacy-by-design framework facilitates a critical balance in complex, multi-party interactions between protecting sensitive information and fostering necessary collaboration, enabling efficient operations in competitive environments while safeguarding proprietary data. Gordian Envelope also improves and simplifies regulatory compliance for data directives. This will generate clear economic benefits for companies domiciled in the United States, particularly in relation to the European Union and its strong GDPR requirements for the privacy of personal data. Using Gordian Envelope, US companies will be better able to comply with the GDPR (avoiding major fines such as those now faced by Facebook and Amazon) and they’ll also be better able to better compete with European companies that have already had several years to get a leg up on privacy-focused data management. With that said, we feel that Gordian Envelope’s most important impact may be the positive societal outcomes that it offers, which were core to our developmental process. That positive impact will come from its introduction of data minimization as the default scenario for data transmission. There should no longer be a question of exchanging user data wholesale between organizations. Instead, there will be an expectation that data will be redacted such that only necessary data is sent. If more is needed later, it can be added through the process of “progressive trust”. Because this capability is easily usable within Gordian Envelope, we hope it can be leveraged into the introduction of rules and regulations about data minimization. We will actively advocate for the broader adoption of data minimization and privacy-by-design standards through ongoing collaboration with legislative bodies, international standard organizations, and industry groups, driving real-world policy impact. (We already have experience working with all three sorts of entities.) This will establish user privacy as a default standard, transforming how personal data is handled across industries. It will protect people from their data being sold and their data being correlated in gigantic data-mining machines, because that data simply won’t be there when Gordian Envelope is being used correctly. Besides abstract improvements to users’ privacy, this will also create very real improvements to their safety, because personally identifiable information such as addresses and phone numbers (which are currently very easily available on the internet for most people) will become less accessible, particularly over time. It also will introduce individuals to the idea of being able to personally control their own information, including both data and credentials. This is a crucial human-rights advance that moves users toward self-agency and empowerment, while still maintaining individuals’ presence as members of a larger community. Our focus is on driving real-world impact by promoting data minimization, privacy compliance, and user agency through innovative PET solutions. This impact will be clearly measured through public usage of the Gordian Envelope testbeds, via lower counts of lost data in privacy breaches, and through lowered fines on companies for those breaches. **Project Justification** The basic research on hash-based redaction (generally) and Gordian Envelope (specifically) is done. We published an Internet-Draft through the IETF and have taken it through 7 minor revisions as of this writing. We have also published research papers on multiple Envelope extensions including attachments, compression, cryptographic seeds, symmetric cryptography, public key cryptography, functional expressions, graphs, known values, open transport protocols, and sealed transport protocols. We’re now looking to translate that basic research into specific use models, which is a perfect match for the PDaSP program: Gordian Envelope is entirely focused on privacy-preserving data sharing, and we now want to put that into practice. In order to truly translate our basic research into practical, real-world usage, we need to demonstrate the importance and ease-of-use of our privacy features. Our package of user-facing, web-focused testbeds does exactly that. The core Gordian Envelope Toolkit allows extensive, easy-to-use graphical interaction with Gordian Envelope capabilities, then the overlays will encourage user involvement (the peer credentials & software releases sites) and demonstrate new capabilities (the AI provenance & the herd privacy sites). We think these means are exactly what is required to foster the PPDSA solutions of Gordian Envelope, and we’re confident that doing so will also democratize privacy solutions because of the implicitly democratic nature of Gordian Envelope: it’s all about empowering the user and ensuring that their fundamental human rights are preserved in the digital realm, which is in accordance with Blockchain Commons’ own mission statement. Our goal with Gordian Envelope is ultimately to allow individual users to leverage the benefits of their data, not just huge organizations. **Overall Project Management and Collaboration** The Gordian Envelope Toolkit project team of Christopher Allen, Wolf McNally, and Shannon Appelcline has been intensely focused on this privacy-preserving data solution for the last few years, has successfully shepherded it through discussions at the IETF and with other groups, has worked with other companies that are beginning deployment of Envelope technology, and is innately the most familiar group with the concept. The group includes architecture, engineering, videography, and user-focused documentation expertise. The chief architect and PI, Christopher Allen, has extensive experience with privacy-focused technologies, some of it visionary and generative, such as his paper “The Path to Self-Sovereign”, which kicked off the idea of self-sovereign identity. He has successfully incubated two major protocols: IETF TLS, which today ensures the privacy of banking, shopping, and almost all other interactions on the internet; and W3C DIDs, or decentralized identifiers, which are a new and growing technology that makes the idea of self-sovereign identity concrete. Christopher was a performer on the DHS S&T SBIR (Contract #HSHQDC-16-C-00061; Program Manager: Anil John) that laid the foundation for Decentralized Identifiers (DIDs) to become globally adopted. He is also an invited expert to the new W3C DID working group, an editor for the DID resolution spec, and an invited expert to the W3C Verifiable Credentials 1.1 working group. Christopher has worked with a number of companies over the years focused on user-empowered privacy, among them Blockstream, Blackphone, and Blockchain University. Wolf McNally is an engineer and researcher who has co-authored most of Blockchain Commons’ specifications and engineered all of its major tools to date. Shannon Appelcline is a technical writer focused on decentralized technology, whose largest scale works include the “Learning Bitcoin from the Command Line” course and the *#SmartCustody* book, both co-authored with Christopher. Though small, the Gordian Envelope Toolkit project team works with a larger community to ensure that Gordian Envelope meets the privacy and security needs of real-world developers and publishers. We hold monthly Gordian Developers meetings where we talk with developers about their current progress and requirements and where we request input on our own work. Some of our Envelope extensions have already been revised due to comments from that community. We also engage regularly with global thought leaders in data privacy, security, cryptographic protocols, and blockchain development, both in workshops that we facilitate and host (Silicon Salon, FROST workshops) and where we have leadership roles in (Rebooting Web of Trust), as well as when we’re invited to speak on these topics at academic and industry conferences. These speaking roles are part of our regular interaction with industry organizations and international standards organizations such as W3C and the IETF. Our work with IETF has been the most important recently because expert feedback there resulted in revisions to our specifications for both Gordian Envelope and dCBOR—the latter being a CBOR application profile that we created to support the determinism necessary to maintain Gordian Envelope hashes. We will expand these interactions over the course of an NSF project with planned attendance and possibly presentation at conferences such as IETF, IEEE Symposium on Security and Privacy, Real World Crypto, and Privacy Enhanced Technologies Symposium, so that we can influence researchers as well. Finally, we also work with a number of companies who are interested in adopting Blockchain Commons’ specifications, including Gordian Envelope. Past and present partners of this sort have included Bitmark (a digital-assets company), Chia (a digital-currency company), CrossBar (a chip maker), Digital Contract Design (a smart contract company), Foundation (a hardware wallet manufacturer), Proxy (a smart ring manufacturer recently acquired by Oura), Unchained Capital (a financial services company), and many others. Some of our earliest specs such as URs and Animated QRs (both of which are integrated with Envelope) have been deployed by over a dozen companies. We have also received multiple grants from the Human Rights Foundation for our work in this space. We expect to bring in external contractors for some new expertises required by this project, such as graphic and UX design and system maintenance, drawing either from past interns or past partnerships. In short, our small, agile team at Blockchain Commons provides the core expertise and the connections that we require to translate our privacy-focused data-interchange system into more practical real-world uses. Our partnerships, our developer links, and our standards-group work will ensure that we’re looking at the larger picture and providing toolkits and testbeds that genuinely match what’s needed by the larger world. \ We look forward to this opportunity to make the research and development we’ve done so far on user-focused and privacy-focused data management into a real-world system that can change how data is stored (and transmitted) online. ## References Cited Allen, Christopher. 2016. “The Path to Self-Sovereign Identity”. *CoinDesk*. [https://www.coindesk.com/markets/2016/04/27/the-path-to-self-sovereign-identity/](https://www.coindesk.com/markets/2016/04/27/the-path-to-self-sovereign-identity/). Andrieu, Joe & Christopher Allen. 2019. “Amira: A Self-Sovereign Web of Trust Engagement Model”. W3C. [https://w3c-ccg.github.io/amira/](https://w3c-ccg.github.io/amira/). McNally, Wolf & Christopher Allen. 2022. “The Gordian Envelope Structured Data Format”. *IETF Data Tracker. *[https://datatracker.ietf.org/doc/draft-mcnally-envelope/](https://datatracker.ietf.org/doc/draft-mcnally-envelope/). Sporny, Manu, Dave Longley, Markus Sabadello, Drummond Reed, Orie Steele & Christopher Allen. 2022. “Decentralized Identifiers (DIDs) v1.0”. W3C Recommendation. [https://www.w3.org/TR/did-core/](https://www.w3.org/TR/did-core/). Uncredited. Retrieved 2024. “Developer Resources: Gordian Envelope”. Blockchain Commons Developer Resources. [https://developer.blockchaincommons.com/envelope/](https://developer.blockchaincommons.com/envelope/). Uncredited. Retrieved 2024. “Our Vision”. Blockchain Commons website. [https://www.blockchaincommons.com/vision/](https://www.blockchaincommons.com/vision/). Uncredited. Retrieved 2024. Verifiable Credentials Playground. [https://vcplayground.org/](https://vcplayground.org/). Various. Retrieved 2024. “Research”. Blockchain Commons GitHub Repo. [https://github.com/BlockchainCommons/research/?tab=readme-ov-file#blockchain-commons-research](https://github.com/BlockchainCommons/research/?tab=readme-ov-file#blockchain-commons-research). ## Budget and Budget Justification [500k-1.5M for up to 3 years] [budget justification, up to 5 pages] [see spreadsheet for content] [we need to lock down numbers and then see how they’re filled in as part of the project submission. [I suspect that I’ll need to write up justifications either per item or overall, but don’t yet know the format. #### **Facilities, Equipment and Other Resources** Blockchain Commons is a remotely organized, virtual company. It is incorporated in Wyoming and its PI is located in California. Regular contractors are scattered across other western states. As such, it does not maintain any central offices and its principals and contractors provide their own equipment. All principals and principal contractors to be associated with this project (architect, engineer, technical writer) have regularly worked with Blockchain Commons since its foundation in 2019. The team has been proven to work together well and is intimately familiar with the Gordian Envelope specification. Meetings are regularly held through online services such as Zoom. Blockchain Commons has organized a group of developers interested in our protocols who regularly meet with us at Gordian Developer Meetings, held on the first Wednesday of most months for the last few years. We also have regularly worked with IETF and W3C over the last several years, including giving presentations at plenaries and CBOR group meetings for the IETF and acting as a co-author and invited expert for privacy-related W3C groups. Additional contractors, primarily for the deployment and support of internet services, are expected to be drawn from interns and from contractors who have worked on previous projects for the principals. Internet services are to be hosted on cloud-based services, likely run through either GitHub or Akamai. We’ve used both for years. They have very high uptime and should prove stable and secure for the intended testbeds. Overall, the resources already deployed for Blockchain Commons are expected to continue through for this NSF project, and their leanness & efficiency is expected to be a benefit that will help to concentrate costs, time, and work. #### ## Senior/Key Personnel Documents (1) Identifying Information (i) *Name: Allen, Christopher (iii) *Position Title: Executive Director & Principal Architect (2) *Organization and Location Name: Blockchain Commons LLC Location: Cheyenne, Wyoming (3) *Professional Preparation Georgia Institute of Technology Atlanta, Georgia 1980-1981 Computer Science (4) *Appointments and Positions Start Date: March 2018 End Date: Appointment or Position Title: Executive Director & Principal Architect Name of Organization: Blockchain Commons Location of Organization: Cheyenne, Wyoming Start Date: November 2015 End Date: Appointment or Position Title: Chairman of the Board Name of Organization: Rebooting the Web of Trust Location of Organization: Wilmington, Delaware Start Date: March 2016 End Date: March 2018 Appointment or Position TItle: Principal Architect Name of Organization: Blockstream Location of Organization: San Francisco, California Start Date: May 2015 End Date: March 2016 Appointment or Position Title: Instructional Designer & Faculty Name of Organization: Blockchain University Location of Organization: San Francisco, California Start Date: September 2014 End Date: March 2015 Appointment or Position Title: VP of Developer Relations Name of Organization: Blackphone Location of Organization: San Francisco, California Start Date: September 2009 End Date: August 2015 Appointment or Position Title: Associate Faculty Name of Organization: Bainbridge Graduate Institute Location of Organization: Seattle, Washington (5) *Products (i) up to five products most closely related to the proposed project; and McNally, Wolf & Christopher Allen. 2022. “The Gordian Envelope Structured Data Format”. *IETF Data Tracker. *[https://datatracker.ietf.org/doc/draft-mcnally-envelope/](https://datatracker.ietf.org/doc/draft-mcnally-envelope/). McNally, Wolf, Christopher Allen, Carsten Bormann & Laurence Lundblade. “dCBOR: A Deterministic CBOR Application Profile”. *IETF Data Tracker*. [https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/](https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/). McNally, Wolf & Christopher Allen. 2024. “Envelope CLI for Rust”. Blockchain Commons GitHub Repo. [https://github.com/BlockchainCommons/bc-envelope-cli-rust](https://github.com/BlockchainCommons/bc-envelope-cli-rust). McNally, Wolf & Christopher Allen. 2024. “Gordian Seed Tool for iOS”. Blockchain Commons GitHub Repo. [https://github.com/BlockchainCommons/GordianSeedTool-iOS](https://github.com/BlockchainCommons/GordianSeedTool-iOS). McNally, Wolf. 2024. “Understanding Gordian Envelope Part One”. Blockchain Commons YouTube Channel. [https://www.youtube.com/watch?v=-vcLCFKQvik](https://www.youtube.com/watch?v=-vcLCFKQvik). (ii) up to five other significant products, whether or not related to the proposed project that demonstrate the senior/key person's qualifications to carry out the project. Allen, Christopher. 2004. “Tracing the Evolution of Social Software”. *Life with Alacrity*. [https://www.lifewithalacrity.com/article/tracing-the-evolution-of-social-software/](https://www.lifewithalacrity.com/article/tracing-the-evolution-of-social-software/). Allen, Christopher. 2016. “The Path to Self-Sovereign Identity”. *CoinDesk*. [https://www.coindesk.com/markets/2016/04/27/the-path-to-self-sovereign-identity/](https://www.coindesk.com/markets/2016/04/27/the-path-to-self-sovereign-identity/). Allen, Christopher & Shannon Appelcline. 2021. “Learning Bitcoin from the Command Line 2.2.0”. Blockchain Commons GitHub Repo. [https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line?tab=readme-ov-file#learning-bitcoin-from-the-command-line-220](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line?tab=readme-ov-file#learning-bitcoin-from-the-command-line-220). Dierks, Tim & Christopher Allen. 1999. “The TLS Protocol Version 1.0”. *IETF Data Tracker*. [https://datatracker.ietf.org/doc/html/rfc2246](https://datatracker.ietf.org/doc/html/rfc2246). Sporny, Manu, Dave Longley, Markus Sabadello, Drummond Reed, Orie Steele & Christopher Allen. 2022. “Decentralized Identifiers (DIDs) v1.0”. *W3C Recommendation*. [https://www.w3.org/TR/did-core/](https://www.w3.org/TR/did-core/). (6) *Certification Each senior/key person is required to complete the following certifications regarding the information provided in their Biographical Sketch: I certify that the information provided is current, accurate, and complete. This includes but is not limited to information related to domestic and foreign appointments and positions. I also certify that, at the time of submission, I am not a party in a [malign foreign talent recruitment program](https://www.nsf.gov/bfa/dias/policy/researchprotection/nspm33definitions.pdf#page=3). Misrepresentations and/or omissions may be subject to prosecution and liability pursuant to, but not limited to, 18 U.S.C. §§ 287, 1001, 1031 and 31 U.S.C. §§ 3729-3733 and 3802. Signature[[30]](https://new.nsf.gov/policies/pappg/24-1/ch-2-proposal-preparation#ftn30): Date: #### ### Data Management and Sharing Plan The primary outputs of the Gordian Envelope Toolkit will be a series of websites that support the testing, testbedding, and usage of Gordian Envelope for a variety of fields. These websites will be publicly available for at least the three year period of this award and hopefully for much longer. Their source code will be available via GitHub, to allow their deployment or examination by other people, as desired. This project will include new documentation, which will appear either on the new websites or on current public Blockchain Commons websites, and new videos, which will appear on Blockchain Commons’ YouTube channel. The sites will be built upon the specification for Gordian Envelope currently registered with the IETF as an Internet-Draft. If any changes or additions to Gordian Envelope grow out of this project, the IETF Internet-Draft will be updated appropriately. The sites will also be built upon some of the extensions for Gordian Envelope that are recorded in the “Research” repo for Blockchain Commons at GitHub. If any changes or additions to Gordian Envelope extensions grow out of this project, the research repo will be updated appropriately. Any other new discoveries or insights that grow out of this development process will most likely result in written articles, published to the Blockchain Commons blog, published as an advance reading paper for Rebooting the Web of Trust, or distributed to news sites that we have worked with in the past such as CoinDesk. However, articles of this sort are not a planned, or even intended, part of this project. Generally, Blockchain Commons believes in open software and open access to patents covering foundational cryptocurrency techniques. We expect all of our work done under this NSF project to be openly available and freely distributable. ### ### Budget Justification **Line A: Senior Personnel** Christopher Allen, as Executive Director and Principal Architect of Blockchain Commons will be overseeing the project at 2 months per year for each of the three years. A yearly rate of $250,000 is therefore budgeted at $41,667 each year. **Line E: Travel** Travel is for attendance at conferences and workshops, with one to two attendees selected for any conference. These trips are necessary to push for continued specification of Gordian Envelope (primarily at IETF), to receive feedback on our work, and to bring our work to the attention of researchers and developers. The chosen conferences are a combination of crypto, privacy, and standards conferences. Some conferences were excluded due to distance/cost, when alternatives were available. \ Travel costs were estimated based on current low costs for economy plane tickets, while hotel costs were based on GSA Per Diem (for domestic) and Department of State Allowances (for international). For one conference each year, travel costs were slightly increased for attendance by our technical writer, who lives in Hawaii. For years two and three, prices increasingly had to be estimated roughly because venues and times are not yet chosen. *Year One, Domestic*: * *May 12-15, 2025, *IEEE Privacy 46 (San Francisco) * 2 attendees, $400 travel, $2880 hotel (5 nights), total $3280 * *July 14-19, 2025*, PETS 2025 (Washington DC) * 1 attendee, $300 travel, $1056 hotel (6 nights), total $1356 * Attendance by tech. writer at one Year One conference, travel +$500 * Domestic Total Year One $5136 *Year One, International:* * *October 31-November 8, 2025, *IETF 124 (Montreal) * 2 attendees, $1500 travel, $2736 hotel (8 nights), total $4236 * *March 9-11, 2026*, Real World Crypto 2026 (Taipei) * 1 attendee, travel $1000, hotel $940 (5 nights), total $1940 * *March 12-21, 2026, *IETF 125 (somewhere in Asia) * 1 attendee, travel estimated $1250, hotel estimated $3375 (9 nights), total $4625 * International Total Year One $10801 [There will likely be some amortization of travel+hotel costs between RWC 2026 and IETF 125, but it’s impossible to estimate until the location for IETF 125 is determined.] *Year Two, Domestic:* * *May 18-21, 2026*, IEEE Privacy 47 (San Francisco) * 2 attendees, $400 travel, $2880 hotel (5 nights), total $3280 * *November 13-21, 2026*, IETF 127 (San Francisco) * 2 attendees, $400 travel, $4608 hotel (8 nights), total $5008 * Attendance by tech. writer at one Year Two conference, travel +$500 * Domestic Total Year Two $8788 *Year Two, International:* * *Early 2027*, Real World Crypto 2027 (location unknown, most likely international) * 2 attendees, Estimated $4500 total cost * International Total Year Two $4500 *Year Three* * IETF in 2027 * Privacy Conference (PETS?) 2027 * Real World Crypto 2028 None of the conferences for the last year have been scheduled. We plan attendance at three, likely two domestic and one international, and assume 2 attendees for each. We have estimated the cost for each at $4500, plus $500 for our tech writer to attend one. * Domestic Total Year Three $9500 * International Total Year Three $4500 **Line F: Participant Support Costs** **Part F2: Travel Costs** Travel costs are per diems for attendees at conferences, calculated per Department of State or GSA allowances. *Year One*: * *May 12-15, 2025, *IEEE Privacy 46 (San Francisco): $750.50 [2 attendees, 6 days] * *July 14-19, 2025*, PETS 2025 (Washington DC): $513.50 [1 attendee, 7 days] * *October 31-November 8, 2025, *IETF 124 (Montreal): $2,034 [2 attendees, 9 days] * *March 9-11, 2026*, Real World Crypto 2026 (Taipei): $648 [1 attendee, 6 days] * *March 12-21, 2026, *IETF 125 (somewhere in Asia): $1600, [1 attendee, 6 days] * Year One Participant/Travel Costs $5546 *Year Two:* * *May 18-21, 2026*, IEEE Privacy 47 (San Francisco): $750.50 [2 attendees, 6 days] * *November 13-21, 2026*, IETF 127 (San Francisco): $1224.50 [2 attendees, 9 days] * *Early 2027*, Real World Crypto 2027: estimated $1500 [2 attendees, est. 6 days] * Year Two Participant/Travel Costs: $3475 *Year Three:* * 3 conferences for 2 attendees, estimated at $1500 each * Year Three Participant/Travel Costs: $4500 **Part F4: Other** The “Other” column for Participant Support was used to record registration costs for these conferences. Costs are not laid out for most future conferences, and they often vary widely depending on country where the conference is held, but the costs were calculated as percentage increases over the most recent known cost. *Year One*: * IEEE Privacy 46: $2240 [2 attendees, 110% of 2023 cost] * PETS 2025: $800 [1 attendee] * IETF 124: $2299.50 [2 attendees, 105% of IETF 123 cost] * Real World Crypto 2026: $495 [1 attendee] * IETF 125: $1204.50 [1 attendee, 110% of IETF 123 cost] * Year One Participant/Other Costs $7043 *Year Two:* * IEEE Privacy 47: $2346 [2 attendees, 115% of 2023 cost] * IETF 127: $2628 [2 attendees, 120% of IETF 123 cost] * Real World Crypto 2027: $1089 [2 attendees, 110% of RWC 2026 cost] * Year Two Participant/Other Costs: $6063 *Year Three:* * IETF Conference: $2737.50 [2 attendees, 125% of IETF 123 Costs] * Privacy Conference: $2448 [2 attendees, 120% of 2023 IEEE Privacy cost] * Real World Crypto 2028: estimated $1188 [2 attendees, 120% of RWC 2026 cost] * Year Three Travel Costs: $6373 **Line G3: Consultant Services** Blockchain Commons’ Sr. Engineer (Wolf McNally) and Sr. Technical Writer (Shannon Appelcline) both work as consultants. Their rates have been set, with Wolf’s running low for a Sr. Engineer and Shannon’s running average for a Sr. Technical Writer. They receive no additional benefits. * Wolf McNally, Sr. Engineer, $125/hr * Shannon Appelcline, Sr. Tech Writer, $100/hr We will also be hiring on additional consultants for work on this project at fair market fees: * Sysadmin, $75/hr * UX Designer, $100/hr * Web Designer, $7,500/web site This is the breakdown of planned work for each participant on the project: *Year One:* * Wolf McNally, 48 weeks, full-time [240 days]: $240,000 * Shannon Appelcline, 48 weeks, 40% time [96 days]: $76,800 * Sysadmin, 48 weeks, 10% time [24 days]: $14,400 * UX Designer, 48 weeks, 10% time [24 days]: $19,200 * Web Designer, 1 site: $7,500 * Year One Consultant Total: $357,900 *Year Two:* * Wolf McNally, 48 weeks, full-time [240 days]: $240,000 * Shannon Appelcline, 48 weeks, 40% time [96 days]: $76,800 * Sysadmin, 48 weeks, 10% time [24 days]: $14,400 * UX Designer, 48 weeks, 20% time [48 days]: $38,400 * Web Designer, 3 sites: $22,500 * Year Two Consultant Total: $392,100 *Year Three:* * Wolf McNally, 12 weeks, bug fixes & updates [60 days]: $60,000 * Shannon Appelcline, 24 weeks, 40% time [48 days]: $38,400 * Sysadmin, 48 weeks, 10% time [24 days]: $14,400 * UX Designer, 48 weeks, 10% time [24 days]: $19,200 * Web Designer, 1 site: $7,500 * Year Three Consultant Total: $139,500 **Line G4: Computer Services** Computer services are budgeted at $1,152 for each of three years. This is for a testbed cloud server and a deployment cloud server for our various testbeds. Each one is currently specced as a Linode 8GB (8GB mem, 160 GB storage), which runs $48 a month at Linode (Akamai). $48 x 12 x 2 = $1,152 a year. **Line G5: Other** $7,900 is budgeted for each of the three years. This is for an IETF Membership for a company of our size, to give us full voting and participation rights, allowing us better opportunity to advance our specification. **Line I: Indirect Costs** Indirect costs are calculated at the *de minimis *level of 10% of direct costs. **Synergistic Activities** ***Synergistic Activities*** ***Rebooting the Web of Trust Design. ***Christopher’s Rebooting the Web of Trust workshops, run 11 times starting in 2015, focus on encouraging participants to share their knowledge in order to collaboratively write papers about decentralized identity. This required him to design a methodology where participants could quickly immerse themselves in the subject field while simultaneously becoming comfortable with collaborating with attendees. At RWOT2 Christopher had participants write a short imagination of what a future of decentralized identity might look like. At other workshops he’s had “speed dating” rounds where participants talked about their expertise or interests. Over time, this has developed into the first day of the workshop focusing on these collaborative ice breakers before participants form interest groups to write papers. This has been very successful: RWOT has finalized 68 papers across its 11 workshops. ***Cryptocurrency Implementers' Workshop. ***Christopher pitched the Financial Crypto conference to host a workshop on translating Bitcoin and blockchain theory into practical use. The idea was accepted and Christopher was elected by the full-conference membership to co-chair the first Cryptocurrency Implementers’ Workshop, held in conjunction with Financial Crypto 2019. He supported invited talks and demo show-and-tells that helped participants to transfer knowledge in support of real-world applications. Christopher has similarly supported other conferences as a member of the Steering Committee for the International Financial Cryptography Association (2017-2019) and the Program Committee for IEEE Security and Privacy Blockchain (2017). ***Learning Bitcoin Authorship. ***Following Christopher’s work at Blockchain University, he remained interested in showing people how to use Bitcoin software. This began with the creation of short instructions on installing Bitcoin nodes. After he brought in technical writer Shannon Appelcline, Christopher developed that into a full course that not only helped people to install Bitcoin software, but also used that software as an intermediary for teaching Bitcoin concepts. Students install and use Bitcoin Core’s bitcoin-cli command-line interface in a hands-on manner, learning all of the intricacies of Bitcoin along the way. Today, the course is book-length and has brought numerous people into the industry. (It has over 3,000 stars on GitHub.) ***Path to Self-Sovereign Identity. ***In 2016, Christopher began advocating for the idea of “self-sovereign identity”, where people would control their own digital identities rather than them being controlled by corporations. However, he wanted to avoid the errors of past identity movements such as federated identity and user-centric identity. To argue his vision of user-controlled digital identity Christopher wrote a paper called “The Path to Self-Sovereign Identity” that not only detailed that vision but also traced the history of the field and discussed why previous efforts had failed. It was a powerful argument. Christopher’s article was the top search result for “self-sovereign identity” for the first few years, before the field really took off, and today it remains a touchstone for the numerous companies now working in the field, as well as for self-sovereign identity technologies such as Decentralized Identifiers (DIDs), which Christopher also helped to develop. It was published as part of *Self-Sovereign Identity *(2021) by Manning, the first technical book on the topic. ***ID2020 Organizer. ***Christopher was one of the organizers for ID2020, the first UN conference on digital identity and human rights. It was a driver for understanding the challenges of digital identity and also led to the discussion of self-sovereign identity at the UN.