Verifiable credentials: the challenge isn't issuing them, it's making them useful
A verifiable credential only adds value when it resolves a trust decision in a real-world context. It is not enough simply to issue it correctly: it must be understandable to the recipient, useful to the presenter, and verifiable by those who need to rely on that data.
SSI · Verifiable credentials · EUDIW · eIDAS2 · Business Wallet · Interoperability
Digital identity requires products, not just standards
SSI’s challenge is not merely to issue credentials, but to design experiences in which people, organisations and systems can trust, share and verify data in a meaningful way.
In recent years, verifiable credentials, digital wallets and SSI models have gone from being a niche topic to taking centre stage in many discussions about digital identity. The evolution of the European framework, with eIDAS2, the EUDI Wallet and the ARF, has further accelerated that conversation. But for me, the challenge remains the same: turning a powerful technical model into experiences that can be understood, adopted and used in real-world contexts.
Issuing a verifiable credential may be technically complex, but that is not enough. The key question is not simply whether a credential can be issued, stored or verified. The question is: what problem does it solve, what data needs to be trustworthy, who should present it, who should verify it, at what stage of the process, and with what consequences?
That is where the product-centric approach becomes crucial. Because SSI is not merely an identity architecture. It is a paradigm shift in the way people, organisations and systems share data. And that shift is not always intuitive for a member of the public, a business or an organisation that needs to operate with certainty.
The value of a verifiable credential lies not in its mere existence, but in the fact that it forms part of a trust decision.
When the credential exists, but nobody knows how to use it
One of the most common mistakes when working with verifiable credentials is to assume that the problem is solved once the credential has been issued correctly. From a technical perspective, this may seem like a significant milestone: there is an issuer, a holder, a wallet, a credential, a proof and a verifier. But from a product perspective, this is where another equally important phase begins: ensuring that all of this makes sense to those involved in the process.
The SSI paradigm is transforming the way information is shared. In traditional models, citizens often have to submit complete sets of documents, fill in forms, upload files or rely on manual checks. In a model based on verifiable credentials, the approach changes: individuals can manage their own attributes, provide proof, share only specific information and exercise greater control over their data. This offers enormous value, but it also introduces a new level of complexity.
For many people, a digital wallet can easily become a digital filing cabinet. It is a place where credentials, certificates or other details are stored, but without a clear understanding of what they mean, when they should be used, what data they contain, or what it entails to present them. If the user experience is lacking, citizens may end up accepting, sharing or rejecting information without fully understanding the action they are taking.
The opposite can also happen: the use case may be perfectly constructed in a demo, but fail to fit within a real-world process. An issuance and verification test may work in a laboratory setting, but fail when factors such as roles, permissions, exceptions, revocations, expiries, organisational representation, support, onboarding, legacy systems or the need to interoperate with different trust frameworks come into play.
Another common mistake is to use ‘blockchain’ as a synonym for SSI. They are not the same thing. SSI can rely on various trust mechanisms, and a blockchain network may form part of certain models, but it does not in itself define the utility of a verifiable credential. The value lies in the flow of issuance, custody, presentation and verification; in the trust framework that underpins it; and in the ability to integrate it into processes where there is a real need to verify information.
The challenge, therefore, is not merely technical. It concerns adoption, user experience, trust and the product itself.
Making credentials useful requires designing the context
Before designing an SSI-based solution, it is important to understand which trust relationship you are seeking to address. A credential is not an isolated entity: it forms part of a process in which someone issues it, someone holds or presents it, and someone needs to verify it in order to make a decision.
The value is in verification
A verifiable credential is useful when it allows us to trust a piece of information without relying on manual processes, static documents or checks that are difficult to trace. It can be used to demonstrate a status, authorisation, qualification, affiliation, eligibility or representation. However, its true value lies in the fact that such proof reduces friction, increases trust or enables decisions to be made with greater confidence.
A wallet shouldn't just be a drawer
A digital wallet should help citizens understand what credentials they hold, who issued them, what data they contain, and what happens when they choose to present them. The user experience should make consent clear: what is shared, with whom, for what purpose, and for how long. Automating part of the process can be useful, but there must always be an explicit and understandable action when relevant data is shared.
The paradigm needs translating
SSI introduces concepts that are not always obvious outside the technical sphere: issuer, holder, verifier, DID, proof, revocation, trust framework, selective disclosure and verifiable presentation. The challenge for UX and product design lies in translating these concepts into clear actions: receiving, reviewing, storing, presenting, verifying, revoking, renewing or delegating. It is not a question of hiding the complexity, but of making it workable.
People and organisations do not operate in the same way
Designing a Holder Wallet for individuals is not the same as designing a Business Wallet for organisations. In the enterprise sector, additional requirements arise: organisational identity, corporate attributes, representation, permissions, delegation, internal traceability and acting on behalf of an entity. The experience must take into account not only who you are, but also in what capacity you are acting and with what authority.
From standard to use case
I work to translate complex technical processes into experiences that can be understood, validated and put to use in real-world contexts.
When I work on verifiable digital identity solutions, I try to start with the use case, not the credential. The first question isn’t which standard we’re going to use, but what data needs to be trustworthy and what decision depends on verifying it.
From there, it is necessary to map out the actors involved in the process. Who issues the credential, who receives it, who holds it, who presents it and who verifies it. It is also important to understand whether we are dealing with an individual, an organisation, a representative or a system that needs to operate within a framework of trust. This distinction completely changes the experience and the functional logic.
Next comes the technical discussion. You cannot design a good SSI experience without talking to the technical team about feasibility, standards, integrations, formats, protocols, revocation, expiry, trust, security and ecosystem constraints. eIDAS2, the EUDI Wallet and the ARF are important references because they help establish a common framework, but not all wallets or use cases strictly adhere to the EUDI Wallet model. Even so, being aligned with that framework matters: for interoperability, for market expectations, for regulatory developments and for the need to avoid building isolated solutions.
That technical work must then be translated into UX. A member of the public should not need to understand the ARF to know what they are sharing. An organisation should not have to interpret cryptographic concepts to operate a Business Wallet. A verifier should not have to navigate an opaque process to determine whether a credential is valid, current and issued by a trusted entity.
For me, the challenge lies in automating everything that can reduce friction without compromising control. If the system can recognise a credential, interpret its status, validate its issuer or prepare a presentation, that’s perfect. But when personal data is exchanged, authorisation is required or relevant attributes are presented, consent must be explicit, understandable and proportionate.
We also need to design the error handling logic. What happens if a credential is revoked, has expired, is not accepted by the verifier, is missing an attribute, the wallet is not compatible, or the organisation is not authorised to act? Many prototypes work well on the happy path, but real products stand or fall on how they handle exceptions. That is why implementing SSI in a product requires a hybrid approach: understanding the standard, speaking the language of technology, grasping the business process, and designing an experience that does not expose the citizen or the organisation to unnecessary complexity.
Usefulness is the true measure of adoption
Digital identity isn’t adopted as a matter of course; it’s adopted because it’s useful.
Verifiable credentials have enormous potential to transform the way we share and verify information. They can reduce friction, improve privacy, facilitate interoperability, build trust and open up new possibilities for citizens and organisations. But that potential will only be realised if the product solves a problem that someone needs to solve.
A credential is not useful simply because it exists, but because it forms part of a trust-based decision. Because it avoids the need to request a full document when it is sufficient to verify a single attribute. Because it enables an organisation to operate under a verifiable corporate identity. Because it makes it easier for a citizen to prove a status without having to repeat procedures. Because it allows different systems to communicate with one another without relying on manual validations or ad hoc integrations.
SSI’s future depends not only on issuance, but also on the experience of using and verifying the data. It depends on how the data is explained, how consent is designed, how exceptions are handled, how wallets are integrated into existing processes, and how people, organisations and systems are connected within trust frameworks that can be sustained in production.
Technology is already making headway. The challenge now is to make it useful.
Let’s talk about digital identity from a product perspective
We can discuss SSI, verifiable credentials, the EUDI Wallet, interoperability, or digital trust solutions that need to move beyond technical complexity to become clear, useful and adoptable experiences.