Technical interoperability refers to the ability of different systems, devices, applications, or components to connect, communicate, and exchange data seamlessly and effectively. This involves adhering to common standards and protocols to ensure compatibility, enabling diverse systems to work together without requiring significant modifications.

Introduction

As more ecosystems look to enable digital trust architectures for their participants, interoperability continues to be deemed important but often misunderstood. If you’re working towards enabling a digital trust ecosystem for B2C use cases, consider the following questions:

1. What ‘technical interoperability’ strategy should you consider to ensure maximum uptake and value creation for your ecosystem?
2. What technical dependencies exist in outside ecosystems when it comes to credentials and wallets?

In my opinion, it looks likely that Government Wallets and OEM Wallets will dominate the storage of high-value personal identity credentials, both in the short term and potentially in the long term. This means that not only will government credential issuers define their own issuance technical requirements, but they will also place conditions on what wallets their issued credentials can be issued to, what technical stack these wallets support, and even business logic.

This raises an important question for non-government credential issuers, verifiers, and ecosystem governance authorities: Should you invest time and resources in defining new technical interoperability profiles, or what your ecosystem will support? Or is this effort redundant if your goal is to verify high-value personal identity credentials?

Defining Your Ecosystem Strategy

When thinking about how to best benefit your ecosystem with digital trust tools, here are some considerations to think about:

1. Ecosystem Goals: Define your business goals. Define the primary functions and goals of your ecosystem. Define your locus of governance and influence. This helps in understanding the scope and the specific needs of your ecosystem. What ecosystems are you working in, and do they fit together nicely?
2. Bootstrapping: Decide whether or not your ecosystem requires a foundational credential from outside your ecosystem to get started. If so, understand the technical interoperability requirements of that system to know what bridges are needed to first become a consumer of credentials.
3. Wallet: Decide where it makes sense for your ecosystem’s credentials to be issued to. Should there be any conditions on what wallets can receive these credential offers?
4. Consuming External Inputs: Understand what additional inputs your ecosystem needs from external ecosystems and how these can be consumed by your participants. This involves defining the necessary bridges and ensuring compatibility with external profiles to create a frictionless user experience.
5. Providing Outputs Externally: Determine if your ecosystem wants to produce outputs that are usable by other ecosystems. This might involve aligning with common standards and external ecosystem interoperability profiles.

Interoperability Profiles and Wallet Compliance

If your ecosystem requires consuming credentials from external ecosystems and their wallets (Bootstrapping), you will need to demonstrate alignment to their technical profiles.

Examples of technical interoperability profiles that Governments Issuers, Government Wallets and OEM Wallet providers are aligning to include the Aries Interop Profile 1.0 & Aries Interop Profile 2.0, the ISO mDL profile (ISO 18013-5), the OpenID4VC High Assurance Interoperability Profile with SD-JWT VC, the Dutch Decentralized Identity Interop Profile (DIIP), and others. You’ll notice that they all make hard decisions on credential exchange protocols, credential formats, identifier types, signatures schemes, revocation methods and more. Further, some credentials are bound to wallets, others aren’t – this may be valuable for you to know for your own use cases.

If you decide that it’s not important for your ecosystem and its participants to exert any sort of wallet control today, does it make sense to have your ecosystem credentials issued to these government or OEM wallets? A positive aspect of this approach is that your credentials will sit alongside high-value identity credentials and can be used in conjunction with them during verification interactions. A potential downside is the dependency on these third-party wallets, which could pose risks in the future. However, this approach is straightforward, as illustrated in the next section when we discuss practical examples.

If it is important for you and your participants to exert control over wallets, consider whether you are dependent on other ecosystems to bootstrap your use case. If the answer is no, then think about the demand side for your ecosystem’s credentials. Will demand come from external ecosystems outside of your governance, or solely from within your ecosystem?

If the answer is yes, and governments are unlikely to issue credentials to non-government or OEM wallets in the near term, it’s crucial to consider user flows and associated risks. If you’re conducting proofs by accepting credentials from third-party wallets and want to extend a credential offer to participants in your ecosystem-approved wallets, ensure the user experience remains smooth and the risk vectors low. This is particularly important given the difficulty of conducting app-to-app binding for data exchanges on certain mobile phones.

Practical Examples and User Experience

Vancouver’s Digital Credentials Initiative

A practical example of this concept is the City of Vancouver’s initiative to modernize city services using digital credentials. In collaboration with Technical Safety BC (TSBC), the Land Title and Survey Authority of BC (LTSA), and the Ministry of Citizens’ Services, Vancouver is issuing digital credentials to municipal residents to streamline processes such as permitting and licensing.

• Ecosystem Goals: The City of Vancouver, and broader municipal primary function is to modernize city services by reducing manual verification steps in permitting and licensing processes. Their locus of governance is municipal services.
• Bootstrapping: Vancouver’s initiative relies on foundational credentials issued by provincial partners such as the Ministry of Citizens’ Services (Person credential, and BC Registries (Digital Business Card).
• Wallet: The city has decided that it makes sense for their ecosystem to rely on the provincial wallet as a utility for their ecosystem’s credentials. There’s limited value in them owning the wallet experience as there is a direct dependency between the municipality and the province.
• Consuming External Inputs: Beyond consuming provincial credentials, the municipality integrates inputs from provincial partners such as Technical Safety BC (TSBC), the Land Title and Survey Authority of BC (LTSA) to enable more modernization of municipal services.
• Providing Outputs Externally: Vancouver produces digital credentials that can be used by other government ecosystem organizations.

After answering these questions, it’s clear that technical interoperability isn’t a complicated discussion. The fact that the ecosystem is localized makes a difference as well. Therefore, a decision was made to align with the BC Wallet (based on Aries Interop Profile 1.0).

Airlines and Seamless Travel Initiatives

There are many other efforts underway within the airlines to improve customer journeys through the use of digital credentials and other digital trust tools. Being an IATA Strategic Partner allows Northern Block to have purview over active industry efforts to modernize travel experiences.

• Ecosystem Goals: Airlines aim to provide seamless travel experiences through identity management, offer management, payments and fulfillments. 
• Bootstrapping: Airlines may require foundational government personal identity credentials such prior to issuing their own credentials to customers.
• Wallet: Airlines require direct interactions with their customers, therefore any wallet functionalities must be embedded within their existing channels.
• Consuming External Inputs: Outside of government-issued credentials, airlines may need to consume credentials from other travel ecosystem participants such as airports for security clearances, loyalty providers for frequent flier benefits, and retailers for duty-free shopping privileges.
• Providing Outputs Externally: Just like airlines will value the consumption of credentials from third parties, these same third parties will also value airline issued credentials within their business processes.

Airlines must remain in control of their products, money flows and data. This changes the outlook around technical interoperability profiles compared to the first example with the City of Vancouver.

To this end, airlines prefer to integrate wallet capabilities into their existing mobile apps. Their customers are already using these apps, and customer data is crucial for creating personalized travel experiences. Their interoperability story gets more complex considering the ecosystem needs and the global footprint of the industry. Ongoing work is happening to address industry technical interoperability challenges.

Conclusion

In summary, while evaluating technical interoperability profiles for your ecosystem might seem like a daunting task, we hope this blog has provided valuable insights on how to approach this challenge. It may not be as complicated as you think, and you may not need to overanalyze the short-term implications. As the adoption of digital credentials grows, you can adapt to the evolving landscape. The key is to start by demonstrating value to your ecosystem and build from there.

—–

By Mathieu Glaude
Connect with me on LinkedIn

—–