At Northern Block, our primary goal is to facilitate the orchestration of trust tasks as seamlessly as possible. We aim to make it easier for our partners, customers, and the entire world to engage in digital interactions with trust embedded into the fabric.

The concept of a “trust task” was first introduced to me in the Trust over IP Foundation’s Technical Architecture Specification, but the term was originally coined by Daniel Hardman, who describes it very nicely in a recent presentation of his:

Trust tasks differ from applications in important ways: they are multi-party, and they should be composable.

I really liked how Daniel displayed trust tasks within the ToIP hourglass model, as it really showcases its composable nature. I’ve taken the liberty of adapting his slide in the context of Northern Block to showcase where we are focused within the large spectrum of digital trust.

You’ll observe that there is a trust task called “ask trust registry.” To support this task, we have been dedicating efforts into developing the necessary supporting systems to ensure its smooth operation.

What is a Trust Registry?

• A trust registry essentially serves as a source of truth and authoritative information. The governance framework behind a trust registry is what makes it authoritative for its trust ecosystem. If there is confidence in the governance framework, it naturally leads to confidence in the authority imposed by the governance body within the trust registry or source of truth.
• It’s crucial to recognize that a verifiable data registry (such as a blockchain or DLT) doesn’t always provide a source of truth. These registries can serve as storage for information related to a public entity’s decentralized identifiers, DID documents, schemas, credential definitions, and more. Although they offer immutable data storage with resolution and discovery capabilities, they may not always deliver authoritative information.
• This is where the trust registry comes into play. By providing authoritative information backed by a strong governance framework, trust registries support the attainment of digital trust and ensures that the entities participating in an ecosystem are reliable and credible. If you’d like to learn more about the role of governance, I highly recommend listening to the insightful podcast conversation I had with Scott Perry, a colleague in the digital trust space. Scott chairs the Governance Stack Working Group at the Trust over IP (ToIP) Foundation, and our discussion delves into this important topic.

​​Within a typical credential acceptance trust task within Orbit Enterprise, several sub-trust tasks may need to be orchestrated in order for a party to accept a credential offer. These may include peer connections, secure messaging, negotiations, and the consultation of external supporting systems such as trust registries.

The holder receiving a credential offer may want to invoke other trust tasks to assist them in making the decision to accept the credential offer.

Northern Block has been collaborating closely with Jacques Latour, Chief Technology & Security Officer at the Canadian Internet Registration Authority (CIRA), which manages over three million .ca domains as the .ca top-level domain (TLD) registry. Together, we’ve been exploring how the Domain Name System (DNS) infrastructure can enable digital trust, particularly in the context of trust registries and their role in maintaining authoritative records for .ca domain owners. We recently co-published an IETF Working Draft of our work if you wish to have more information.

When an entity is presented with a verifiable claim, there are three things they will want to ensure:

1. That a claim hasn’t been altered/falsified at any point in time (cryptographic verifiability, verifiable data registries) ✅
2. That a claim has accurate representation (DID authentication, accurate representation) 🤨
3. That a claim has authority (authorization, authority) 🤨

While cryptographic verifiability is a fundamental aspect of verifiable credential exchange protocols, it doesn’t necessarily guarantee the accurate representation or authority of a specific public key or decentralized identifier (DID).

To address this human trust issue, we’ve utilized the decentralized DNS infrastructure to create a flexible linkage between issuing bodies’ domain names and their DIDs, which doesn’t impose a specific DID method. By enabling issuers to edit their DID documents with pointers to their DNS records, our approach allows for various DID methods to leverage the DNS infrastructure for added assurance.

Why DNS?

• The Domain Name System (DNS) infrastructure is considered global, unique, resilient, and highly secure, particularly when the Domain Name System Security Extensions (DNSSEC) are utilized. As a global system, DNS operates across the internet, mostly known for ensuring that domain names are translated into IP addresses, making it easier for users to access websites and online services. The uniqueness of the DNS lies in the fact that each domain name corresponds to a unique label such as trustregistry.nborbit.io, avoiding any confusion or conflicts. The DNS infrastructure is resilient, as it relies on a distributed hierarchical structure, which minimizes the risk of a single point of failure. Finally, the security of the DNS is significantly enhanced by the implementation of DNSSEC, which provides cryptographic signatures to ensure the integrity and authenticity of the data within the DNS, preventing attacks such as DNS spoofing or cache poisoning.
• The exclusive write access granted to domain name owners for their DNS records, coupled with the proper implementation of DNSSEC, enhances the records’ authoritative nature, ensuring the integrity and authenticity of the information they provide. This write access is cryptographically verifiable through a chain of trust that, in the Canadian context, flows from the Internet Corporation for Assigned Names and Numbers (ICANN) to the Canadian Internet Registration Authority (CIRA), and then further down to the .ca domain owners.
• Beyond the cryptographic trust, CIRA has established processes and agreements with domain name registrars to ensure that .ca domain names meet specific criteria, such as having a Canadian presence. The registry operated by CIRA can be considered sources of truth because they are authoritative in the context of .ca domain names and are connected to existing governance mechanisms managed by CIRA (more details on CIRA governance here). This governance structure further reinforces the trustworthiness of the registries, making them reliable sources of information for .ca domain names and their associated entities.

