Guide

European Digital Identity: Explained Simply

Find out what European digital identity means, how Verifiable Credentials work, and what this means for developers and recruiters.

“European digital identity” describes the shift towards digital proofs that people can manage themselves and present selectively. Anyone searching for this term usually wants to understand what sits behind it, why it is becoming important, and how it differs from PDF documents, profiles or CVs. That is exactly what this text explains, with no prior knowledge of W3C Verifiable Credentials required, specifically for developers and recruiters. For context, our introductory article on digital identity is also helpful.

In practice, this is not just about state-issued identities. Verifiable professional proofs are also relevant, for example from genuinely audited development work: for developers via the free repo audit, for companies via credential verification, with the Proof Engine methodology and the pay-per-verify model.

What is meant by European digital identity

Put simply, European digital identity refers to a form of identity and digital proof that can be used online. In other words, statements about a person should not have to be checked every time only through paper documents, PDFs or manual one-off approvals, but should exist in a form that can be presented and controlled digitally.

It is important to distinguish between two things:

  • Identity answers the question of who someone is.
  • A credential confirms a specific statement about that person, such as a qualification, an exam result or another verifiable attribute.

This is particularly relevant in the labour market. Companies do not just want to read claims; they want to be able to verify them when needed. Developers, in turn, do not want to gather, explain and send the same evidence again in every hiring process.

The basic principle of digital proofs is simple:

  • An issuer creates and signs a credential.
  • The holder stores it themselves.
  • A verifier checks it when it is genuinely necessary.

What also matters is this: verification does not automatically require all raw data to be disclosed. Often, the focus is on a verifiable result, not the full release of all underlying information.

This also shows the limits of traditional documents. A CV, a profile page or a PDF can be useful because people can read it. But that does not automatically make the statements in it technically verifiable.

If you would like to get the basics straight first, our introductory article on digital identity will help.

How W3C Verifiable Credentials work in practice

Blank credential card with seal, connected nodes and verification mark

W3C Verifiable Credentials are an open format for digital proofs that can be checked technically. You can think of them as machine-readable certificates: not just readable by people, but also structured so that their origin and integrity can be verified.

In practice, there are three roles involved:

  • One party issues the credential.
  • The person concerned holds it.
  • Another party verifies it when needed.

For the holder, the wallet is important. In this context, a wallet is not simply a user account on a platform, but a place where a person stores their credentials themselves and presents them selectively. The crucial point is possession: the credential sits in the person’s own wallet, not merely in a service’s internal dashboard.

For a verifier to understand where a credential comes from, its origin must be verifiable. did:web is one method that allows an issuer to be identifiable via the web. This makes it possible to check whether a credential really comes from the party that is supposed to have issued it.

Selective verification is just as important. It means a verifier does not automatically have to see all the underlying information. They can verify the credential, its origin and the issued result without necessarily disclosing all raw data.

For developers, this means that once a credential has been issued, it can be used again in future conversations. For recruiters, it creates a different way of looking at documents: instead of only reading self-declared claims, they receive a technically verifiable proof.

Why digital developer credentials are more than a better CV

For developer roles, it is often not enough to ask what someone says about themselves in a CV, profile or cover letter. What usually matters more is what verifiable work actually exists. That is exactly where the difference begins between self-presentation and a digital credential based on real development work.

A CV condenses claims: technologies used, roles, projects, responsibilities. A repository, by contrast, shows traces of concrete work. It is more likely to reveal how code was created, how changes were introduced and what technical substance sits behind a claim.

A practical example of this is Acquispect. It does not audit a developer’s CV, but their Git repository.

The audit runs in three stages:

  • Stage A: the Ghostwriter Detector analyses the .git history forensically. It looks at commit authorship, detects possible block code-dumping and determines an Impact Score.
  • Stage B: the Safety Check scans for leaked secrets, known vulnerabilities in dependencies, test coverage and the tech stack.
  • Stage C: five AI expert personas with the perspectives of Tech Lead, Security, Performance, Architect and Craftsman arrive at a consensus verdict with a Confidence Score.

What matters is how the result is classified: it is not an absolutely certain yes or no. The outcome is a verdict with a confidence value and an explainable basis. That matters in hiring because it does not simply repeat a claim, but provides a technically derived judgement based on actual work artefacts.

This makes digital developer credentials more than a “better CV”: they shift the focus away from statements about work and towards verifiable traces of the work itself.

