Credential Synchronization for Edge Wallets

Inspiration

Credential management in Self-Sovereign Identity wallets is essentially still in its infancy. This is especially visible in the lack of creating proper wallet backups that contain all the relevant key material and the Verifiable Credentials themselves. This leads us to the actual problem we want to tackle, the lack of credential synchronization is immanent. People usually have multiple digital devices that they can use to interact and transact on the Internet so there is a high need in reusing the credentials on multiple devices more or less in the same time. But currently, this is widely not possible due to the previously mentioned lack of credential co-existence on multiple wallets. You could manually export them on the one device, and import it on the other but this is incredibly inconvenient. And secondly, issuers of credentials do or should revoke the previous credential if a new one is issued to the same identity. So having two identical credentials at the same time is at least hard to achieve. This applies to cloud instances but especially to edge agents.

What it does

Our project does relocate the storage location away from the wallets in a decentralized and opaque storage grid from StorJ. The credentials are stored there and made accessible through an interface to the wallets. This allows different wallets that hold the same DID to have a shared credential storage. When a credential gets issued, only the metadata remains on the device itself so that the user knows which credential she is in possession. The actual credential is straight forwarded to the user's sovereign directory in StorJ and indexed over its credential ID. If the user wants to present the credential, she selects the credential in the wallet which triggers a call operation that forwards the credential's data to the wallet where selective disclosure and the presentation takes place. In order to create the private directory, the user requires to have a private and persistent piece of data that is only known to the user. It acts as the key to the sovereign directory in StorJ. Like with a private key, if this secret is known or available to the public the identity credentials are compromised. Other devices periodically check whether a new credential has been added or removed to the directory and pull the metadata of the credential in case it was put there by another device.

How we built it

In order to achieve our goal, we sticked to the provided technology. Such as the DID method "ION" based on the Sidetree protocol and as well as the Microsoft Authenticator app and the provided Identity hubs. However, our goal was to integrate StorJ. Therefore, we utilized the StorJ S3 Gateway which allows us to store and retrieve secrets. We implemented an interface out of Azure's Verifiable Credential (preview) resource where we set an API that stores the credentials in StorJ using their S3 gateway. This gateway allows to push and pull data from StorJ's decentralized and opaque storage grid in a widely used manner.

Challenges we ran into

Our main challenge was the inability of the Microsoft Authenticator App to export single credentials. This made it impossible for us to export these data directly from the edge agent. To overcome this problem and to demonstrate the purpose and usability of our solution, we utilized Azure's Verifiable Credential (preview) resource which acts as a cloud agent.

Accomplishments that we're proud of

We are proud of our team and our results. We haven't known each other before but were open to everyone's ideas to implement and came to an unanimously decision of which project we developed. We were able to organize tasks and updated each other regularly about each one's progress.

What's next for Credential Synchronization for Edge Wallets

We have achieved our minimal goal of outsourcing storing the credentials to an external and encrypted open-source storage grid. Storing the credentials is only the first step. In the future, we could extend this to store also the public and private key pairs and essentially replicate the wallet storage on there. Since it's using the W3C Verifiable Credential standard, this process could be integrated into any wallet that supports this standard. We will put our work under an Apache 2.0 license so that it can be reviewed and improved by our community. We also envision integrate it into official recommendations from the W3C, DIF or/and Aries.

Built With

• did
• s3
• storj