Bridging the gap between Hyperledger Indy and Ethereum
Why and how we built our own Hyperledger Aries bridge a little early
The Aries project was established in the Hyperledger Foundation to accomplish two goals:
- to bring a measure of decentralized interoperability to the universe of wallet and agents handling DIDs and VCs anchored to the Hyperledger Indy ledger, and
- to make the Indy ledger more accessible to the outside world of SSI anchored to Ethereum and other ledgers.
But after the initial planning, theorizing, and naming was done, it became clear that finalizing the work of #2 required more progress on #1. This work is necessarily internal to the Sovrin community, and for the sake of backwards compatibility and protecting data already in production systems, this work is best lead and overseen by people with extensive Hyperledger Indy experience. Since we had until then worked with Ethereum-anchored identities and W3C-style presentation flows, we built our Indy wallet in Javascript according to what we could call an “Aries-first” approach, working backwards from W3C interoperability rather than working forwards from Indy-native approaches. This put us in a unique position to do tentative work on #2 without waiting for #1 or diving deep into historical and legacy considerations. Here is why and how we did it.
Why we needed a modern Indy wallet sooner
The SSI world has long been bifurcated between an ecosystem clustered around the Indy ledger on the one hand, and on the other, an archipelago of ecosystems and independent players, the largest of which is the Ethereum ecosystem. Large enterprises and observers from the institutional bodies of the international IT industry tend not to see this fragmentation as a beautiful and organic process of parallel development. From where our clients were standing, this landscape presented real risks of technical debt; the power of the technology was obscured by the lack of network effects and a harmonized stack. For this reason, Spherity started from open-source Ethereum codebases, which offered a very lean and adaptable interpretation of the W3C standards, and elaborating them into a highly modular SaaS solution, customizable for anchoring on different ledgers and implementing various business cases at enterprise scale.
Key to our focus on interoperability is what we see as the business value in ledger-agnostic systems and maximally portable data. Some of our clients, as well as other observers of the market, worry that the young SSI sector might be failing to adequately prioritize its delivery on the fundamental promise of true data portability and interoperability. This criterion is enumerated in both Kim Cameron’s 7 Laws of Identity and Christopher Allen’s 10 principles as a central tenet of SSI principles. In a word, “vendor lockin” is antithetical to self-sovereignty, which is why the protocol needs to be specified and governed by maximally open processes.
Platform lock-in can be almost as dangerous as vendor lockin for longterm investments, however. If an enterprise or government were to build an SSI system on one system and not another because it needed a certain feature upfront, they need to know in advance that further investments will reasonably unrestrained by this initial choice. Being “locked in” to one ecosystem or the other is only slightly better than being locked in to a specific platform or vendor, particularly at enterprise scale.
For this reason, many of our clients wanted to have cross-ecosystem interoperability on a fundamental level (VCs and DIDs) substantially tested and stable before advancing to production on application-level projects. In concrete budgetary terms, the slow, expensive process of integrating legacy ERP systems is a major investment which would rarely be undertaken for a proof-of-concept, yet which must be done before an actual production-grade system would be worth building. Calculating the risks and returns on such an investment required a cross-ecosystem wallet, which has been slow to emerge. Perhaps Spherity will be the first to offer such a wallet, when our forward-looking Indy wallet and our Ethereum-based wallets begin to interoperate across a seamless joint interface in the coming months.
After we initially focussed on custodial wallet solutions with encrypted key stores, cloud HSMs and Multi-Party Computation, we started working on Bring-Your-Own-Key Management options to enable non-custodial implementations for our customers as well.
The meat of the matter: Credential issuance and exchange across systems
The core functions of any SSI wallet are receiving, storing, sharing, and perhaps most importantly verifying Verifiable Credentials issued by authorities or presented by counterparties. Wallets also have to be able to provide platform-specific information to issuers to even have original credentials issued to them. Being about to work with multiple platforms entails all the different encryption and signature mechanisms of all platforms involved to be handled seamlessly under the hood, without the end-user having to think much about blockchains or encryption curves. But VCs aren’t just formatted differently across systems — they have totally different dependencies and information flows.
Indy issuance, for example, requires a pre-existing, ledger-registered credential schema against which each attribute in a credential can be separately encrypted and signed. This is a prerequisite for selective disclosure using zero-knowledge algorithms which slice out pieces of VCs leaving the rest encrypted. In most of the Ethereum universe, by contrast, a similar kind of selective disclosure is achieved by putting less information into each VC and bundling them as Verified Presentations (decomposable into separately-accessed VCs which can be rebundled selectively). Credential definitions or other VC semantics are sometimes pre-registered, sometimes ephemeral, and sometimes not used at all.
Issuing across these kinds of logical divides requires a comprehensive, if slightly inelegant, solution: the requirements of all systems must be met, even if this adds steps and complexities for all involved. Even if a VC was designed to be sliced up by zero-knowledge disclosure, it still needs to be wrapped (alone) in a Verified Presentation for some wallets to receive it. Similarly, re-issuing a simpler VC from an Ethereum system to an Indy wallet requires finding a registered definition it can be mapped to, even if inelegantly.
To build an Indy version of Spherity’s cloud identity wallet harmonized with our earlier, Ethereum-based wallet, we had to add steps to our issuance process, renaming and reconceiving our API calls to align with the Aries terminology and all the steps required for compatibility across platforms. Once we port have ported these changes back to our Ethereum-wallet, the next step will be to create a hybrid wallet that can manage both inside one interface, creating a usable way to do agent-to-agent communications and transactions internally.
In a tentative way, our multi-user, enterprise system has already modeled and tested the ambitiously agnostic “agent-to-agent” communications of the Aries project by tabling one of the most tricky aspects: security. Since Spherity’s cloud platform operates individual wallets with their own custodial keys in segmented or distinct networks, these operate as distinct agents representing different identities. These individual wallets can communicate “agent-to-agent” within a security perimeter and within a shared context, without necessarily knowing that they are autonomous actors within one system which is “speaking to itself”.
DIDComm: Batphones today
DID-based messaging is another, clear example of Aries interoperability happening “in miniature”: the independent components in Spherity’s modular system talk to one another as if they were distinct “agents”. Since the early days of SSI, architects have been imagining a far-off day when peer-to-peer communications could be initiated without any third party dependencies or traces being left, not even those of the Domain Name Service (the global namespace of the internet). Phil Windley, founder of Sovrin and cofounder of the Internet Identity Workshop, calls this the dream of a “batphone,” in playful reference to the magical technology of the superhero Batman.
Today, there are enough DIDs out “in the wild” on different live, production-grade systems that we can start to build and test such a batphone. A stripped-down core of the Aries wallet-to-wallet communication protocol outlined in Aries was moved out of the Hyperledger Foundation recently to take advantage of the leaner, faster incubation process of the Decentralized Identity Foundation (DIF). This project, codenamed “DIDComm”, attempts to agree on the bare minimum of features and functionalities, such that simple messages can be exchanged between all wallets, ideally to enable or accompany exchange of credentials and presentations.
Today, there are enough DIDs out “in the wild” on different live, production-grade systems that we can start to build and test such a batphone. A stripped-down core of the Aries wallet-to-wallet communication protocol outlined in Aries was moved out of the Hyperledger Foundation recently to take advantage of the leaner, faster incubation process of the Decentralized Identity Foundation (DIF). This project, codenamed “DIDComm”, attempts to agree on the bare minimum of features and functionalities, such that simple messages can be exchanged between all wallets, ideally to enable or accompany exchange of credentials and presentations.
Future Outlook: Interoperability
Spherity’s enterprise wallets, managing identities and credentials in two different families of implementations, will be combined in the coming months to offer a unified interface spanning two platforms. This internally-interoperable solution will offer a kind of sandbox for the interoperability long promised by the community, and soon to be specified and refined by the Aries and DIF communities. Our modular approach has a lot in common with the modular and composable “protocols” and “drivers” making up the Aries model, so we are confident that we will be able to stay current with Aries as the protocols get more explicitly defined and refined by the community. We have initiated the process of becoming full Sovrin stewards to take part in this refinement.
To start playing with our solutions and seeing firsthand how identity wallets can be created, delegated, and managed at the enterprise level, drop us a note at hello@spherity.com.
To be kept up-to-date as new features roll out and new capabilities get built, follow us here on Medium, or on Linkedin, or sign up for our email newsletter.
