Achieving AIP 2.0: Increased Interoperability

1 What is Aries Interop Profile (AIP)?

Aries agents are all united through the standards and protocols they aim to adhere to, and the underlying technologies:

• Cryptography
• DIDs
• DID Utility Ledgers
• Verifiable Credentials

As Digital Trust ecosystems evolve, they will naturally require many technologies to coexist and cooperate.

Stakeholders and users will not care about incompatibilities — they will simply wish to take advantage of the benefits of digital trust.

Interoperability ultimately means more than just Aries agents working with each other. It covers worldwide standards and paves the way for broader compatibility.

Interoperability will drive scalability while identities/subjects make self-sovereign choices. The technology must ensure that these choices don’t result in digital trust ecosystems losing trust.

To prevent vendor lock-in, interoperability must enable different ledger (and non-ledger) choices, and credential formats provided by identities/subject to co-exist.

Today if we have to present two forms of ID at a bank, we have to present two seperate documents. The bank requires two different verification technologies/processes to ensure the two documents can be trusted. This process is very expensive, time consuming, and it also drives unique training needs — an additional cost. In this example, interoperability means that the same document reader can read both a Driver’s Licence and a Passport — a very cost efficient and trusted process for the economy.

If Hyperledger Aries is to continue to flourish, these are the five drivers that we think must be taken into consideration when talking about interoperability:

1. Drives Scalability 🚀
2. Maintains Privacy & Security 🔐
3. Avoids Diluting Other Standards’ Principles 💪 (e.g., if Aries should be interoperable with mDL, you can’t dilute the principles of mDL)
4. Drives Adoption through Cost Efficiencies 📉
5. Ensures Tech Stack has long-term viability 🛸 (not a short term bridge solution)

2 How We Achieved AIP 1.0

Towards the end of 2021, Northern Block demonstrated AIP 1.0 Compliance of its Orbit Edge Mobile Wallet against the Aries Agent Test Harness (AATH) (here).

Interoperability is assessed using the Aries Agent Test Harness (AATH), which is 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 GitHub repo.

https://medium.com/r/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DWkPuEuf9K3Y

AIP currently has two versions:

• AIP 1.0, defines how Aries agents communicate with each other using a single type of verifiable credential, and
• AIP 2.0, builds on AIP 1.0 including how Aries agents can exchange several types of verifiable credentials, including W3C standard verifiable credentials.

Our work since these demonstrations has been to move the needle towards AIP 2.0 Compliance for both our Orbit Edge Mobile Wallet and Enterprise SSI Cloud Platform.

3 Why We Chose Aries Framework JavaScript (AFJ)

To achieve AIP 2.0, Northern Block needed both our Cloud and Edge agents to support it.

Our Enterprise SSI Platform (Cloud Agent) is based on ACA-Py 0.7.3, which already provides support for AIP 2.0. However, ACA-Py can only run in the cloud — so it wasn’t an option for our mobile environments.

This section explains the reasoning behind why we chose Aries Framework JavaScript (AFJ) for our Mobile Wallet Agent to move us to AIP 2.0.

3A Vibrant Community

The first thing we looked at was the activity happening in the multiple Aries projects.

We wished to become contributors to a project with lots of activity so that we wouldn’t be amongst the sole/few contributors.

We realized that there remained a lot of work to do on these frameworks; and we wanted to share the load with others.

We saw that there were multiple contributors working on AFJ with tons of recent, and real-time activity.

This not only creates benefits for Northern Block, but also for our network of partners and clients. To avoid vendor lock-in scenarios, we recommend to our clients that if we build a product for them and for whatsoever reason they decide to no longer work with us; their code base will remain on an active open source framework and will likely continue to be maintained by us — meaning they will continue to reap the benefits of the framework updates.

With all the activity happening in AFJ, the AIP 2.0 support was where we needed it.

3B Multiple Credential Format Support

In our NB Orbit Solutions, we are agnostic to credential formats, as we want to make it as simple as possible for anyone to securely transmit verifiable data between two entities.

There are use cases where one would rather use an Indy AnonCreds credential (based on CL signatures) versus using a W3C JSON-LD credential (based on Ed25519 signatures).

For example:

• Indy AnonCreds are well suited when privacy-preserving and non-transferability are required (this makes them really well suited for government-issued credentials)
• W3C JSON-LD — these are heading towards being privacy-preserving, but are transferable (this makes them better suited today for when identity binding is not a requirement, but verifiability and trust are still important. For example: a ticket, or a medical prescription.)

