Decentralized identifiers (DID) are an emerging web specification. Many DID implementations are under consideration, and a few implementations exist. Going forward, interoperability will be a key to the success of DIDs.
A recent W3C call for recommendation cited a lack of interoperability as an objection to the “Decentralized Identifiers (DIDs) v1.0” proposed recommendation.
No practical interoperability. As Microsoft & Google expressed, the DID “Core” spec has not demonstrated any degree of practical interoperability, instead delegating that to a registry of 50+ “methods”, none of which themselves have interoperable implementations.
In the spirit of working code moving the world, we decided to show that DID interoperability can work in the real world. DIDs have been a core part of the Fission stack for over a year. Microsoft has implemented DIDs with its ION network. We decided to show that a user could sign up with Fission with an ION DID.
Read more about ION Formats in the DIF Sidetree Specification
Identity
We used ion-tools to create an ION DID.
The first step in creating an ION DID is generating a key pair. The supported key types include secp256k1 and Ed25519. We chose Ed25519.
Next, we created the ION DID and registered with the ION network in a process called anchoring. Once anchored, short-form ION DIDs are resolvable on the ION Network.
Sign Up
With our ION DID in hand, our next step was signing up with Fission. We wanted to keep our demo straightforward and lightweight. Rather than build a separate ION-based signing app, we decided to keep the user’s private key in cleartext memory. We did this for demo purposes only, and we do not advocate for pasting private keys into websites in production. An external signing app could easily complete the signing, but this was beyond the scope of our demo.
Our demohacked Auth Lobby looked like this:
A user enters their email and username as usual, but they also enter their ION DID and their private key. We check if the username is available and resolve ION DID with the ION Network. If both check out, the user can sign up.
The Auth Lobby issues a UCAN token with the ION DID as its issuer, the Fission server as its audience, and the capability to use all Fission resources. The UCAN represents a user granting permission to sign up with Fission using their ION DID. We sign the UCAN with the ION private key.
When the Fission server receives the sign-up request, it resolves the ION DID. If the ION DID is registered, a node on the ION Network returns a DID document that contains the public key associated with the DID. The Fission server checks that the UCAN has a valid signature and signs the user up if so.
Authorization
After sign up, the Fission server has registered the user, but we also need to set up their account in the browser. Their ION DID is their root identity, but we want to create a Fission DID to use Fission resources as any other Fission user would.
Fission users have nonexportable RSA keys secured by the WebCrypto API, and Fission DID associated with them. We created these resources using keystore-idb. Then, we issued a UCAN with the ION DID as the issuer, the user’s Fission DID as the audience, and the capability to use all Fission resources. This UCAN grants the Fission DID permission to use Fission resources, such as the Webnative Filesystem (WNFS) and our app publishing platform.
Through the normal course of using Fission, the user may grant other UCANs, such as when they link their account on a device. This first UCAN serves as the root proof of capability, and any future UCANs would include it in the UCAN proofs field as a nested token. The Fission server checks with the ION Network each time validates a UCAN with this root proof. Effectively, the user’s ION DID is in control, and if the user revokes their public key, their access to Fission resources will end.
Did it Work?
It did! After implementing all of the above, we signed up a user for Fission Drive.
To the best of our knowledge, this giphy captures the first example of DID interop between two production DID systems.
The user requests a sign-up in Fission Drive, which redirects them to the Fission Auth Lobby, where they sign up with their ION DID. After sign-up and authorization, the Auth Lobby grants Drive permission to access the user’s file system.
Revocation
We had hoped to show that a user could revoke access to Fission resources by removing an ION public key. We ran into some challenges removing keys using ion-tools, and we could not demonstrate revocation.
We think it may be possible to remove a secp256k1, and it may be the case that support for this operation with Ed25519 has not been implemented yet.
DID Interop is what we make it
With this demonstration, we have shown that DID interop is possible. We would have liked to show revocation to close the loop, but sign up and authorization are entirely possible and, in this case, not all that difficult to implement.
We invite other DID implementers to interoperate and move decentralized identity forward. None of us can on our own, but we can as a sum of our efforts.