Response to Kaliya’s “Being Real” Post
A notable critique of Hyperledger Indy, Hyperledger Aries, and AnonCreds was published by Kaliya Young (Identity Woman) last week. The post surfaces an important topic and contains some truth worth telling. I salute Kaliya for that, and for the honorable intentions behind her writing. However, the post also contains some factual errors, and its narrative both assumes and invites conclusions that I consider unjustified. I want to suggest that we map the space a bit differently. Hence, this public comment.
At this point I am two employers removed from heavy involvement in the Indy-Aries-Anoncreds stack (I’ll call it IAA for concision, though that isn’t a standard acronym). I left Evernym not long after the pandemic began. That means I no longer have a lot of skin in the game. My current responsibilities don’t fit with me attending IAA community meetings, making or reviewing contributions, or serving on the Sovrin Technical Governance Board. However, I was once a very active participant there, giving me some meaningful first-hand experience. I also know and admire the people in that community. This motivates me to ensure that IAA is evaluated accurately and fairly. Perhaps if that sort of evaluation happens, some will still decide IAA isn’t for them — but if so, my subjective opinion is that it shouldn’t be for the reasons the critique suggests.
I don’t have the time to write a point-by-point response, but perhaps a multiplicity of voices will address the most important subtopics. I hope others write about the dynamism and creativity of the open source community behind Aries, for example, which is nowhere near the monolith Kaliya implies. As you might expect from its Linux Foundation roots, it’s egalitarian and sensitive to real production requirements in very healthy ways. I hope they describe how Aries and AnonCreds are now meaningfully independent from Indy, with further improvements coming soon. There’s significant momentum on that front. I hope they explain how the critique’s analysis of performance is rooted in a misperception of the way Indy stacks use the blockchain. I hope they detail how section 6 of the VC spec contradicts the post’s claim that serialization formats are normative for compliance to the VC spec. And so forth, and so forth.
However, there are two issues with the blog post that I want to address here.
The Privacy-Trust Paper as an “Explanation” of Link Secrets
A significant section of the critique is about link secrets, and it repeats the old claim that they are insecure. The post cites for support a 2019 paper by Arnold and Longley that was published in a special issue of the IEEE Communications Standards magazine.
I am already on record as asserting that the 2019 paper has inaccuracies and misrepresentations — and that its explanation of link secrets is particularly flawed. I stand by my assertion. The month after that article was published, I wrote a detailed rebuttal and sent it to the W3C CCG. My plea then was that people should know about both sources, and that if they read one, they should read the other. I repeat that plea now. Read and ponder both — including the supporting documentation. Then decide for yourself which view of link secrets and ZKP credential security is grounded in reality.
You should not conclude from this challenge that I think link secrets are ideal or even complete; far from it. Kaliya is right to point out that they can be shared — but so can the key that controls a DID (which is the basis for holder binding in most alternative implementations of VCs). Thus, the criticism applies to the entire VC ecosystem and is overblown, not revelatory. There are reputational reasons why DID key sharing isn’t likely — and there are also incentives that make link secret sharing unlikely. Discussions that aim to be fair-minded should surface the whole story.
A Misunderstanding About Credential Formats
The post encourages the perception that, since the format of AnonCreds credentials doesn’t match one of Kaliya’s two preferred serializations, JSON-LD or JWT, AnonCreds are therefore at odds with the standard.
It is true that the AnonCreds ecosystem is out of alignment with several points in the VC spec. But the reason why is mis-described in the post, exactly as it has been mis-described and misunderstood in the SSI space for years. Let’s fix that. Please, if you care about better dialog in our space, take the time to carefully read what follows.
I believe the IAA community and the rest of the VC community are talking past each other because we don’t realize that we’re using the one-word term “credential” differently. Note how that is different from saying we disagree about the meaning of the two-word term, “verifiable credential.”
To understand the significance of the distinction, consider this question: What construct from the AnonCreds world should be evaluated for alignment with the standardized concept of a verifiable credential?
Many people, both inside the IAA community and outside it, seem to assume that the “Creds” in “AnonCreds” is that construct. Given the way language works, it’s hard to fault the logic. But if so, no wonder we’re all frustrated, because that’s totally incorrect. It is externally visible AnonCreds “proofs” that should be evaluated as verifiable credentials, not the inward-facing credential construct that gives AnonCreds its name.
In the worldview of most readers of the VC spec, a held “credential” is designed to be shared and verified — either directly, or wrapped in the envelope of a verifiable presentation. What you hold and what you share have the same format because they’re the same object. Thus “credentials” are a natural locus for interoperability.
But the VC spec constrains data models; it doesn’t actually require what you hold and what you share to be the same object instance.
AnonCreds happened to define the one-word term “credential” earlier — and differently — than the W3C. It splits what’s held and what’s shared into separate objects. The role of the thing that AnonCreds calls a “credential” is NOT to be shared; it’s to help a holder generate a derivative object in a distinct format each time something interesting needs emitting to the outside world. These derivative objects, which are called “proofs,” are what an AnonCreds holder shares with verifiers. If you squint away some details, they are just-in-time, fit-for-one-purpose verifiable credentials (note the two-word term, and my hedge word “squint”).
Verifiable AnonCreds “proofs” are thus candidates for alignment with the VC spec, but internally-facing AnonCreds “credentials” are not. They never have been, and they never will be. Since they shouldn’t be shared, their interop is out of scope to the VC community writ large.
If you’re reading this post on the internet, there’s a good chance that somewhere behind your screen is a CPU using little-endian byte order. Yet TCP/IP, which brought the post to you, requires big-endian byte order. How dare Intel ignore the TCP/IP standard?! Isn’t this an interoperability disaster? Not at all. Private representations are irrelevant, as long as what moves over the public wire meets the requirements. That’s the tried-and-true CS principle of encapsulation.
Interoperability does matter to the IAA community, which is why they have formal measures of it (and substantial intra-community success with it). The IAA community also cares about building bridges outside its own community, and has work to do there. But that work isn’t about what it calls credentials — it’s mostly about what it calls proofs. If AnonCreds proofs were serialized as verifiable presentations containing properly modeled verifiable credentials, and if a few other minor details were cleaned up, the VC spec’s guidelines would be satisfied, regardless of the AnonCreds “credential” format.
This work can be done, and it’s not particularly hard. It doesn’t require most of the changes that people have been browbeating the IAA community about. It doesn’t require that AnonCreds “credentials” change the way their schemas work to give them JSON-LD contexts. It doesn’t require that AnonCreds give up its ZKPs. It doesn’t require BBS+ signatures. All it requires is a mapping between the content of an AnonCreds proof and the data model that the VC spec requires. The existence of such a mapping, which must be deterministic, is what allows a data structure to claim conformance to the VC data model standard.
And guess what? The mapping’s already been created. I built it in the summer of 2020, and referenced it in PR #2223 to the Indy SDK. (Thank you to Jonathan Rayback, from Norton/Avast, for visiting this PR recently and commenting with content that fixes the old Google docs links referenced there.)
But the PR was never merged — and that was the right call. What I wrote was ugly proof-of-concept code that required a dirty hook into the private parts of a cryptographic data structure. Rewriting the algorithm to fetch data a different way wouldn’t be hard, but I never got around to it. I just didn’t have an extra two weeks to code.
This might seem incredibly lazy or unfortunate, but it brings me to my larger claim:
There’s no point in completing this PR.
If my code were fixed and Hyperledger Indy got the ability to emit proofs as verifiable presentations with VCs inside them, I honestly don’t believe it would unlock a single interoperability win in the next several years.
The PR has already languished for almost that long, which confirms my suspicion.
I think it’s because we all know, or at least intuit, that AnonCreds credentials having controversial security or being intransigently non-compliant is only a small part of the real misalignment. We’ve made enemies of each other, and reinforced that enmity by dissing each other’s solutions to customers. If I look below the high-level idealism, the IAA community and the rest of the VC community fundamentally disrespect one another’s approaches to privacy. Even if our tech spoke the same language, would we be willing to alter our UX and messaging so users think about privacy the way a different credential technology demands? I doubt it. We advocate different security goals. We argue about signature mechanisms and serializations of cryptographic material. We pit DIDComm and CHAPI and OIDC against each other. We disagree on how revocation should be handled. We don’t see eye-to-eye on DID methods — not just which methods to use, but why, and when, and whether the methods must support self-certifying identifiers or queries about timestamps/versions in the past. And so it goes…
I feel like the real interoperability challenge in our community is human, not technical. That is not a criticism, just an acknowledgement that we have human work to do. I know I do.
Let’s work on that together.