How verification works without unnecessarily disclosing raw data

Magnifying glass over sealed credential and partially obscured card with protection symbol

After the audit, the verdict is sealed as a W3C Verifiable Credential and stored in the developer’s wallet. This means the credential does not sit only in an internal system, but with the holder themselves.

This matters for understanding how it works: the developer remains the holder of the credential. They decide when to present it and for what purpose it is used. In a hiring process, that means it is not simply some third-party profile being passed around, but the developer’s own technically verifiable proof.

When a company verifies it, it does not automatically see all raw audit data. What is visible is the verdict — in other words, the issued audit result — not the complete underlying working material.

There is also a full audit log. This makes it possible to understand how the result was reached and what the verdict is based on. For recruiters, this is important because this middle ground is often missing between two extremes:

  • a mere self-declared claim with no technical verifiability
  • full disclosure of all raw data

Verification creates a practical space in between. Developers do not have to expose all of their working material in full. Companies still receive a verifiable proof with reasoning.

This is especially useful in hiring: the statement is stronger than a PDF or profile text, without every check automatically becoming full raw-data disclosure. In this way, selective verification becomes a workable model for both sides.

What this means organisationally for developers and companies

From an organisational point of view, the model is deliberately designed to stay close to the way a digital credential is used.

For developers, the key point is this: the audit is free. That lowers the barrier to building a verifiable proof of your own work in the first place. If you want to hold such a credential, you do not first have to understand a pricing model before the actual value appears.

For companies, the logic is different. They pay per verification, with no subscription model. That fits the basic principle of credentials:

  • the credential sits with the holder,
  • it is carried by them,
  • it is only verified when there is a specific need.

Organisationally, this is different from a permanently running tool that has to operate continuously for everyone in parallel. Verification only becomes relevant when a company actually wants to check a specific credential.

If companies or developers have more extensive requirements, there is also an enterprise offering available on request.

No complicated setup is strictly required to get started. Access is possible via wallet sign-in or as a guest. This is particularly helpful if someone first wants to understand the topic or get to know the process without a major technical hurdle.

Frequently asked questions about European digital identity

Is a European digital identity the same as an online ID card?

Not quite. An online ID card is one example of a digital proof of identity. The term European digital identity is broader. It covers not only the question of who someone is, but also how different credentials can be presented and verified digitally. That can include state-issued identity credentials, but also professional credentials relating to specific claims.

What is the difference between a digital identity and a Verifiable Credential?

Digital identity describes the person in the digital space. A Verifiable Credential, by contrast, is a verifiable proof of a specific statement about that person. Put simply:

  • Identity: Who is this person?
  • Credential: What specific statement about this person has been issued?

A credential can therefore, for example, record a result about audited development work without reducing the person to that one proof.

Why is a Git repository often more meaningful for developers than a CV?

Because a CV mainly summarises what someone says about their work. A Git repository, by contrast, contains traces of actual work. An audit can examine different questions there, such as:

  • who authored commits,
  • whether code was dumped in blocks,
  • what impact changes had,
  • whether secrets were leaked,
  • which known vulnerabilities appear in dependencies,
  • what the state of test coverage and the tech stack is.

This then forms the basis for a consensus verdict from five AI expert personas, with a Confidence Score rather than absolute certainty.

Does a company see all raw audit data during verification?

No. During verification, the company sees the verdict rather than the raw data. In addition, it can read the full audit log to understand how the result was reached. That is the important middle ground: verifiable, but not the same as full disclosure of all working material.

Do developers absolutely need a crypto wallet to use this kind of credential?

Not to get started. Access is possible via wallet sign-in or as a guest. When a verdict is held as a W3C Verifiable Credential in your own wallet, the credential sits with the developer themselves. That is exactly in line with the idea of holding your own credentials and presenting them selectively.

Conclusion: European digital identity becomes concrete when credentials are verifiable

European digital identity is not just a political or technical umbrella term. At its core, it is about trustworthy digital credentials that people hold themselves and can present selectively when needed.

This becomes particularly tangible in hiring. Especially for developer roles, verifiable proofs of real work are often more robust than pure self-descriptions in a CV, profile or PDF.

W3C Verifiable Credentials make this principle understandable and practical:

  • issue
  • hold
  • present selectively
  • verify

In everyday use, digital identity gains traction where it becomes simpler for both sides: for developers when presenting proof, and for companies when verifying it in a transparent way.

Share