TrustBox is a suite of tools to build and utilise trust infrastructure for application ecosystems. It targets open standards that bridge the web with digital identity. Currently, it consists of:
TrustSight - A trust overlay for your browser. It helps web users figure out if they can trust a website. Currently, this is a separate repository.
TrustBench - A developer tool for building and publishing trust infrastructure such as trust frameworks, and the pieces need to participate in a trust framework.
TrustGraph - A visualizer for trust relationships. It can be used by both builders and users to understand trust within an ecosystem.
This repository also contains:
The HomebuyingUK Demo - A trust framework supported journey through the early steps of a property sale. Utilising TrustBench, TrustSight and TrustGraph
To learn more, watch the HombuyingUK demo video, and try it out for yourself. Or stick around for the story. If you're only interested in the tech and standards, skip to here.
This project is inspired by an effort I'm involved in to build a trust framework for the home buying and selling industry. It requires some explanation and quite a few acronyms so here it goes.
The Property Data Trust Framework (PDTF) created by the Home Buying and Selling Group, and now managed by the Open Property Data Association, seeks to enable people and organisations within the UK to exchange trustworthy property data more easily. Its significant contribution currently is the publication of data schemas describing standardised property data.
I wanted to explore the implementation of a trust framework, and a bridge into the world of verifiable credentials (VCs) and decentralized identifiers (DIDs). Unfortunately, but also excitingly, the development of digital trust frameworks is still quite young.
Another important piece of this tale is the UKs Digital Identity and Attributes Trust Framework (DIATF), a beta policy paper in the UK. The policy describes the concept of schemes, that allows industries to create domain specific trust frameworks that are certified by the Department of Science Innovation and Technology (DSIT).
I wanted to find out, from the perspective of the average internet user:
- How could an organisation prove their participation, and role, in the PDTF?
- How could the PDTF prove its certification as a DIATF scheme?
Hence, TrustSight is born.
TrustSight is a trust overlay for your browser, find out more here.
To effectively demonstrate TrustSight for this purpose, I needed to build a trust framework. Actually, I needed to build two interlocking trust frameworks. This was the birth of TrustBench.
A natural way to make sense of such a setup is a graph, so obviously I had to build TrustGraph.
I realised I now had a suite of tools, so it needed a name. I am not very imaginative.
The HomebuyingUK demo follows an average internet user through the early steps of selling their home - showing how TrustSight can give them confidence through this journey. Part 2 shows how a technical administrator for HomebuyingUK can easily update the trust framework using TrustBench and visualise the published changes with TrustGraph.
Part 1 can be replicated yourself by starting at the TrustUK demo site. Doing part 2 fully requires running this repository yourself. See here. Or you can just look at the trust graph used in the demo.
The demo is implemented as a collection of projects in this repo.
Each organisation in the demo has a website. In these readmes you can find out more about the inspiration for each organisation. The sites themselves are created from templates and not very interesting.
TrustUK (fka. DDIATF)
HomebuyingUK (fka. DPDTF)
More interesting is the trust infrastructure for the demo, i.e. how each website/organisation is identified and how they make assertions about each other. It
is implemented as a single TrustBench model, where each site is an entity. I call it the
It uses TrustBench to build the model into pieces that are published/hosted by the relevant website.
It also uses the pubishWithWeb5 config to additionally publish trust establishment documents to a DWN.
The core of the solution is the combination of trust establishment documents and wellknown did configurations. Together it provides an open and standards compliant way to make trust assertions about an entity and have that entity be provably associated with a domain. It means it is practical to publish and consume trust infrastructure (welknown did configs, topic schemas, trust docs) using a web server.
Additionally we use decentralised web nodes to offer enhanced publishing functionality, so that organizations do not have to rely solely on publishing to a website. (currently only trust establishment documents themselves can be published to a DWN. In the future, topic schemas would be too). This provides an easier way for applications to query for an entity's trust documents, which we take advantage of in TrustGraph. TrustSight also uses it to refresh trust docs (keep them up to date), or falls back to refreshing from the authors webserver/website.
We use various libraries: veramo, @sphereon/wellknown-dids-client, web5.js - to implement the standards properly, and perform real did operations, credential signing, and verification (although we don't support verification of JSON-LD linked domain credentials yet, just VC-JWT). We have a burgeoning library called trustlib which may one day combine that stuff in a way that its easy to reuse, atm its all rather spread about the place.
- TrustSight wraps it into a chrome extension with a react UI (tailwind + shadcn <3).
- TrustBench wraps it into a node js library / proto cli.
- TrustGraph wraps it into a Next.js application. It uses Reagraph for graph visualisation.
- Each demo website is a simple Next.js application with tailwind
trust-backboneis the TrustBench model that describes all the trust infrastructure for the demo websites.
This is turborepo repo (a turbo, repo?). Its mostly typescript. Frontend is mostly React and Tailwind. Package manager is PNPM.
Here is a full index for the repo:
TrustUK (fka. DDIATF)
HomebuyingUK (fka. DPDTF)
Tool for building and publishing trust infrastructure.
Holds the model defining the trust backbone used by the demo, plus a script to build the model with TrustBench.
Burgeoning library thats currently almost empty but may one day organise the dependencies shared by TrustBox.
This Turborepo has some tools setup for you:
- TypeScript for static type checking
- ESLint for code linting
- Prettier for code formatting
To build all apps and packages, run the following command:
pnpm build
install pnpm
install dependencies
pnpm installSet up a local environment with
pnpm run initThis will create a local.environment.json in /packages/trust-backbone for you - including a fresh kmsSecretKey.
and build a local trust backbone for the demo apps (e.g. with localhost origins). See here for more info.
To develop all apps and packages, run the following command:
pnpm dev
The services will be available at the following urls by default.
- TrustUK - localhost:3002
- HomebuyingUK - localhost:3001
- PropertyPrepper - localhost:3003
- TrustGraph - localhost:3004
Grab the did generated for your local TrustUK entity. Easiest way is probably one of:
- using TrustSight, hover over the avatar and copying it. (not very sophisticated i know)
- go to the built trust establishment doc and copy the author value.
You can then use that did in TrustGraph to get the visualisation.
To change the trust backbone, e.g. add new trust assertions, trust docs, entities. The trust-backbone model should be updated. See the readme for it.
When you change the model and want to see the changes in dev. You need run this inside /packages/trust-backbone.
pnpm run build localBefore pushing any changes, you must rebuild the trust backbone properly for deployment.
You need the right kmsSecretKey to do this, which only I have.
So let me know if you ever get to this point.
pnpm build demoThis should all be nicer, with dev commands setup to auto rebuild and CI to build for prod on push. But i got a bit stuck, see here.
I haven't enabled any of the remote caching stuff.
Turborepo can use a technique known as Remote Caching to share cache artifacts across machines, enabling you to share build caches with your team and CI/CD pipelines.
By default, Turborepo will cache locally. To enable Remote Caching you will need an account with Vercel. If you don't have an account you can create one, then enter the following commands:
npx turbo login
This will authenticate the Turborepo CLI with your Vercel account.
Next, you can link your Turborepo to your Remote Cache by running the following command from the root of your Turborepo:
npx turbo link
Learn more about the power of Turborepo: