About Podcast Episode
In a prior episode of the SSI Orbit Podcast (#53), Daniel Hardman and I discussed the implications of choosing different architectural models for digital identity implementations. We explored the trade-offs involved in these decisions, particularly focusing on client-server architectures. In this particular discussion with Sam Curren and Darrell O’Donnell, we planned to delve deeper into this topic, examining real-world examples and discussing specific technologies and implementations, such as DIDComm and OpenID for Verifiable Credentials (OpenID4VC).
Our conversation starts around a key concept: the distinction between session-based and non-session-based activities in common computing tasks. Session-based activities, such as logging into a website or participating in a video conference, involve a server establishing a session with your device. This session allows the server to remember you as you navigate from page to page or interact with other participants. On the other hand, non-session-based activities, like sending and receiving emails or downloading files, don’t involve a lasting session. Your device sends a request, the server responds, and then the connection ends.
We’ve been witnessing growing adoption of verifiable credentials for both session-based and non-session-based scenarios. While session-based activities typically involve you (a consumer) presenting credentials to a verifier, non-session-based activities could allow you to play different roles in the verifiable credential trust triangle. For instance, you could be a holder of credentials, but you may also wish to be a verifier, to check the integrity of an email or a file, for example. This framing is one input that can be handy when trying to determine what digital credential exchange protocol is best suited for a specific context.
We then delved into both identity and non-identity use cases surrounding verifiable credentials. This exploration helped us distinguish where certain specifications, such as OpenID4VC can truly shine and offer significant benefits. For example, OpenID for verifiable credentials is particularly well-suited for identity-centric use cases. It allows users to log into websites and applications using verifiable credentials, similar to how they would log in with a username and password – this makes it a natural fit for identity-centric use cases and helps eliminate passwords, something we can all agree is needed. But in non-identity-centric use cases, such as issuing a product passport from an enterprise resource planning system or manufacturing management system, something like OpenID4VC would make less sense, and we may look at DIDComm-based protocols as enablers.
We also noted that verifiable credentials are just one tool in our arsenal to achieve digital trust. There are other types of trust tasks that you might want to use alongside verifiable credential interactions to build trust (e.g., secure messaging, asking a trust registry). This is an important distinction. For those aiming to provide digital trust infrastructure as a public good to citizens or consumers, it’s crucial to consider tools that foster digital trust beyond a specific identity system architecture. This also means thinking about protocols that offer the flexibility to go beyond digital credential exchanges. These protocols should provide additional foundational elements of digital trust that empower citizens or consumers in interactions that extend beyond the traditional client-server model prevalent in today’s digital world.
An interesting point that emerged during our discussion was the comparison between DIDComm and OpenID4VC. While it might seem like comparing apples and oranges, just as you can enjoy both fruits in one snack, you can also leverage both OpenID4VC and DIDComm in the same products. OpenID4VC can be a great mechanism to obtain identity credentials, which could then help bootstrap other downstream interactions using a protocol like DIDComm.
DIDComm and OpenID can work together. If a DID with a DIDComm endpoint is passed during an OpenID for VC interaction, it can bootstrap into something more later. Also, if there’s an existing DIDComm interaction, it can tie the context together with the interactions happening in the OpenID4VC protocols.
We concluded our conversation on a note of agreement that the most important thing is meeting the customers where they’re at. This means using technologies and protocols that the customer is already familiar with and comfortable using. Since many customers are already familiar with the process of logging into websites and applications using OpenID, it may make sense to use OpenID for verifiable credentials as well. This approach can help to reduce friction and increase adoption of verifiable credentials.
Here’s a quick soundbite from the conversation:
Looking ahead, I’m certain that there will be more thinking, collaboration, and convergence between different credential exchange protocols like DIDComm and OpenID4VC, and I eagerly look forward to it. I hope you find this conversation as interesting and engaging as I did.
The full list of topics discussed between Sam, Darrell and I in this podcast conversation include:
- Session-Based vs Non-Session-Based Activities – discussed the differences between session-based activities (like logging into a website or video conferencing) and non-session-based activities (like sending an email or downloading a file).
- Verifiable Credentials in Different Activities – discussed the adoption of verifiable credentials across session-based and non-session-based activities, and the potential restrictions and opportunities in both models.
- Alternatives to Session-Based and Non-Session-Based Activities – explored potential alternatives to the common ways of looking at session-based and non-session-based activities.
- Understanding DIDComm – delved deeper into what DIDComm is, its properties, and how it would fit within our everyday lives and on the web.
- Momentum Behind Client-Server Architecture-Based Protocols – discussed the momentum behind client-server architecture-based protocols for exchanging verifiable credentials, specifically OpenID for verifiable credentials.
- Benefits of OpenID for Verifiable Credentials – discussed the benefits of using OpenID for verifiable credentials, including injecting integrity into wallets and signed payloads.
- Importance of Other Aspects Beyond Verifiable Credentials – explored why a digital identity program should care about aspects beyond verifiable credentials.
- Impact of Government Recommendations on Digital Identity – discussed how government recommendations can have a significant impact on the direction of digital identity initiatives.
- Coexistence of Different Protocols – explored the idea that different protocols, like DIDComm and OpenID, could coexist and complement each other.
- Shifting Focus from Wallets and VCs to User Journeys – discussed the need to shift focus from wallets and verifiable credentials to user journeys and how having more integrity in the journey can help reduce fraud or cost.
- Business Perspective on Choosing Protocols – discussed the need to look at choosing protocols from a business perspective, considering what would be most beneficial for the specific use case.
Sam Curren is the Senior Systems Architect and Deputy Chief Technology Officer for Indicio. Sam has been involved in the Identity Community for over 12 years, working and researching on personal data, distributed systems, supply chain digital birth certificates, and Decentralized Identifiers (DIDs).
As a pioneer in decentralized identifier communication protocol (DIDComm) and open source technology verifiable credentials, Sam played an instrumental role in the development of Hyperledger Aries and Hyperledger Indy. Sam is a project maintainer and contributor to multiple open source repositories and open standards for decentralized identity, and holds an extensive range of leadership roles for various community groups, including the Decentralized Identity Foundation and Hyperledger Foundation.
Where to find Sam
➡️ LinkedIn: https://www.linkedin.com/in/samcurren/
➡️ Twitter: https://twitter.com/TelegramSam
Darrell O’Donnell is a technology company founder, executive, investor, and advisor. At Continuum Loop, Darrell and team help large and small companies to operationally deploy emerging technologies. As a Founding Steering Member of the Trust Over IP Foundation, Continuum Loop is committed to ensuring that we can all add more digital trust to our interactions. Darrell is focused on solving problems of mission-critical systems and interoperability, especially where there are many players and no clear central authority. He advises numerous startups, senior government leaders, and investors.
Where to find Darrell
➡️ LinkedIn: https://www.linkedin.com/in/darrellodonnell/
➡️ Twitter: https://twitter.com/darrello