DID Extensibility on the MATTR Platform

At MATTR we’ve been busy building the next generation of solutions for verifiable data and digital trust. Earlier this month we introduced our platform and added experimental support for a new, privacy-preserving method for selective data disclosure. Today, we’ve reached another milestone that gives our users even more choice and transparency by the addition of a new way to use Decentralized Identifiers (DIDs).

Modularity and extensibility are key design principles underpinning our core platform architecture. The MATTR Platform is designed to support a wide range of distinct pluggable components, providing our customers with confidence that their technology choices will continue to evolve with new innovations as they emerge.

When it comes to DIDs, there are currently over 50+ DID Methods registered with the W3C. Each DID Method defines a CRUD model that describes how a particular DID scheme works with a specific verifiable data registry such as a distributed ledger or blockchain. The initial group of DID methods was quite small, and has expanded significantly over time as more solutions emerge in this space. While all of these new DID methods theoretically adhere to the DID core specification, each method makes a different set of choices that affect the underlying trust model at play. For instance, DID methods have distinct rules about who gets to add new transactions, what input data is required, where DIDs are anchored, who can view or monitor the DIDs, and more.

In short, there are many factors that affect the choice around which DID method to use, and it’s not a trivial decision.

We believe that DIDs, when deployed responsibly, can be extremely effective at preserving user privacy, enhancing transparency and consent, enabling data portability, and enforcing user control. To learn more about our approach, read our blog, “Intro to DIDs for people”.

In addition to our current support for DID Key (static key-based identifier) and DID Sovrin (ledger-based identifier), we are now proud to add DID Web (domain-based identifier) to our list of supported DID methods.

DID Web helps to bridge the gap between the way that trust is established on the internet today, namely using domains, and new and emerging ecosystems using DIDs. When using DID Web, rather than anchoring a DID to a decentralized ledger such as a blockchain, the DID is instead associated with a specific domain name, and subsequently anchored to the web host registered with that domain via DNS resolution. Effectively, this allows a DID using this scheme to be resolved as simply as one resolves a web URL, every time they click on a link. For example, we’ve set up a DID Web using our own domain, which can be resolved at did:web:mattr.global.

Users in the emerging world of DIDs can use this mechanism to bootstrap trust by using the reputation associated with public domains. While this solution may not work in every circumstance and lacks some of the resilience and censorship guarantees afforded by DID methods with less centralized dependencies, DID Web provides a practical and useful pathway to adoption, particularly for entities whose data and identity are already public. When used in parallel with more natively decentralized mechanisms, we can help to ensure that the web remains free and open while providing a path for legacy systems to remain interoperable with the emerging distributed web of trust.

By adding support for new DID methods such as DID Web, we are creating optionality and choice for our users. Our products will always be ledger-agnostic. We will also continue to offer support for DIDs which are not anchored to any ledger. We aim to bridge the gap between approaches that are built on top of ledgers and those using domains, key registries, and other methods to establish trust.

We are also actively investigating how to add support for more scalable solutions that use ledgers on an ad-hoc basis, such as DID methods based on the layer two Sidetree Protocol. This open-source protocol provides an abstract layer that sits on top of DLT infrastructure.

The Platform Drivers part of our architecture provides DID Method support in the form of pluggable integrations that prevent vendor lock-in and enable user choice. To find out more about how the MATTR Platform supports a broad spectrum of DID methods, check out our documentation on MATTR Learn and sign up to get started.