This factor eliminated agents such as Aries Framework Go, which could have also been a valid option, but it doesn’t support Indy credentials.

These are some of the trade-offs that must be taken into consideration when comparing various Aries implementations.

AFJ has both Indy and W3C support and it works in React Native — which brings me to the next factor.

3C Team, Technology and Skill Set

What you’re already familiar with and what you’re building can have a big impact on what library you choose.

Our Orbit Edge Mobile Wallet is built in React Native. We chose React Native for our mobile wallet because:

1. It’s a popular language choice amongst developers (making it easier to find developer talent),
2. We wouldn’t have to create native mobile apps for different operating systems (e.g., one codebase for Apple, another code base for Android),
3. It has tons of widely used third party libraries (e.g., internationalization support).

Other agents such as Aries Framework .NET limits you to writing your application in .NET. From past experiences, we can claim that .NET is a good platform to build mobile apps in and it’s built for enterprise usage. If you already have a mobile app, or you have infrastructure, or you have developers that are familiar with Go then you probably pick Go.

It really comes down to developer preference.

4 What Excites Us About AIP 2.0

4A Out-of-band With Connection Reuse

One of the really big advantages of AIP 2.0 is the ability to conduct out of band communication with connection reuse, in a standardized way .

Out-of-band (non-Aries) communication channels are available between the Verifier and the Prover(s), to allow the Verifier to provide a URL to the Prover.

• Could be an email with a QR code to be scanned by a wallet and a link to be opened on a mobile device to be handled by a wallet
• Could be a web page displaying a QR code
• Could be a QR code printed by the verifier and posted

In-band connection will use a secure, private communication methodology built atop the decentralized design of DIDs: DIDComm Messaging.

The outgoing messages are based on DIDComm Messaging, however it doesn’t use the in-band routing and encryption as defined by the DIDComm spec — but the replies are.

So as a first step, while there is no connection, you’re able to send a message using an out-of-band technology. And then you establish the DIDComm connection.

AIP 1.0 was missing a standard way to reuse connections. Labels could be used to identify the requester of the connection, and to not create duplicate connections when the same requestor sent connection requests. Hence techniques such as labels were used as a way to drive connection reuse — resulting in proprietary implementations to achieve connection reuse — a weak point.

In AIP 2.0, the RFC added standard out-of-band for connection reuse as part of the protocol. It can be used as a generic out-of-band invitation to either create a connection, do connectionless exchanges, or both. It’s something that the end user does notice and makes UX a lot better.

Let’s say you want to sign in to a website, so you scan a QR Code.

You create a connection and then you show a proof of a credential.

The following week you want to sign in from a different computer so you create a connection.

So what used to happen in AIP 1.0 is you would create a new connection, resulting in two connections that would show up in your wallet.

Now that you can reuse the connection, and you can sign in using that connection again, you won’t have to manage multiple connections for the same entity.

Of course we know that there exists use cases where you don’t want connection reuse (e.g., cases where you don’t want to be correlatable across connections). We wrote a recent blog post that scratches the surface of this: https://northernblock.io/why-credential-issuance-should-be-holder-driven/.

4B Credential Format Agnostic

This enhancement makes it flexible for implementation teams who would like to use Aries, but have requirements for a specific credential type. A couple differentiations in an above section were described in relation to Indy AnonCreds vs W3C JSON-LD credentials.

Generally in AIP 2.0, a lot of focus has been on removing the dependencies on Indy, making it more standards based to support formats such as the W3C credential. This big enhancement happens through the Issue Credential and Present Proof v2 RFCs.

The v1 protocol was specifically Indy-focused, meaning you could only use it with AnonCreds credentials. The v2 protocol now supports JSON-LD credentials and it could be defined in such a way that any more could be added later on, making it credential format agnostic.

Now, on the same issue credential protocol, you can now support multiple formats — you can send the credential as either an AnonCreds with an AnonCreds-based signature, as a W3C supporting different signatures, as an mDL, or any other credential format. If both agents support the signature and the message format, then they are able to decrypt what they have received.

4C Support for 90+ DID Methods

In AIP 2.0, we’ve also been able to remove the dependency on legacy Indy DIDs and legacy Indy Peer DIDs.

This wasn’t really adopted before, and now these new protocols use DID Exchange built on top of the W3C DID Core specifications, instead of the connection protocol, and always fully uses qualified DIDs that follow the RFC.

