The Intersection Between DID and Decentralized Relational Data

Last week, the Kwil team returned from an interesting and productive week at EthCC in Paris. One of the prominent themes at the conference was Decentralized Identity (DID) solutions, and the two main approaches to implementing them: self-sovereign identity (SSI) and ID protocols. This blog will unpack the key differences between self-sovereign identity and ID protocols, and the applicability of decentralized storage solutions to each.

Self-Sovereign Identity

Self-Sovereign Identity solutions offer users the ability to plug their ID data into applications, akin to a digital passport stored in a wallet like MetaMask. With SSI, users can provide their credentials to desired applications without having that sensitive data stored by third parties. The core benefit of SSI lies in enabling users to manage and share their identity data on their terms, promoting autonomy and privacy.

Benefits:

• Privacy: Users store their personal data on their local machine.
• Transparency: Users sign ID transactions to validate their identity to applications - when and where PII data is accessed is explicit to the user. 

Drawbacks:

• Data Safeguard Risk: Users must ensure the security of their digital identity to prevent data loss - if a private key or password is lost, so too is the identity data. 
• User/Platform Liability: In case of identity theft or regulatory disputes, the absence of central authorities can complicate resolutions, especially when it comes to KYC compliance verification. 

‍Identity Protocols

ID Protocols take a different approach to decentralized identity - the goal being to strike a balance between user data access controls and the ease of use for third party applications to access their user data. Platforms that require Know Your Customer (KYC) checks to provide services to end customers need assurances regarding the persistence of their user data. This is especially true for companies operating in regulated industries. For example, let's say a crypto exchange (e.g. Coinbase) wants to adopt an identity protocol. The benefit of doing so is that an identity protocol would unlock a large repository of users that can be seamlessly onboarded without having to repeat the KYC process. However, Coinbase must maintain access to those KYC’d users in case a regulator asks for the identity of a flagged account holder. Identity protocols provide user data access guarantees, eliminating this platform risk. At the same time, Coinbase does not have to worry about maintaining their own internal database, since it can offset that responsibility to the identity protocol on which they are built.

This approach also enables mutually beneficial data sharing. User credentials as a subset of a large, unfragmented dataset are valuable to third party analytics. Contingent on the user consent, residual rewards can be a great way for users to generate passive income from data that would otherwise only be used to sign into applications. 

Benefits:

• Platform Risk Mitigation: Applications can have confidence to build on top of ID Protocols because perpetual access to the database is guaranteed.
• Data Origin Verification: In the event that a regulator or other third party requires the origin of user data, it can be easily referenced and tied to a KYC’d user.  
• Incentivized Data Sharing: Users can give consent to share their ID data with third parties, leading to a smooth application onboarding as well as residual rewards for access to that data. 

Drawbacks:

• Identity protocols store data across a distributed network, placing a strong emphasis on encryption and data protection mechanisms.

With regards to the first benefit, Kwil’s federated database infrastructure is well positioned to balance platform risk mitigation and GDPR compliance. Federated networks can apply strict rules around where and how nodes can operate, maintaining regulatory compliance around PII data storage (nodes located in the EU, the right to be forgotten, etc.). This, in addition to the immutable codification of rules for database access and manipulation, eliminates platform risk for applications that build on top of Kwil supported identity protocols. 

Both SSI and ID protocols offer unique benefits, and finding the right approach will depend on the values and requirements of users and platforms. Their offerings position them to be attractive to different use cases. A crypto native user may find the privacy of an SSI service compelling, whereas identity protocols are compelling to projects looking to adapt and contend with the regulatory climate of web3.

For mass adoption, identity protocols are preferable to self-sovereign solutions because they allow applications to maintain persistent read and write access to user datasets, mitigating platform risk and making building applications on top of this data seamless. In addition, third parties have regulatory requirements to both verify the content of their user ID data and where it is stored. For many projects, pointing to an identity transaction associated with an ID wallet is not sufficiently verifiable.

The unique unlock Kwil provides is the ability to mitigate platform risk (persistent user data access) while also upholding GDPR node location and deletion requirements. In a self-sovereign system, a regulated company would still have to maintain their own centralized database of identity records, thereby eliminating a lot of its benefits. On the flip side, Kwil directly addresses legal and privacy concerns, making it a more attractive alternative to regulated companies than SSI.

It will be interesting to see how the DID space evolves and the different applications built on top of these protocols. What’s becoming increasingly clear is that the advancement of web3 is contingent on effective DID solutions that make user onboarding seamless and allow applications to remain compliant within the jurisdictions they operate.