Remote QES - Creating a Signature (EUDI Wallet used for authentication/authorisation)
High Level Description:
In this remote flow, the signature is created using a signing (private) key held within a Qualified Signature Creation Device operated by a Qualified Trust Service Provider.
It shall be highlighted that in this flow the signature is created by an external signing service which interacts with the Relying Party. The sole role of the EUDI Wallet in this flow is to be used for
authentication and authorisation purposes as part of the signature creation.
Journey Steps
Usage
Which step of the experience
How would they use the app?
are you describing?
Enablers
What do they need
The document to be signed is Internet User is enrolled to a default QTSP has issued a signing For user: Being able
under the control of the Connectivity signing service (built-in to the certificate for the user to authenticate via
'Relying Party' EUDI Wallet) PIN/biometrics etc.
Relying Party
Creates [Optional] [Optional] Presents Communicates
document(s)/ Requests user document(s)/ document(s)/data to Receives signed
Authenticates
data to be signed authentication data to be signed be signed to signing document
user
service
User
EUDI Wallet Holder
Opens EUDI Authenticates Reads Views the Identifies to Reads Authorizes/ Provides consent Reads
Wallet in EUDI Wallet error message document/data error message to sign document(s)/data error message Views signature
EUDI Wallet
(Relying Party (e.g. 'Sign with EUDI Wallet' confirmation
The 'Online Identification & interface) button)
Authentication' flow described in
ARF v1.2.0' shall be followed.
The 'Online Identification &
Authentication' flow described in
ARF v1.2.0' shall be followed.
Touchpoint
What service do they interact
with?
EUDI Wallet (Valid State) EUDI Wallet (Valid State) EUDI Wallet (Valid State)
Relying Party Service Relying Party Service Relying Party Service
Valid State Valid State Valid State
Backstage
EUDI Wallet
Authenticates Verifies Verifies signing
User QTSP request
The subsequent steps are under the
responsibility of the QTSP and its
It shall be clarified that the flow indicates interaction with the Relying Party.
separate steps for user authentication This flow presents an indicative end-
and user consent. However, it shall be
possible that the consent for signature to-end scenario.
may already be handled as part of the
previous authorisation step.
QTSP Receives the Requests user Requests Verifies Accesses certificate Computes hash digest of the Passes hash Builds the whole signature (AdES)
Receives Stores Forwards signed
document(s)/data authentication authorisation for Authorisation information document/data to be signed digest to QSCD and finalises creation
eSignature value signed document document
to be signed signature creation of the signed document (applicable for
specific formats, i.e. PDF, XML)
In the scenario where only the
It is possible that only the hashes Corresponding authentication
hashes are received on the QTSP,
are received on the QTSP premises, means shall be realised subject to
this step is deemed as not
for privacy, confidentiality and the scenario, e.g. same-device May optionally fetch additional
elements to include, e.g. certificates, applicable/optional.
performance reasons. (deep-link) and cross-device (QR)
timestamps, signing time etc.
flows
Signature Creation Device
(Remote)
(operated by a QTSP)
Creates eSignature Delivers
value using QSCD eSignature value