EUDI Wallet Signatures: Identity Is Not Document Signing

An EUDI Wallet can identify a person and can support qualified electronic signatures. Those two capabilities are related, but they are not the same event.

That distinction matters whenever a product moves from “who is this?” to “did this person sign these exact terms?” A wallet presentation can establish identity without creating a signature over a document. A tap on an approval screen is not automatically a qualified electronic signature either.

Four different outcomes

Outcome	What it establishes
Identity presentation	Selected identity attributes came from a trusted credential and were presented for this request.
Electronic approval	The user performed an electronic action indicating acceptance; legal effect depends on evidence and context.
Advanced electronic signature (AdES)	A signature meeting the identification, control and tamper-detection requirements in Article 26 of eIDAS.
Qualified electronic signature (QES)	An advanced signature created by a qualified creation device and based on a qualified certificate; it has the equivalent legal effect of a handwritten signature across the EU.

The fact that the same wallet appears in all four journeys does not collapse them into one proof type.

What the EUDI regulation requires

Article 5a of Regulation (EU) 2024/1183 says wallets must enable users to sign by means of qualified electronic signatures or seal by means of qualified electronic seals. It also says natural persons must be offered the ability to create qualified electronic signatures by default and free of charge, while allowing Member States to limit free use to non-professional purposes.

In practice, a QES journey can involve a qualified trust service provider, a qualified certificate and a qualified signature creation device or remote equivalent. The wallet can orchestrate access to that capability without making the wallet provider itself the qualified trust service provider.

The Commission's service-provider guide lists qualified signatures and seals as a wallet feature. Large-scale pilots have also tested signature use cases, but pilot success should not be confused with universal national production availability.

Identity presentation answers “who”

A PID presentation can establish attributes such as a legal name and date of birth. The presentation is cryptographically bound to a request so a verifier can reject replay or substitution.

That can be strong evidence of who participated in a session. It does not necessarily bind the participant to a specific contract, document version or consent text.

To prove a document action, the evidence needs a stable representation of the content and an explicit action associated with it.

Document signing answers “what” and “when”

A sound digital signing flow preserves the relationship among:

• the signer's verified identity or pseudonym;
• the exact document bytes or canonical content;
• the signer's explicit action;
• the transaction challenge and device proof;
• the occurrence time; and
• the evidence needed for later validation.

Hashing is useful because a cryptographic digest changes when the document bytes change. But a hash alone cannot show what the signer saw, reproduce a lost document or prove that the user intended to sign it.

The signing service should compute the authoritative hash over the exact bytes it presents. Accepting an arbitrary customer-supplied hash creates a substitution gap: the service cannot show that the hash belongs to the document displayed to the signer.

Where a wallet presentation can fit

A wallet presentation can be one component of an electronic signature evidence package. For example:

1. The service receives and fixes the document bytes.
2. It computes a digest and displays the document to the user.
3. It requests a fresh wallet presentation bound to the transaction and digest context.
4. The user performs an explicit signing action.
5. The service stores the document, signature evidence, wallet evidence and audit links.

That can create strong attribution and integrity evidence. Whether it is a simple, advanced or qualified electronic signature depends on the complete implementation and legal requirements—not on marketing language.

If a QES is required, use the qualified path and validate it as such. Do not relabel an identity-bound approval as qualified.

Qualified signatures need qualified validation

The eIDAS framework defines requirements for validating qualified signatures and advanced signatures based on qualified certificates. A verifier must evaluate certificate status, trust-service-provider status, integrity and the applicable validation policy.

Long-term evidence can also depend on trusted timestamps, revocation information and archival processes. A valid signature at creation time can become difficult to prove years later if the evidence required to reconstruct that validity is missing.

This is why “we use public-key cryptography” is not a signature classification. The cryptography is necessary; the certificate, device, provider status, process and validation result determine the legal category.

What the signer should see

A defensible user journey should make clear:

• who is requesting the signature;
• which document or terms are covered;
• whether multiple files form one ordered package;
• whether the operation is an approval, AdES or QES;
• what data the wallet will share;
• how the signer can retain a copy; and
• what happens after completion.

For document files, “what you see is what you sign” is not cosmetic UX. It closes the gap between displayed content and retained evidence.

What Alentra calls signing

Alentra separates identity and signing primitives deliberately.

• identify requests credential attributes.
• age_verify produces a threshold result.
• sign binds wallet evidence to hashes Alentra computes over the exact uploaded document bytes it shows and retains.
• light_sign binds an explicit action to short inline terms.

These flows are designed to preserve evidence without claiming that every result is a QES. A future qualified route must be backed by the appropriate EUDI wallet capability, qualified provider, certificate, creation device and validation process before it is labeled qualified.

For the complete ecosystem context, read the EUDI Wallet guide. For the protocol path behind identity presentations, see How the EUDI Wallet works.

Electronic-signature classification is fact- and jurisdiction-specific. This article is technical background, not legal advice about a particular transaction.