The United Nations Trust Graph
In July the UN/CEFACT eDATA project published a white paper on the adoption of Verifiable Credentials for Cross Border Trade. It discusses many aspects of the topic, from macro economic drivers to technical details and common use cases. As a co-author, I obviously recommend it to anyone with an interest in international standards and digitization of supply chains:
In this blog post, I will specifically focus on the concept of Trust Graphs, introduced in the white paper (section 3.3). Trust Graphs essentially combine the cryptographic verifiability of VCs with the data analytics potential of knowledge graphs. I will elaborate on the potential of this combination, and implement it as a graph algorithm in Neo4j.
Introducing the Sample Trust Graph
Above is the sample trust graph from the white paper. It exemplifies a number of Verifiable Credentials issued by Issuers about Subjects. On the left hand side are a number of Trust Anchors. These are Entities which the verifiers on the right hand side have undergone processes to trust. As an example, the trade finance Bank has established the Customs authority of a foreign country as a Trust Anchor.
The Bank receives an Invoice for a shipment issued by a foreign Exporter. Being a VC, the Invoice can be cryptographically traced to the Exporter. But if the bank does not know that Exporter, verifiability alone is not enough to establish trust.
However, the Exporter holds an Authorized Economic Operator certificate issued by Customs. When presented with both VCs, the Bank can establish a cryptographically verifiable chain back to the Customs Trust Anchor.
The two mentioned Verifiable Credentials could for example be instances of Commercial Invoice and CTPAT.
Note that the top most branch of the trust graph does not end at a Trust Anchor. This is where the verifying side needs to focus attention. All the rest, which does trace back to Trust Anchors can be processed completely automated. This is a huge deal to verifiers. Banks, customs authorities, large importers and exporters process thousands of documents each day. Massive amount of resources are spent on risk assessment based on human judgment of PDFs with analogue signatures.
A trust graph is the key which unlocks digitizing international documentation procedures: establish and grow Trust Anchor points and trace data verifiably back to them.
Verifiable Credential Link Details
Zooming in slightly, each of the graph edges are represented graphically by the arrows going from “I” to “S”. This reads “Customs has issued an AEO Certificate about the Exporter”.
This is a nice abstraction. Anyone familiar with the Verifiable Credentials data model will know that in fact that “AEO Cert” arrow is a VC node with two edges. Not an issue at all, just something to keep in mind as we switch into “real” graph data perspective in a minute. Here, our data model will be:
A Note on Identifiers
A quick word about the identifiers too: the identifiers in the sample trust graph are a bit sketchy. “customs.gov.x“ is not a decentralized identifier, and certainly neither is “abcd”. However sketchy, the sample identifiers are locally unique and will be good enough for the point we are aiming to make here, so we’ll just go with them.
In reality, the customs DID for example would look something like did:web:customs.country.gov. This would resolve to a DID Document with public cryptographic material, and customs would control its private keys behind it. This is an essential part of the earlier described infrastructure, enabling verifiable data.
Verifiable Data Pipeline
In the following, we take the role of verifier. This could be one of the two verifiers represented on the sample diagram: a Trade Finance Bank or an Importer. But it could certainly also be destination-side Customs Authorities processing import filing data. Indeed, anyone else receiving data!
We should imagine a bunch of inbound data documents which have originated through different APIs, varying channels, pipelines, and at different points in time. Some relate to the particular shipment at hand, others are about entities or organizations. Remember that every arrow on the Sample Trust Graph is a Verifiable Credential.
All data gets verified at the time it is presented. The bank, for example, verifies the Air Waybill when it is presented, the Packing List when it is presented, and so forth. Clearly, if the data does not verify, we will reject it immediately.
You can verify a sample Commercial Invoice here.
We would likely also re-verify credentials at the time we run our data analysis (a principle of Zero Trust Architecture). After all, credentials could have expired, been revoked, or issuing DIDs be deactivated.
Once verified, we can progress with our data analysis. Because Verifiable Credentials are Linked Data, they can be directly imported into a graph database, establishing a knowledge graph.
Building the Knowledge Graph
We will now switch focus to the right-hand side of the data pipeline. To simplify matters, we are pretending that all data at this point has been successfully verified. We are also going along with rather simplified sample data from the UN whitepaper. In reality, VCs typically contain lots of valuable data, but for this all we really need is the type of VC (AEO Cert, Invoice, etc).
I will use Neo4j to build and analyze the knowledge graph. If you want to follow along yourself, here is the cypher commands needed to establish the base data:
https://github.com/nissimsan/trust-graphs/blob/main/sample-trust-graph/un-trust-graph-data.cypher
Here is what we get when importing it:
Trust Determination Algorithm
With the verified knowledge graph in place, we can analyze the graph to determine potentially untrusted branches. As mentioned earlier, trust start from Trust Anchors — entities which have undergone due processes to establish them as a reliable authority of the type of credentials which they issue.
The following cypher algorithm marks all graph nodes which trace back to a Trust Anchor. Starting from an evaluation node (“eval”) which in the case of the trade finance back is the shipment, it finds all paths back to the Trust Anchor points (“anchor”). All the five Trust Anchor points from the sample are defined as part of the command. Finally, all the nodes on the paths back to Trust Anchors are labeled as “trusted”.
MATCH n=(eval)-[*]-(anchor)
WHERE eval.did = ‘xyz321’ AND anchor.did IN [‘trade.gov.x’, ‘customs.gov.x’, ‘agri.gov.x’, ‘accredit.org’, ‘ip.gov.x’]
FOREACH (m IN nodes(n) | SET m.trusted = true)
In Neo4j Bloom, we can now paint a clear picture which indicates the part of the graph which needs attention. The Forwarder is not known already, and therefore we do not have a basis on which to trust the Air Waybill which it issued. Procedures must be initiated to assess whether the Forwarder is a legitimate and trustworthy actor.
Conclusion
The green parts of the Trust Graph can safely be automated — whether running finance rules and risk assessment, customs release or any other rules-based procedure. Manual focus can be switched to exception management, determining Trust Anchors. This is both cheaper, faster and safer.
We have seen here how the powerful United Nations CEFACT Trust Graph concept can be implemented. Digitization has traditionally been particularly difficult in the inherently heterogeneous environment of international trade. Cryptography and standards are the keys to unlock this potential.