DID Exchange allows you to exchange DIDs and DID Documents. The connection protocol from AIP 1.0 wasn’t very well suited for standards compliant like non-Indy or Pairwise DIDs (this was more a limitation of the implementations and that it was an old protocol leaning on an unreleased/older version of the DID Core spec. There was nothing preventing the protocol to be used with other DID Methods).

The DID Exchange protocol supports all DIDs — any method can be used. Of course both agents communicating must support DID Exchange. Peers must support the same DID Methods so that they can resolve the DIDs. For example, if Alice uses did:key and Bob doesn’t support did:key, then it can’t be resolved.

DID Exchange is much more generic — meaning DID exchange opens the door for all DID methods that are registered in the spec registry , so that 90+ DID Methods could be used.

This is an important upgrade to Aries for staying on top of evolving standards.

And here’s another reason why this upgrade is important.

If you are the Holder of a Bank ID Credential, it’s likely that you can present this ID to a Government Tax Agency and they will trust it. So if you have a did:bank ID which can only be used within their ledger and their governance, the tax agency will accept it since they trust the process that the bank would have done to verify claims and issue this ID to you.

We can draw parallels to how the first numbers on a credit card typically represent the issuer identification number. Using the standard format provides interoperability because you’re not tied to one to a federated ID or a centralized slash. If I’m only using did:sov, it can become a federated ledger if it’s the only ledger which can resolve the DID (identifier).

If the end user can select the DID Method, then they’re not tied to a federated model, it’s completely decentralized.

4D Bring Your Own Identifier!

The purpose of supporting DID Exchange is to give the end user the freedom to choose their own identifier for the relationship; enabling them to use less/more secure or different DID Methods as their identifier.

It allows you to choose your own identifier for the relationship to avoid the centralized model (e.g., when you sign up for Facebook they give you an identifier).

In this decentralized model, you inform the other party of your identifier you wish to use, and they just have to resolve it.

This now gives end users much more flexibility; allowing the end user to create multiple personas around DIDs and present them as they wish.

Of course with Connectionless you don’t need to do that bootstrapping because you are not creating a connection; you’re creating a key that you’re only going to use for this single exchange, and then you’re going to throw it away — similar to a temporary email that you may use for a single purpose.

The single/temporary key usage can also be true for connection-based exchanges, which brings in the ability to conduct Key Rotation.

The other party could update their DID Document on the ledger, remove the previous key and update it for a new key. The next time they wish to send you a message, you resolve the DID Document and your agent can know that they changed their keys. Your agent will then begin using this new key to encrypt messages for them, allowing them to rotate keys as needed without informing you.

This brings added security benefits by reducing the chances that your keys get compromised. It’s a concept that’s similar to switching your password every 60 days for online services. If someone gains access to your keys, they can decrypt your messages.

4E Standardized URL Shortening

Another thing which has been standardized in AIP 2.0 is the URL shortening mechanism.

This standardization is part of the Aries RFC 0434: Out-of-Band Protocol 1.1.

URL shortening is used to make payloads simpler and smaller (e.g., in QR Codes). We ran into issues at Northern Block in the past in which our QR codes would get too heavy, making them impossible to scan from a mobile device.

Because URLs weren’t standardized in AIP 1.0, we were forced to create our own mechanism. And so did other vendors, which made it difficult to do interoperability.

Standardizing the way you shorten the URLs whether it’s an invitation, a proof request, or whatever that may be provides interoperability so people are not doing things their own way.

4F Standardized Mediator Coordination

Mediators are a store and forward system that provide mobile wallets with a static endpoint. Mobile devices are not guaranteed to be available online when a cloud agent needs to communicate with them. The mediator acts as an answering machine for the mobile wallet and will forward on the encrypted messages it has received when the mobile device is back online.

There’s now a standard protocol for that which is why you can use ACA-Py as the mediator and AFJ on the client-side. It’s not something the user will notice but it makes the infrastructure easier.

There was previously no standard way of registering my routing keys and endpoint with 3rd party mediators. There’s now a discovery protocol for the edge wallet to find the mediator and register itself using a standard protocol.

The Recipient (edge wallet) must know which endpoint and routing key(s) to share, and the Mediator needs to know to which endpoints messages received with a key need to be routed to.

This allows edge wallets (holders) and issuers/verifiers to connect with any third party mediator that supports this protocol, avoiding vendor lock-in.

Special thanks to Subhasis Ojha, Timo Glastra and Kyle Robinson for reviewing this blog post prior to publishing. 👏 👏 👏

Looking to explore, or test out out interoperability between different open standards and/or technologies? Schedule a call with me!

Originally published at https://northernblock.io on July 14, 2022.