Identification vs
Authentication
Two fundamental concepts in banking, digital identity and eIDAS.
Understanding the difference is essential for designing legally strong
on-site, in-app and remote signing processes.
Identification
Authentication
Required for QES
All modules covered
Two different questions
Confusion between these two concepts is one of the most common sources of legal and process risk in digital signing.
“Who are you?”
Establishes and verifies the real-world identity of a person.
Usually performed once (or periodically) at onboarding or when a qualified certificate is issued.
- Creates a trusted identity record
- High-assurance KYC / AML process
- Passport, ID card, video ID, biometrics
- Regulatory basis: AML + eIDAS
- Result: Confirmed identity
“Are you that person right now?”
Proves that the person currently interacting is the same one who was previously identified.
Performed repeatedly — every login, every transaction, every signature.
- Protects access and actions
- Confirms the current session
- OTP, SCA, biometrics, PIN, device binding
- Regulatory basis: PSD2 SCA + eIDAS
- Result: Confirmed session
Detailed comparison
Core question
Identification: Who are you?
Authentication: Are you that person now?
Frequency
Identification: Once (or rare / periodic refresh)
Authentication: Many times — every relevant action
Main goal
Identification: Create a trusted identity record
Authentication: Protect access and confirm the current action
Typical methods
Identification: Official ID, video identification, biometrics
Authentication: OTP, SCA, biometrics, PIN, device binding
Regulatory drivers
Identification: AML / KYC + eIDAS identity proofing
Authentication: PSD2 Strong Customer Authentication + eIDAS
rSign examples
Identification: Branch face-to-face for OQES
Authentication: App SCA session for IQES
Why both are required for a full QES
To issue a Qualified Digital Certificate (and therefore create a full Qualified Electronic Signature),
the QTSP must be confident of two things.
1. High-assurance identification
The certificate is issued to the correct real person.
Identity must be verified with a high level of assurance (face-to-face or equivalent methods accepted under eIDAS).
2. Strong authentication at the moment of use
Only the rightful owner can use the certificate or approve the signature.
This is ensured by SCA, OTP, biometrics or other strong factors at signing time.
One without the other is not enough
Strong identification without current authentication leaves the process open to session takeover.
Strong authentication without proper prior identification means the certificate may be linked to the wrong person.
Bank as Registration Authority
In IQES the bank re-uses the high-assurance KYC performed at onboarding and confirms the current SCA session.
This combination satisfies the QTSP’s identity-proofing requirements for a one-time QDC.
How identification & authentication work in each module
OQES
Identification: Face-to-face by bank clerk at the branch (official ID document).
Authentication: Performed during the same visit (OTP, biometric or explicit consent).
- One-time QDC issued by QTSP
- Full Qualified Electronic Signature
- No signature-pad hardware required
IQES
Identification: Already performed at account opening (high-assurance KYC) — re-used.
Authentication: Current Strong Customer Authentication (SCA) session inside the banking app.
- Bank acts as Registration Authority
- One-time QDC for the session
- Customer never leaves the app
RQES
Identification: Handled by the trusted cloud identity provider or national eID scheme.
Authentication: Handled by the same identity provider at the moment of signing.
- Existing or session-based QDC
- Fully remote — no branch visit
- Multiple ID providers supported
PAES
Identification: Face-to-face by bank clerk.
Authentication: Biometric characteristics of the handwritten signature captured on the pad + process controls.
- Advanced Electronic Signature
- Strong evidentiary value
- Qualified timestamp included
Authentication is still required face-to-face
Even when identification is performed in person by a bank clerk,
authentication is still needed for the actual signature or transaction.
1. Identification
Clerk checks the official ID document (ID card / passport) → answers “Who are you?”
2. Authentication
Proof that the same person is now approving / signing the document → answers “Are you that person right now?”
Authentication methods in face-to-face scenarios
OTP / SMS
Code sent to the customer’s registered mobile number. Most common technical factor used with OQES.
Signature pad (PAES)
Biometric characteristics of the handwritten signature captured on a dedicated pad.
Biometric on tablet
Fingerprint or face recognition on the branch device.
PIN / password
Customer enters a secret known only to them on the terminal.
Clerk confirmation
Clerk confirms in the system that the identified person is the one acting. Useful but weaker alone.
Recommendation
For full QES, combine clerk confirmation with at least one technical factor (most commonly OTP).
Proving “Clerk Confirmation”
When no PIN, OTP or biometric is used, the evidence of authentication relies on the bank’s internal process and audit logs.
What can be proven
Clerk’s authenticated system session, timestamp and branch location,
customer ID linked to the action, exact action confirmed in the log,
clerk user ID, and internal process documentation.
Limitations
Relies heavily on human correctness. Weaker technical non-repudiation.
Can be challenged in disputes. Usually not sufficient alone for QTSPs issuing a QES.
Best practice for OQES
Clerk confirmation alone is acceptable only for lower-risk processes.
For full QES it is strongly recommended to combine it with at least one technical factor (OTP is the most practical).
rSign support
The platform captures the necessary process metadata so that identification,
authentication method and clerk actions form a coherent evidence package.
Key takeaway
Identification answers “Who are you?”
It creates the trusted identity record that a Qualified Certificate (and therefore a QES) can be linked to.
Authentication answers “Are you that person right now?”
It ensures that only the rightful owner can approve the signature at the moment it is created.
Both are required — even face-to-face
Clerk confirmation can be evidenced via audit logs, but for QES it should be combined with a technical factor.
rSign covers every combination
OQES, IQES, RQES and PAES are designed so that identification and authentication are correctly paired for the chosen legal strength.
Correct identification + strong authentication = full QES
rSign implements both sides of the equation for on-site, in-app and remote signing —
so banks can offer the highest legal strength with confidence.