September 13, 2022 By Mathieu Glaude
Introduction
My name is Mathieu Glaude. I’m the CEO of Northern Block, a company bringing products to market that will help people regain sovereignty and privacy over their lives.
We’re hopeful that we can be one amongst the many contributors that put the building blocks in place to ensure that people’s rights are protected.
We’ve therefore chosen to build our products (Orbit Edge, Orbit Enterprise) on self-sovereign identity principles and open standards & technologies.
I only personally started diving deeper into the world of digital identity in 2019, when as a company, we lacked an elegant way to let users interact with decentralized governance systems that we were building using combinations of blockchains, crypto, smart contracts, etc.
I must say that these past few years have been quite the learning journey for myself. I’m fortunate to be surrounded by a team of brilliant curious individuals who help push my knowledge every day.
I also took it upon myself in 2021 to start doing the SSI Orbit Podcast with thought leaders in the digital ID space, with an objective to push the industry forward.
Today, Northern Block is one of the many organizations contributing to Hyperledger Aries (and consuming it).
At this time, I felt like it made sense for me to share some of our learnings as contributors and developers of systems that use Aries, Indy and various verifiable credential implementations.
As I wrote this blog post, two things became apparent to me.
- The various elements are evolving with the community to address specific use cases, and interdependencies between them are being eliminated to allow for ultimate flexibility and interoperability, where required.
- Convergence seems to be happening across various elements of the ecosystem. Standards such as OIDC and mDL are all now in dialogue with W3C, AnonCreds, Aries, etc. Mobile is a predominant technology, just like the way laptops were once upon a time. To reduce consumer friction and drive adoption, convergence of all these different technologies is required inside a mobile environment
I hope this blog post is helpful both for people familiar and unfamiliar with Aries, Indy and AnonCreds.
I look forward to continuing learning together to help people regain sovereignty and privacy over their lives.
Learnings from Aries, Indy and Various Verifiable Credential Implementations
1 Aries Protocols vs Aries Frameworks
When talking about Aries, I think it’s important to first differentiate Aries Protocols from Aries Frameworks.
Aries Protocols are the defined set of Request for Comment (RFCs) for the Aries project. They basically describe important topics that we want to standardize across the Aries ecosystem.
On the other hand, Aries Frameworks are implementations of the Aries Protocols. Examples include Hyperledger Aries Cloud Agent – Python (ACA-Py), Aries Framework JavaScript (AFJ), Hyperledger Aries Framework Go, and others.
Some folks in the community have reasons to use one Aries Framework over another. We at Northern Block have chosen AFJ for our mobile wallets and ACA-Py for our cloud wallets. We wrote about some of the reasons for choosing AFJ in this recent blog post.
Challenging implementations is one thing, but the protocols are what the community is committed to continuously improving together.
The tools (frameworks) can come and go, but if we mess up the protocols, it won’t matter what tool we wish to use to implement them.
2 Aries Protocols Aren’t Tied to Indy
Aries is a messaging protocol between peers, with no reference to specific implementations, meaning that Aries is detached from Indy.
And what you move on these messaging pipes needs to refer to something stored externally, such as a wallet, ledger, or context.
You don’t know what tech stack the recipient is using. So you need interoperability on the pipes so that people can receive, interpret, etc. How they store it after that doesn’t matter. So Indy isn’t actually on the pipes.
The fact that Aries refers to Indy today is only as reference implementations. Though it’s mentioned, we shouldn’t read it as it’s tightly coupled, but instead a reference storage format. While it is important that protocol definitions stay independent from technical stacks, today they are not. Work must be done to make it clear in documentation that they aren’t tightly bound.
Let’s take an example of an Aries RFC that refers to Indy. In the Present Proof protocol, you can implement the Aries protocol and attach different presentation formats.
From Aries 0454-present-proof-v2, not tying Aries to any presentation formats
The Aries protocol choreography (the heart of Aries) also shows that any presentation format can be attached to run it. It has nothing to do with any particular storage technology.
From Aries 0454-present-proof-v2, Choreography Diagram
3 Aries Protocols Aren’t Tied to AnonCreds
Now that we’ve separated the messaging protocol from the storage, let’s look at how credentials can be stored.
Right now Northern Block is focused on building use cases which are privacy-preserving, thus best suited for AnonCreds. We have looked at use cases where JWT and JSON-LD credentials would be a good fit.
The AnonCreds specification is being developed to address a privacy-preserving specific use case with participation from the community.
It’s an independent specification which has evolved into its own things. AnonCreds are completely separate from Aries. And the community is working towards making AnonCreds independent of any ledger stack.
It’s good to see the data exchange protocol and the process protocol being developed independent of how credentials are stored. Aries is being developed to address data exchange and business process protocols, whereas AnonCreds are being developed for how credentials are stored and how they can be cryptographically secure. They are totally independent.
Depending on the use case, you can choose the right combination of business process protocols. For example: mDL. For interoperability to work, one can replace Aries with mDL and use AnonCreds. Work is also in progress where the AnonCreds specification will be used to store credentials which can be consumed by OIDC.
Ultimately the goal is interoperability and this is what we’re moving towards. That’s where community contributions are happening.
The next version of the AnonCreds specification (tentatively v1.0) will remove from the v0.1 specification any dependence on Hyperledger Indy by removing any requirements related to the storage of the objects used in AnonCreds, whether they be stored remotely on a “Verifiable Data Registry” (including Hyperledger Indy) or in local secure storage.
4 AnonCreds are Purposely Different from the W3C VC Data Model
AnonCreds are intentionally different for a good reason: the ideal number of credential formats/types is > 1.
Certain credential types are better for different use cases. Indy/Aries does support multiple credential types to allow for this.
The biggest concern is with high assurance government credentials such as a verified person. This type of credential must support the privacy preservation provided by zero knowledge proofs and supported by AnonCreds. We don’t want to create the equivalent of a modern tracking cookie bound to a high assurance credential that uniquely identifies a person.
Further, we might want to use different credential formats for different schemas. Combining different credential formats could be great for certain use cases.
For example, I may want my address to be privacy-preserving (AnonCreds), whereas my tickets to a sports game shouldn’t be, and should be transferable (pick your W3C credential data model).
Again, If you’re looking for more details around this, we’d suggest you refer to Daniel’s paper, which did a great job at explaining this.
Though current implementations are that credential and schema definitions are posted on an Indy ledger, nothing is stopping anyone who implements the Aries Framework and the AnonCreds specification to use their ledger technology of choice.
5 CL signatures
Currently, CL signatures are used to serialize the payload prior to storage.
First, CL-signatures have a long history of successful usage. Real-world usage shows it is at an acceptable level for the performance of hardware.
Secondly, Anoncreds are not explicitly tied to CL Signatures, and are replaceable/upgradeable in the future.
In the current state, CL signatures solve specific use cases around privacy preservation that are not possible with traditional public/private key cryptography.
Privacy preservation for high assurance issued credentials is a must have requirement for certain use cases and must be addressed by the digital ID community.
Now that some of the advantages of BBS+ signatures have become relevant for privacy-preserving use cases (such as selective disclosure), Northern Block is actively involved in having W3C verifiable credentials with BBS+ signatures in Aries agents. It’s being developed right now and is close to being available across the various frameworks.
This is an area of considerable alignment across all standards, although there are still some technical challenges to solve. As an industry we need to push NIST, BSI and other standards bodies to fully certify the core crypto technologies. This is not only an Aries problem.
6 Aries Protocols Are Built with Interoperability in Mind
If VCs can be stored in different formats, can we achieve interoperability when business processes involve multiple participating entities who may choose different tech stacks?
Yes.
Peers can be on different tech stacks. For example, Northern Block uses ACA-Py for cloud agents and AFJ for mobile agents.
Interoperability isn’t about how credentials are stored. Interoperability is about the proofs that are exchanged, not what a holder is storing. How data is stored isn’t what matters in this context; what is returned is what matters. What a holder exchanges is a proof, not a credential itself.
Aries frameworks are where interoperability gets demonstrated and tested. Hence the message sent by one peer must be interpretable by the recipient peer. Aries agents / Aries frameworks developers must ensure that they are developing with interoperability in mind.
For those developers there are the Aries RFCs that outline all of the protocols and interopathon events to put all of the parties together. There are multiple reference implementations that any party can use to test their implementation, and all of this is open-source.
Interoperability is assessed using the Aries Agent Test Harness (AATH), an open-source software that runs a series of Aries interoperability tests and uses a Behavior Driven-Development (BDD) framework to run tests that are designed to exercise the community-designed Aries Protocols, as defined in the Aries RFC GitHub repo.
Towards the end of 2021, Northern Block demonstrated AIP 1.0 Compliance of its Orbit Edge Mobile Wallet against the AATH (here).
AIP 2.0, builds on AIP 1.0 including how Aries agents can exchange several types of verifiable credentials, including W3C standard verifiable credentials.
7 Aries Frameworks Are Built For Mobile
Now let’s move to Aries frameworks.
At Northern Block, we’ve built multiple Aries wallets. Over the past few years, we’ve built them using different architectures.
Lately, we have selected AFJ (here), but earlier we were using other technologies.
As more choices became available, we had more options to choose from. As the adoption of SSI increases, we expect more options to become available.
For the time being, there is no Aries Framework Swift – not because it is impossible – just that not enough people have wanted to put in the effort to make one. The same thing is true with Flutter. There is nothing stopping people from writing these and making them open-source.
AFJ is currently fitting the role with support for React-Native cross-platform mobile development.
Newer wallets have sizes of 50 megabytes or less. This represents 0.3% of the storage space on low end (cheap) smartphones.
We’ve however seen an issue in size with the limitation in the revocation registry, rather than storage. This is an issue to be addressed, but is proven to work today and is sufficiently scalable for real-world large credential deployments. No standard has a great revocation story right now and we need to ensure revocation scalability is there for use cases which need it.
8 Aries Protocol And Frameworks Continue to Evolve Through Community Learnings
Open standards should be given time to emerge, evolve, and mature. And this has been the case with Aries protocols and frameworks. This has been a global effort.
For example, let’s take the evolution of how connections have been handled by Aries:
RFC-0160 –> RFC-0023 –> RFC-0434
You can see an evolution of the protocol as we continued to learn, making this one a good example of agility and upgradeability.
With the first implementation (0160), there were challenges (e.g., the ability to re-use connections wasn’t possible, limited support for the type of DID Documents).
It evolved into the second RFC (0023) based on DID Exchange and supporting multiple DID Documents.
It was then superseded by 0434 which addressed remaining challenges and provided a way to support the previous two, while creating a space for new handshake protocols to be supported as they evolve.
The main value is that when I create an invitation, I give the choice of protocols that are supported. And we can list any number of them, which takes ties away from any one specific way of doing things. Earlier this wasn’t the case.
We expect other protocols to continue evolving through community participation.
—
At Northern Block, we want to continue building robust privacy-preserving solutions and would love to engage in more conversations on how those solutions can be built while keeping interoperability with other use cases and tech stacks while avoiding vendor lock-in.
