Preface

Decentralised identities is a new emerging identity platform based on open standards, it puts the user in control of their own data. This blog focuses on the differences of publishing your decentralised identifier (DID), used for verification of an issued credential, on web or ION. If you're new to decentralised identities, I recommend reading up on it here.

Intro

I recently setup our production Verified ID service in Azure. When you are creating a new Verified ID service, there is a choice to choose your preferred trust system. The choice is between using Web (default) or ION.

Once your Verified ID service is initialised you cannot change this trust system without deleting all your credentials and resetting the service, so it's a pretty big choice to get right... but often people are unsure about the differences of did:web and did:ion.

At a high level, did:ion and did:web are two different methods for creating and managing your decentralised identifiers. These decentralised identifiers are used to validate the authenticity of a credential being presented.

did:ion

When I setup our production service, I chose did:ion as the trust system. did:ion uses ION (Identity Overlay Network), a level 2 open and permissionless network. It can support thousands of transactions per second and uses distributed ledgers to enable censorship and be tamper evasive. It runs as a platform atop of the Bitcoin blockchain.

You can use the ION network explorer to view published documents.

did:web

On the other hand, you can chose did:web. This is a little more familiar to people as it relies on existing web technologies such as DNS and HTTPS. With this approach the trust is with the domain owner and due to needing to verify each presentation request for validity, the DID document needs to be highly available and able to respond to thousands of requests a second for large and mature implementations. If the issuer's domain is not available to verify at the time of presentation, the user may see some security warnings but can continue after accepting the warning. Will this get stricter as the platform matures... perhaps.

Decentralisation

I mentioned that did:web relies on a domain being highly available and scalable for verifying the credential being presented, by definition having reliance on this central authority is not only a single point of failure, it makes did:web less decentralised compared to did:ion. This also makes did:web less secure, as you are putting trust into the domain owner to manage and control the DID; whereas did:ion relies on a fully decentralised and distributed network overlay platform.

Conclusion

In summary, the main difference is the underlying technology. With existing web technologies like DNS and HTTPS, issuers can leverage did:web. However, for a truly decentralised platform, you should use did:ion, which uses the ION protocol and blockchain technology.

I highly recommend going for did:ion if your use case would allow it. Not only is it more secure, it's more decentralised, has a higher trust level, and ensures immutability. Moreover, did:ion will allow your issued credentials to still be issuer verified should the your implementation cease to exist in the future.