Now that I’m not involved in DIDs and VCs full time, I tend not to find myself engaging with this space as much, but I definitely want to call this essay at as a MUST read for those exploring the SSI space.
Kaliya IdentityWoman Young has really taken the time to break down the nuances of a very technical conversation and distill it to non technical readers in a honest and fair assessment of Hyperledger Indy, Aries, and more specifically Anoncreds.
I know and have been heavily involved with many of the people who have driven this work forward for years. When I was at Evernym I had the privilege of helping to build out the Aries stack and get that project running. I also, spent a small portion of time working on the token that was meant to be launched for the Sovrin network. I have a massive amount of respect for the work and commitment put in by various leaders in this portion of the community. Without their hard work to spread the word, spend millions of investment on shipping code, and drive the standards forward the SSI community wouldn’t exist in the form it does today.
With that in mind, I think it’s important that these points are raised so that good discussion of progress can occur. Some aspects of the Hyperledger SSI stack are useful and will exist in more useful forms than others. For example, the Sovrin ledger has been a well known implementation of SSI that has struggled in the past and with the immense amount of time and effort that ledger is now in a much better state compared to when I worked at Evernym. I’ve witnessed many of the changes, discussions, and late night efforts by many people to keep the Indy node codebase working in production and they’ve done an amazing job at it. It’s only when I started to take a step back that I realized that the architecture of Indy being a private, permissioned ledger leaves it heading in the same direction as many large corporations now extinct browser and intranet projects for many of the same reasons. Private networks lead to expensive costs that are hard to maintain (read expensive) and the means to maintain them often time don’t outweigh the value they create. It’s only through sharing in an open network that we can leverage economies of scales to make the value outweigh the costs because they become shared. That’s why the internet has filled the space where the corporate intranets have failed.
With respect to Anoncreds, there’s been some incredibly well intentioned desires to deploy private and secure solutions for VCs that can be enforced by cryptography. This was the original reason why CL-Signatures were chosen to my knowledge and it remains one of the most motivating factor for that community. They truly believe that privacy is a first class feature of any SSI system and I 100% agree with the principle, but not the method chosen (anymore - at one point I thought it was the best approach but with time comes wisdom). Privacy erosions aren’t going to happen because selective disclosure wasn’t enabled by the signature scheme chosen. They’re going to happen at the legal layer where terms of service and business risk is evaluated and enforced. The classic example of presenting a driver’s license to prove you’re over 21 is a perfect example of this. Sure, I could share only that I’m over 21 and that I had the driver’s license issued by a valid issuer. However, this opens up the possibility that I could be presenting someone elses credential so I also need to present additional correlatable information (such as a photo or a name) to prove I am the person who the credential was intended for. This is because authentication is inherently a correlatable event where with a greater correlation of information the risk of a false positive (e.g. authenticating the wrong person) are reduced. So, for businesses who are trying to validate a driver’s license they are naturally going to trend towards requiring a greater amount of information to reduce their legal risks. The same issues are even more pervasive in the KYC space. So, in my opinion selective disclosure is a useful optimization tool to assist, but it’s only with proper differential privacy analysis of the information gathered, legal enforcement and insurance to offset costs of risk that we’ll achieve better privacy with these systems.
All in all, I think this is an important discussion to be brought up. Especially as the VC v2 work begins underway and explores where it’s important to converge the options between a variety of different deployed systems. There’s bound to be tough discussions with some defenses resting on sunk costs fallacies, but for the best of the SSI community I think these things need to be discussed openly. It’s only when we start having the truly hard discussions about deciding what optional features and branches of code and specs can be cut that we can start to converge on an interoperable solution that’s useful for globally. Thank you Kaliya for resurfacing this discussion to a more public place!