We’ve enabled Orbit Enterprise users to update their DID Documents with pointers to their domain names. Consequently, when someone resolves an issuer’s DID document, they can extract the issuer’s domain from the document and query the issuer’s DNS for additional information addressing the two concerns mentioned earlier. This integration provides a more comprehensive and reliable way of verifying issuers and their authority.

A credential issuer can ensure that certain information is synced up with their DNS records.

The two things that this implementation facilitates for parties are:

1. To authenticate the DID against a second source, to achieve greater assurance that the DID owner is indeed the same party that owns the domain. This added layer of trust strengthens the overall reliability and security of the system.
2. To get information related to trust registries that the DID claims to be listed in. This enables the discoverability of trust registries that may have been unknown prior.

Orbit Enterprise users can utilize the Trust Decision Helper to assist with the aforementioned points. In the screenshot below, you can observe how a holder receiving a credential offer can query the issuer’s DNS records to verify if there’s a match between the DID presented in the DID Document and the DID written in their DNS. Additionally, the holder can query trust registry locations that the issuer directs them to.

A holder receiving a credential offer can query the issuer’s DNS records using the Trust Decision Helper. They are offered with information that can be used as inputs to inform their trust decision.

With hundreds or thousands of trust registries in existence, it becomes virtually impossible for a central entity to manage their locations and purposes. Furthermore, having a central entity overseeing all global trust registries is not ideal for promoting privacy and confidentiality.

Currently, there are numerous identity systems functioning within specific ecosystems, each serving as a source of truth within their respective contexts. Centralizing the management of these systems is not practical. The challenge lies in discovering the presence of trust registries and understanding their associated governance frameworks. This is where DNS comes in. 

If we trust that an entity is accurately represented by their DID, they should be able to guide us towards sources of truth or trust registries in which they are listed. This decentralized and privacy-preserving approach enables direct interaction with the entity, instead of relying on a central authority. By leveraging the widespread adoption and trust established within the DNS infrastructure, we can discover relevant trust registries and gather inputs to inform our trust decisions.

The holder was able to validate that the issuer who offered them a credential has authority to offer said credential within a specific trust registry.

In the final screen which completes the flow, a few key points are evident. Firstly, additional assurance is achieved by validating the match between the DID written in the DNS system and the one presented, enabling cross-verification through two distinct trust systems. Secondly, verification is conducted within a trust registry that the issuer directed the holder to. A third check is performed against the same DID presented in the document, which is also listed in both the DNS records and the specific trust registry. The holder is also given the confidence that, based on this trust registry, the issuer possesses the authority to issue the credential they initially offered.

Note: we could have presented the holder with the trust registry’s referenced governance framework as well. Something to add in future iterations of the Trust Decision Helper.

With these additional inputs, the holder can exit the Trust Decision Helper flow and return to their credential negotiation workflow. They may choose to engage in further trust tasks, such as sending secure messages to the issuing body if they have questions, concerns, or wish to negotiate further. Alternatively, they may be satisfied with the inputs received and feel comfortable making their trust decision and accepting the credential offer.

By incorporating the DNS and trust registry functionality into Orbit Enterprise, we aim to facilitate the scaling of trust registries while enhancing their discovery and usage. The joint presentations between CIRA and Northern Block at IdentityNorth and ICANN have garnered positive feedback, and we continue to actively participate in the Trust Over IP Foundation’s Trust Registry Task Force as well as the Identity Lab of Canada’s Trust Registry Community of Practice.

We will be presenting this work at the Internet Identity Workshop next week, and look forward to engaging in interesting conversations and further advancing what we think to be an important initiative.