Co-authored by Alex Tweeddale (Governance & Compliance Lead), Ross Power (Product Manager), and Ankur Banerjee (CTO/co-founder)
In the early months of 2022, the team at cheqd conducted two surveys diving into self-sovereign identity (SSI) and digital identity in Web 3.0. We analysed responses from a general audience as well as from an expert audience to tease out key trends.
This second article, following on from our first article, focuses on trends and key takeaways from the deep-dive survey that was shown to an expert technical audience of self-sovereign identity (SSI) vendors.
Specifically, this article will focus on trends and challenges that can be drawn from looking at each Layer of the SSI technical stack.
Key technical trends identified in digital identity / Web 3.0 in cheqd’s deep dive survey
Figure 1: the Trust over IP Technology Stack
We will use the ToIP classifications to split up the survey responses into how they correspond with each specific technical Layer. Through this, we will reach a set of conclusions and five trends around the entire technical stack, top to bottom.
Introduction
- Trend 1: (Layer 1) Hyperledger Indy is still the most supported Layer 1, but there are signs it may be losing its dominance
- Trend 2: (Layers 1, 2, 3) Aries-based SDKs are dominant, correlating with Indy at Layer 1
- Trend 3: (Layer 2) OIDC SIOP may be starting to catch up with DIDComm in terms of a peer-to-peer connection layer
- Trend 4: (Layer 3) The lack of harmonisation on Credential type/exchange standards is more stark than ever
- Trend 5: (Layer 4) Ecosystem adoption could be driven by stronger commercial models and payment rails
Interoperability and harmonisation is lacking at each layer of the stack, which is a barrier for adoption
In addressing this challenge, respondents indicated that cheqd could help boost adoption:
Since large-scale interoperability is not yet a selling point, SSI may benefit from new commercial models and payment rails to kickstart and incentivise adoption
To show the workings of how these conclusions were drawn, we will go through each trend individually and explain how the trend has developed and how challenges have emerged from the trends, using evidence in the form of data collected from our survey.
Finally, it is important to make clear that when we set out to gain a better understanding of what our community and our SSI partners wanted, we did not enter with a specific agenda or set of assumptions we were hoping to prove. That said, we are thrilled to see the direction we’re moving in at cheqd is generally supported by the data we collected.
Buckle up!
Trend 1: Hyperledger Indy is still the most supported Layer 1, but there are signs it may be losing its dominance
#Layer1
DID methods are the set of rules and instructions used for interacting with a specific Layer 1 Public Utility in order to write, update and resolve DIDs on that Utility. There are over 100 distinct DID methods already, with increasing diversity in the approach the did methods take.
We asked our respondents what DID methods they currently support or plan on supporting in 2022. The most prominent supported DID Methods amongst our respondents were Indy-based DID Methods, as well as specifically the Sovrin DID Method. This is most likely because Indy and Sovrin have been largely the only options for functional, identity-specific use cases.
did:ethr has also been around for a long time, however, due to being based on Ethereum, identity use cases have never been the main priority of Layer 1. For this reason, Ethereum and did:ethr have not gained the same amount of attention or traction within the identity sphere as Ethereum has across the rest of Web 3.0.
Interestingly, looking at the responses on a more granular level, the majority of the companies that support any of the alternatives to did:indy and did:sov also support one of did:indy or did:sov.
Only 3 out of the 37 respondents supported did:web or did:key without also supporting did:sov or an Indy-based method, for example.
This does suggest that for SSI vendors, did:sov and did:indy are the first DID Methods to be looked at and supported, before expanding to other alternatives afterwards. did:web and did:key both make sense in this regard, as they are off-ledger options for anchoring DIDs, which is arguably much more practical for testing environments or Proof of Concepts since nothing written into the DID is immutable.
Of the ledger-based alternatives, there is not currently a clear frontrunner, although did:ion is probably the alternative gaining the most momentum, as it is the main supported Utility for the VC-JWT Interop Profile between the likes of Mattr, Microsoft, Ping and Workday — working alongside the Decentralised Identity Foundation (DIF).
ION uses a protocol called Sidetree to store DIDs in temporary storage, as well as within IPFS / MongoDB, in order to rollup and batch DID operations to the main blockchain (Bitcoin in ION’s case), which makes it more operationally cost-efficient.
One DID Method that we did not include but was brought up within the comments and ‘other’ sections is did:ebsi. This is a ledger that we do expect to gain much more traction over the coming months and years, especially as the European Blockchain Services Infrastructure (EBSI) has begun releasing conformance criteria for European Digital Identity Wallets, mandating support for did:ebsi. We would expect to see an increase in uptake of specifically did:ebsi off the back of this body of work.
In terms of analysis here, it is important to stress that diversity at Layer 1 is by no means a bad thing. The emergence of new methods to compete with did:indy and did:sov should be encouraged, especially if such approaches comply directly with the W3C DID Core specification. The DID Core Spec was not written to be a rigid standard; rather, it promotes innovation, extensibility and flexibility — meaning that it is possible to innovate to a certain degree at the DID layer without compromising interoperability. We hope that in the next year, did:cheqd will become another name on the above list.
In terms of making interoperability more seamless here, we would push for the community to strengthen the DID Method Test Suite in order to better highlight the degree to which DID Methods interoperate and what functionality exists within each individual DID Method.
Trend 2: Aries-based SDKs are dominant, correlating with Indy at Layer 1
#Layer1, #Layer2, #Layer3
Software Development Kits (SDKs) are less talked about than they should be. In fact, SDKs are pivotal to interoperability because they enable third parties to carry out functions such as establishing connections, issuing Verifiable Credentials and verifying the Decentralised Identifiers within the Credential, against a Layer 1 Public Utility and DID Method(s).
Hyperledger Aries was initially designed to be an agnostic set of Protocols (Request For Comments ‘RFCs’) for carrying out SSI-based operations. These Protocols, however, and a lot of the Hyperledger Aries SDKs, have since been designed to work specifically with Hyperledger Indy — which is why, largely, there has been a dominance of Indy-based Layer 1s and Indy-based DID methods.
This was shown within the survey results, with the largest proportion, 35.1%, of respondents using Aries Cloud Agent Python (ACA-Py); and secondly, 27.0% of the respondents using Evernym’s VDR Tools SDK (tied to Hyperledger Indy).
As a trend here, it is likely that Aries SDKs will remain dominant, especially as there is ongoing work to decouple the dependence between Aries and with Indy. We see decoupling Aries from Indy as a vital part of building a more interoperable SSI technical stack.
At cheqd, we are also planning to support this work by helping expand one of the main Aries Frameworks to support cheqd, and therefore, multiple Layer 1s other than Indy-based networks. Once Aries or any SDK is able to communicate with a variety of Layer 1s and route requests to specific DID Methods accordingly, this will be a key milestone for SSI.
On this slightly different topic, we were surprised to see Aries Framework JavaScript and Aries Framework Go with such a low adoption vector (both 10.8%), especially as most companies indicated that they use JavaScript/TypeScript or related frameworks as their primary language for development, as seen in the graphic below:
The skew towards ACA-Py may simply be down to the fact that much more work is being done on the project. Looking at the Contributions over the last 2 years, ACA-Py is far ahead of the likes of Aries Framework Javascript just in terms of general contributions and commits, with roughly four times more activity over a sustained period.
Figure 2: ACA-Py Contributions
Figure 3: Aries Framework JavaScript contributions
What perhaps this result does show, is that there is no standout SDK for SSI yet, even within Aries, different implementations of Aries may be useful for different purposes, with pros and cons within each implementation.
This may also explain why Indy is the most utilised Layer 1, as Aries is currently the main SDK to use alongside it. Until this tie is severed, we do not see this changing in most SSI implementations.
Trend 3: OIDC SIOP may be starting to rival DIDComm in terms of a peer-to-peer connection layer
#Layer2
Layer 2 in the SSI stack is all about creating secure connection channels between different parties in identity transactions. If you think of Verifiable Credentials for the contents of a letter, Layer 2 provides the Envelope and the Postal Service.
Figure 4: Peer-to-peer communication envelope
Through the use of a peer-to-peer communication channel, Verifiable Credentials or messages can be sent securely between parties, in a way which is completely off-chain. This is often a concept that newcomers to SSI do not fully understand since most uses of blockchain have peer-to-peer transactions take place on-ledger.
The survey results showed that the Layer 2 protocol is relatively split between two frontrunners DIDComm (v1 and v2) as well as Self-Issued OpenID Provider: OpenID Connect (SIOP OIDC).
73.7% of respondents ranked DIDComm v1 and v2 as being either the most or second most important protocol here. This demonstrates that it is a clear leader in the community for how to create trusted communication channels between wallets and agents. This is also supported by interoperability profiles such as WACI-DIDComm.
However, 68.4% of respondents also clearly acknowledged the importance of SIOP OIDC. In fact, there may even be a more current trend toward SIOP OIDC, with both the European Commission as well as the VC-JWT Interop Profile recently selecting it as a communication channel over DIDComm v2. This may be because it focuses on bridging Web 2.0 and more federated identity models into the self-sovereign paradigm, through the thoroughly tested and well-trodden path of OpenID Connect.
Through this bridge, there may be a larger adoption vector as there are already millions of OpenID Connect Relying Parties which may be able to access and issue Verifiable Credentials through this model.
Whether DIDComm or SIOP OIDC does come out on top in practice is yet to be seen, however, it is vitally important that both work towards functional compatibility between the two approaches.
This is also understood within the WACI-DIDComm interop profile which states that it is waiting until version 2 of SIOP OIDC before considering adoption into its own interop profile.
Hopefully, after the latter publishes its v2 spec, it will spark a convergence around a particular interop profile, or a combination of the two. A Killer Whale Jello Salad. If you know, you know.
Trend 4: The lack of harmonisation on Credential type/exchange standards is more stark than ever
#Layer3, #Layer4
Credential Exchange
Being issued a set of claims and Verifiable Credentials to your identity wallet and then presenting them to a third party is at the core of SSI. This is what Layer 3 in the technology seeks to achieve.
For SSI to become an interoperable ecosystem, the mechanism that transports one Verifiable Credential to a Holder’s wallet must be able to communicate with a completely different piece of software receiving a Verifiable Credential or Presentation on the end of the Verifier. Yet, currently, the different approaches do not enable Credential interoperability.
In this category, Aries Present Proof (88.3% voted as 1, 2 or 3 in terms of importance), WACI Presentation Exchange (58.8% voted as 1, 2 or 3 in terms of importance) and Verifiable Presentation Request (76.5% voted as 1, 2 or 3 in terms of importance) all score very highly — with Credential Manifest and OIDC Credential Provider being recognised as very important by a smaller segment of the respondents.
The WACI-DIDComm Interop Profile encompasses both the Wallet and Credential Interop work on Verifiable Presentation exchange, alongside Aries Present Proof, as supported means of exchange, on top of DIDComm v2. WACI Pex and Aries Present Proof here work together, tackling slightly different components of Credential and Presentation Exchange and Proofs.
Looking at the data on a more individual basis, it is not surprising that the people who voted SIOP OIDC highly were also the same people who voted OIDC Credential Provider highly. Similarly, the people who voted WACI PEx and Aries Present Proof highly also favoured DIDComm v1 and 2 as the Layer 2 communication envelope.
This separation between, on the one hand, the VC-JWT Interop profile and EBSI which both focus on SIOP OIDC and OIDC Credential provider; and on the other hand, the WACI-DIDComm interop profile which focuses on Aires Present Proof and WACI PEx demonstrates the lack of harmonisation in the industry right now.
Credential type
It will come as no surprise to anyone who has been in the SSI industry for a while that there is a stark lack of agreement on which semantic and syntactic format Verifiable Credentials should take.
Within the survey results, the respondents indicated a very even:
- 45.9% AnonCreds;
- 40.5% JSON based VC JWT;
- 32.5% JSON-LD; and
- 40.5% JSON-lD with BBS+ signatures.
There has been plenty written on the differences between these Credential types, we will point to Kaliya Young’s work on Credential flavours here.
However, the key point is that this lack of alignment and agreement in technical standards has acted as a barrier to SSI adoption. This response shows directly the split that there is in the community between Credentials types and different standards on this topic.
Here the respondents clearly indicated that both the lack of maturity in technical standards and the limited interoperability afforded by the standards were two of the main barriers to real-world adoption by clients.
Without technical and semantic interoperability, Self-Sovereign Identity can only exist within closed silos or consortiums, rather than as a global model for trusted data.
This is not something that any of us want in the community, and as such, it is important that we work together towards:
- Robust technical Standards published by Standards bodies (such as W3C, IETF, ISO) which anyone is able to adopt, in an interoperable fashion
- Interoperability profiles, outwards communication and industry dialogue about technology stacks
- Middleware to connect any natively incompatible implementations with one another
Through a combination of these three points, we would hope that SSI could converge to a point of interoperability, rather than creating a larger divide.
Layer 5: Ecosystem adoption could be driven by stronger commercial models and payment rails
Quite interestingly, the respondents made it clear that the main driver for the adoption of SSI is currently to reduce the compliance burden on companies and to make it easier to comply with new regulations. It weighed the highest with 65% selecting this option as a driver for interest in SSI amongst their customers.
This is not entirely surprising as there are many regulations are coming into force, or having recently been proposed, which impose strict identity or KYC requirements on businesses, such as the US Drug Supply Chain Compliance Act within product supply chains, eIDAS 2.0 for data sharing in the European Union or the Financial Action Task Forces’ Recommendation 16 Travel Rule within Web 3.0.
Through these regulatory changes, companies are being shoehorned into looking beyond the purview of existing technologies to comply with the expanded scope of these new regulations. Or, in other words, changes in regulation are making SSI adoption more viable, as was selected by 55% of the respondents.
35% of respondents also recognised the potential for revenue streams as a driver for SSI. Similarly, 35% recognise that KYC/KYB is currently too expensive with existing providers. Finally, 35% of respondents see a reduction in costs through greater operational efficiency as being a driver.
These latter three responses indicate that the current customers that SSI vendors are working with are currently more focussed on the compliance benefits of SSI than the potential cost benefits and revenue opportunities.
This response is most interesting when compared to another question we asked on where cheqd’s product roadmap could help our respondents’ customers. Here, 70% highlighted that Payment Rails for Identity would help drive adoption with their customers.
This indicates that functional payment models may increase interest from customers already interested in the compliance benefits. However, it is likely that this is not an existing driver, since the technology to realise the operational and cost benefits, alongside new revenue opportunities is not yet readily available.
This data reinforces the product direction and roadmap we have laid out at cheqd, which is pleasing to see. We also expand and dive deeper into this specific rationale in our third trend of the General Product Survey response — Trend 3: Privacy-preserving commercial models for digital identity exchange could radically accelerate the adoption of self-sovereign identity.
Key Takeaways
One of our founding principles at cheqd is to build out the network with and for our community. We are confident in the knowledge we have within the cheqd team, but fundamentally, we believe in the wisdom and experiences of those that will be the ultimate beneficiaries of the network; a utility after all is for everyone, and should therefore be designed by everyone.
So, bringing it all together, a reminder of the 5 Trends identified:
- Trend 1: (Layer 1) Hyperledger Indy is still the most supported Layer 1, but there are signs it may be losing its dominance
- Trend 2: (Layers 1, 2, 3) Aries-based SDKs are dominant, correlating with Indy at Layer 1
- Trend 3: (Layer 2) OIDC SIOP may be starting to catch up with DIDComm in terms of a peer-to-peer connection layer
- Trend 4: (Layer 3) The lack of harmonisation on Credential type/exchange standards is more stark than ever
- Trend 5: (Layer 4) Ecosystem adoption could be driven by stronger commercial models and payment rails
Looking at the trends holistically, they each spiral into one main challenge: interoperability and equivalency at each technical layer is still one of the largest barriers to mainstream SSI adoption — this is an overarching trend in itself.
Resolving this challenge is not as easy as converging around one formal Standard at each layer, or just using “W3C” Standards. This is because companies, governments and consortia each have individual requirements for SSI that cannot be currently addressed by one interoperability profile.
This has led to a degree of short-termism and long-termism within the community.
Vendors with clients knocking on their door and asking for a product tomorrow are swaying towards short-term solutions (such as AnonCreds which contains privacy-preserving revocation and the capability for predicate proofs); whereas, enthusiasts and SSI visionaries are looking at a longer-term vision of harmonisation and wide-barrelled interoperability (such as JSON-LD with BBS+ signatures or even AnonCreds V2 with BBS+).
Both approaches, short-term and long-term, need to be recognised as valid by the broad SSI community; which does not make the resolution a quick fix.
Whether one mature enough Standard does emerge over the next few years, creating a convergence effect; or, we move towards a middleware marketplace between different implementations and standards, we think it is essential to maintain an open conversation about technical stacks and interoperability profiles. It is only by having this conversation that interoperability may be inched closer.
What do these trends mean for cheqd going forwards?
Understanding the SSI stack through 5 trends and challenges was originally published in cheqd on Medium, where people are continuing the conversation by highlighting and responding to this story.
