Ve i iable Con ac ing
A use case o onboa ding and con ac o e ing in
inancial se ices wi h eIDAS and Ve i iable C eden ials
S´e gio Manuel N´ob ega Gon¸cal es2[0000−0002−7818−4757], Alessand o
Tomasi1[0000−0002−3518−9400] And ea Bisegna1,3[0000−0002−8055−5262], Giulio
Pellizza i2[0000−0001−6455−780X], and Sil io Ranise1,2[0000−0001−7269−9285]
1Secu i y & T us , FBK, T en o (I aly) {a.bisegna, anise,al omasi}@ bk.eu
2Uni e si y o T en o, T en o (I aly)
{giulio.pellizza i,sm.nob egagoncal es}@s uden i.uni n.i
3DIBRIS, Uni e si y o Genoa, Genoa (I aly)
Abs ac . We in es iga e he combined use o eIDAS-based elec onic
iden i y and Ve i iable C eden ials o emo e onboa ding and con ac -
ing, and p o ide a p oo -o -concep implemen a ion based on SAML au-
hen ica ion. The main non- i ial alue de i ed om his p oposal is a
highe deg ee o assu ance in he con ac o e ing phase o he Con-
ac ing Se ice P o ide .
Keywo ds: Ve i iable C eden ials ·Digi al Iden i y P oo ing ·Digi al
Con ac ing
1 In oduc ion
F om he poin o iew o a Se ice P o ide (SP), o e ing a con ac o a
emo e applican can be a isky p oposi ion. Reliably es ablishing i s ly ha
someone no physically p esen eally is who hey claim o be, and secondly ha
he de ails hey ha e p o ided o en e in o a legally binding ag eemen wi h
he SP a e co ec , is no i ial ask. The e a e long es ablished p ocedu es o
add ess hese p oblems when he pe son is physically p esen , usually in ol ing
a o m o pho og aphic ID and any numbe o p oo s o o he de ails, such as
u ili y bills o p o e cu en add ess and/o bank s a emen s o p o e accoun
numbe s. In he case o emo e applican s, howe e , digi al solu ions o iden i y
p oo ing and emo e con ac ing a e s ill a wo k in p og ess. In his pape , ou
con ibu ion is a p oo -o -concep o es he combina ion o wo ecen and
eme ging echnologies: elec onic iden i y ca ds and e i iable c eden ials.
We conside a Con ac ing Se ice P o ide (CSP) wishing o en e a legally
binding con ac wi h an applican be o e p o iding hei se ices. Impo an ex-
amples include u ili ies and elecoms. In es ablishing a legally binding con ac ,
CSPs commonly incu cos s due o aud and e oneously en e ed in o ma ion.
Conc e ely, a u ili y billing he w ong bank accoun , o ha ing o en e a le-
gal dispu e o e in o ma ion en e ed by an applican du ing a pas con ac ing
phase, will incu legal cos s and delays. In his wo k we ocus on he ini ial o -
e ing phase, in which a CSP wishes o ha e a high deg ee o assu ance ha
he in o ma ion being en e ed in he con ac is co ec be o e o e ing i o he
applican ; ou goal is o de e mine whe he he combina ion o wo inno a i e
echnologies can assis in his p ocess.
As a conc e e minimal example, we conside he case o a u ili y CSP equi -
ing (a) an applican ’s pe sonal in o ma ion and (b) an applican ’s bank accoun
numbe (IBAN). The eIDAS [10] amewo k is designed o enable a public se -
ice in as uc u e o secu e and emo e iden i y p oo ing4, and he po en ial
o eIDAS-based eID o s ong cus ome au hen ica ion in he banking sec o
is well-known - see o ins ance [6]. The Ve i iable C eden ials W3C ecommen-
da ion [26] is designed o enable he sha ing o e i iable claims abou subjec s
wi h c yp og aphic p oo s o in eg i y and au hen ici y.
In his pape we examine how hese wo amewo ks could be use ully com-
bined in o de o enable secu e emo e con ac ing. To he bes o ou knowledge,
his is he i s PoC combining he wo echnologies wi hou ecou se o Sel -
So e eign Iden i y, e.g. as in he SSI eIDAS b idge [25]. The main non- i ial
alue de i ed om his p oposal is a highe deg ee o assu ance in he con ac
o e ing phase o he CSP. Conside ing he no el y pa icula ly o he VC ecom-
menda ion, ou objec i e was i s and o emos o es he p ac ical easibili y
o he idea; we lea e a p ope secu i y assessmen o u u e wo k.
In Sec ion 2we desc ibe he use case and a scena io we p opose o add ess i .
In Sec ion 3we b ie ly summa ize some o he ele an aspec s o he echnologies
in ou p oposal. In Sec ion 4we desc ibe ou p oo -o -concep implemen a ion.
Finally, in Sec ion 6we e alua e ou indings.
2 Use case: con ac o e ing
We conside he case o a u ili y CSP equi ing (a) an applican ’s pe sonal in-
o ma ion and (b) an applican ’s In e na ional Bank Accoun Numbe (IBAN)
in o de o o e hem a con ac o se ices. In he case o an unknown appli-
can , his in o ma ion will be conside ed Claims by he applican and which he
CSP will ha e o ei he e i y o accep a hei own isk. In o de o mi iga e
agains aud, he CSP would p e e a high le el o assu ance in hese claims,
and a means o e i ying ha : he claims a e co ec and alid, he applican a
he ime o o e ing is he same as he claim subjec , and he issue is a us ed
pa y.
4Iden i y p oo ing is he p ocess o es ablishing ha an unknown applican eally is
who hey claim o be, and is pe o med du ing cus ome onboa ding (e.g. opening
a new bank accoun ); a e onboa ding, accoun s a e associa ed wi h an au hen ica-
o , and subsequen ly au hen ica ion is equi ed o a emo e claiman o access an
en olled iden i y’s esou ces (e.g. online banking). See [18].
2.1 P oposed use case scena io
Conc e ely, ou p oposal is o conside he IBAN o be an a ibu e o a Subjec ,
and o ha e he Accoun Se icing Paymen Se ice P o ide (ASPSP) issue a
Ve i iable C eden ial o ha e ec . A ough componen diag am o ou p oposal
is shown in Figu e 1.
eID Iden i y P o ide
eIDAS T us Se ice
P o ide
Subsc ibe
(applican / claiman )
CSP
ASPSP
eIDAS
Ve i iable C eden ials
eID Relying Pa y
VC Issue
VC Ve i ie
eIDAS login
QSealC issue
eID Au hen ica e
eID Relying Pa y
eIDAS login
QSealC Subjec
eID Subjec
QSealC s a us
VC Subjec & Holde
VC eques
VC e esh
VC p esen
VC con ex
VC s a us
QSealC
VC e i y
Fig. 1: En i ies in ol ed in he p oposal and hei oles unde he wo main us
amewo ks - eIDAS and VC.
F om he pe spec i e o iden i y managemen in he cybe secu i y con ex
o , e.g. SP 800-63B [18], he equi ed in o ma ion abou he applican can be
conside ed as a ibu es o an iden i y, i.e. claims made abou a Subjec by an
Issue o Iden i y P o ide (IDP) wi h some associa ed p oo s o au hen ici y.
The Ve i iable C eden ials [26] W3C ecommenda ion is designed speci ically
o enable he sha ing o e i iable claims abou subjec s wi h c yp og aphic
p oo s o in eg i y and au hen ici y. In ou use case, hey can be iewed as a o m
o au ho iza ion ce i ica es [19], o which i is c i ical o secu i y pu poses o
map he au hen ica ed iden i y o he ce i ica e holde .
In o de o accomplish his, Issue (ASPSP) and Ve i ie (CSP) o he VC can
iden i y he Subjec by hei eIDAS unique iden i ie (See Sec ion eIDAS-based
eID o iden i y p oo ing). The eIDAS amewo k is designed o enable a public
se ice in as uc u e o secu e and emo e iden i y p oo ing; he po en ial o
eIDAS-based eID o s ong cus ome au hen ica ion in he banking sec o is
well-known - see o ins ance [6]. Fo ins ance, one o he eIDAS-no i ied schemes
is he I alian eID ca d, CIE 3.0, and i s use as a means o iden i y p oo ing
du ing emo e onboa ding is al eady explici ly pe mi ed I aly Banki alia AML
egula ions, which s a e ha au hen ica ion h ough an eIDAS-complian scheme
is su icien o pe o m due diligence o he speci ic s ep o iden i y p oo ing,
e en wi hou he physical p esence o he applican ([2] pa 2 sec ion III comma
2).
Using eIDAS, a ci izen wi h an eID is he Subjec o iden i y asse ions
by hei na ional IDP. The Subjec ac ing as a Subsc ibe i s applies o an
accoun a an Accoun Se icing Paymen Se ice P o ide (ASPSP, in he sense
o PSD2), hen ecei es a con ac ing o e om a Con ac ing Se ice P o ide
(e.g. u ili ies o elecoms).
Using Ve i iable C eden ials, he ASPSP issues a e i iable claim ying an
accoun numbe o he Subjec ; he Subjec holds he claim in hei walle , and
p esen s he claim o he CSP in o de o ecei e a con ac o e .
A a high le el, he p oposed s eps would be he ollowing:
1. Reques e , in possession o eID, eques s a new accoun wi h Accoun Se ice
P o ide (ASP)
2. ASP pe o ms au oma ed emo e iden i y p oo ing wi h eID h ough “login
wi h eIDAS”
3. Bank issues a VC wi h he eques e ’s eID “Pe sonIden i ie ” as subjec and
he new IBAN as a ibu e
4. Reques e eques s a con ac o e om Se ice P o ide (SP)
5. SP pe o ms au oma ed emo e iden i y p oo ing wi h eID h ough “login
wi h eIDAS”
6. SP e i ies VC o ype IBAN and ma ches VC subjec a ibu e wi h eIDAS
“Pe sonIden i ie ”
3 Backg ound: eIDAS and SAML SSO
3.1 eIDAS-based eID
eIDAS allows Relying Pa ies (RP) o ecei e asse ions on a co e a ibu e
se [12] o eID bea e s om he eIDAS a ibu e p o ile. Be ween membe s a e
eIDAS nodes, he p o ocol chosen o such asse ions is SAML 2 [24]. Fo na u al
pe sons, he co e a ibu es a e summa ized in Table 1.
Table 1: eIDAS a ibu es o na u al pe sons ([12]).
Manda o y Op ional
Cu en Family Name Fi s Names a Bi h
Cu en Fi s Names Family Name a Bi h
Da e o Bi h Place o Bi h
Unique Iden i ie Cu en Add ess
Gende
The Unique Iden i ie ield can be le e aged by VC issue s o iden i y claim
subjec s. The asse ion by he membe s a e IDP on manda o y a ibu es can
be le e aged by he CSP in he con ac ing phase. A lis o no i ied eIDAS
schemes is in o mally main ained by he eID Use Communi y [9]. The eIDAS
in e ope abili y amewo k [11] enables each membe s a e o no i y one o mo e
eID schemes based on di e en echnology and p ocesses, om na ional iden i y
ca ds o mobile-based solu ionss. The eIDAS egula ion [10] es ablishes a Le el
o Assu ance (LoA) o each scheme - low, subs an ial, o high. Minimum e-
qui emen s o each LoA se ou in [7], and guidelines on how each scheme may
conc e ely a ain an LoA a e published by he Coope a ion Ne wo k [8]. Secu-
i y conside a ions on eIDAS complian eID schemes ha e also been published
by ENISA [14].
The secu i y o eIDAS schemes has been he subjec o sc u iny in [13]. The
secu i y p ope ies o each scheme depend on i s echnology and p ocesses. Co-
ope a ion Ne wo k guidelines o e some clues as o he p ope ies ha can be
expec ed om each LoA; o ins ance, a subs an ial LoA equi es he means o
au hen ica ion o be based on a leas wo ac o s and be demons ably unde he
con ol o he subjec o whom i belongs (e.g. one biome ic and/o knowledge
ac o ), whe eas he high LoA equi es addi ional p o ec ion agains duplica ion,
ampe ing, and use by o he s. By way o example, CIE 3.0 has been acco ded a
high LoA; i con ains a chip wi h Common C i e ia ce i ica ion agains duplica-
ion and ampe ing, and he p i a e key in he chip is unocked by PIN numbe ,
he eby p o iding ac o s o possession and knowledge du ing au hen ica ion.
CIE 3.0 chip speci ica ions [23] ha e mo e de ail on compliance wi h PACE and
EAC mechanisms o au hen ica ion, con iden iali y, and in eg i y.
3.2 SAML SSO
In his pape we conside he SAML 2.0 Web B owse SSO P o ile [24] (SAML
SSO) since he conc e e eID scheme we ha e in mind is based on a SAML 2.0
IDP [20], and he web b owse p o ile i s ou use case (Sec ion 2) and ou im-
plemen a ion (Sec ion 4). Fully mobile and hyb id scena ios a e also conside ed
in he documen a ion bu beyond he scope o he p esen p oo o concep .
Th ee en i ies a e in ol ed: a Clien (C), an Iden i y P o ide (IDP), and
a Se ice P o ide (SP). C is a web b owse wi h which a use in e ac s; he
use ’s goal is o ha e access o a se ice o a esou ce p o ided by he SP. IDP
au hen ica es C and issues au hen ica ion asse ions ha a e us ed by SP -
he SSO us ela ionship is depic ed wi h a handshake icon in Figu e 2. SP
uses he asse ions gene a ed by he IDP o decide on C’s en i lemen o he
eques ed se ice o esou ce.
Figu e 2shows a Message Sequence Cha (MSC)5o he main s eps o he
SAML SSO p o ocol, which we can b ie ly desc ibe as ollows:
5Each e ical line in an MSC ep esen s an en i y, and ho izon al a ows ep esen
messages om one componen o ano he . Iden i y manangemen p o ocols a e o en
exp essed as MSC o iden i y any laws.
Fig. 2: Message Sequence Cha (MSC) o he SAML SSO p o ocol [1].
S1 C asks SP o p o ide he esou ce a URI.
A1-2 SP sends C an HTTP edi ec esponse (s a us code 302) o IDP, con-
aining an au hen ica ion eques Au hReq(ID,SP), whe e ID is a andomly
gene a ed s ing uniquely iden i ying he eques (s eps A1 and A2). A e-
quen implemen a ion choice is o use he RelayS a e ield o ca y he
o iginal URI ha C has eques ed (see [24]).
↔IDP challenges C o p o ide alid c eden ials (do ed double a ows in he
igu e): his is no speci ied in he s anda d o he SAML SSO in o de o
accommoda e any au hen ica ion p ocess o e ed by IDP.
A3-4 I he au hen ica ion succeeds, IDP builds an au hen ica ion asse ion as
he uple AA = Au hAsse (ID, C, IDP, SP) and embeds i in a esponse
message Resp = Response(ID, SP, IDP, {AA}K−1
IDP ) whe e {AA}K−1
IDP is he
asse ion signed wi h IDP’s p i a e key ( he key icon in Figu e 2). IDP places
Resp and he alue o RelayS a e ecei ed om SP in o an HTML o m and
sends he esul back o C in an HTTP esponse (s ep A3) oge he wi h
some sc ip ha au oma ically pos s he o m o SP (s ep A4).
S2 Finally, he SP sends C an accep ed HTTP esponse (s a us code 200) con-
aining he eques ed esou ce.
3.3 eIDAS-complian ce i ica es and PSD2
eIDAS-complian Quali ied Ce i ica es con o ming o ETSI TS 119 495 [15]
a e he s anda d o PSD2 API o bo h au hen ica ion (Quali ied Websi e Au-
hen ica ion Ce i ica es - QWAC) and non- epudia ion / con en commi men
(Quali ied Elec onic Seal Ce i ica es - QSealC).
The Be lin g oup access- o-accoun implemen a ion guidelines [4] equi e
mu ual au hen ica ion o TPP and ASPSP using eIDAS- and RTS-complian
Quali ied Ce i ica es, which mus include all he oles o which he TPP is
au ho ized. Open Banking Eu ope6main ains a lis o Quali ied T us Se ice
P o ide s issuing PSD2-complian Quali ied Ce i ica es.
4 Scena io and implemen a ion
The en i ies in ol ed in he scena io and hei oles a e:
1. eID holde - Subjec o an IDP-issued eIDAS-based eID documen
2. eID IDP
3. eID OCSP esponde
4. ASPSP - Relying Pa y o IDP unde eIDAS, QWAC and QSealC Subjec
unde eIDAS, Issue o VC
5. CSP - Relying Pa y o IDP unde eIDAS, Ve i ie o VC
Ou eID subjec s a e au hen ica ed o SPs h ough an X.509 ce i ica e,
designed o esemble he basic elemen s o he I alian eID ce i ica e speci i-
ca ions [23]. In pa icula , he Subjec commonName ield con ains an unique
iden i ie o he pe son independen o he indi idual ce i ica e o documen ,
he only allowed key usage is au hen ica ion (digi al signa u e), and ex ended
key usage is clien au hen ica ion.
All he se e s (en i ies 2-5) a e de eloped using NodeJS, and hei se ices
ha e been con igu ed o wo k o e a secu e communica ion channel (HTTPS)
o p o ec hem om man-in- he-middle a acks, in he p o ocol o he CIE 3.0
eID scheme as desc ibed in he manual o SPs [20]. Se e s ha e wo sepa a e
ce i ica es, one o se e au hen ica ion and one o non- epudia ion. In gene al,
hese could be issued by any au ho ized CA; in ou speci ic use case, we hink
i plausible ha hese would be Quali ied Websi e Au hen ica ion (QWAC) and
Quali ied Seal Ce i ica es (QSealC), espec i ely.
Ou sample implemen a ion is conce ned mainly wi h he Se ice P o ide
pa o he a chi ec u e suppo ing au hen ica ion and e i iable c eden ial issu-
ing and e i icai ion o suppo he use case. Ou p oo -o -concep implemen a-
ion is a ailable on gi hub7. We gi e a high-le el desc ip ion he e and e e he
in e es ed eade o he eposi o y o implemen a ion de ails.
4.1 SAML
The wo SPs (en i ies 4,5) implemen SAML h ough he passpo -saml module.
The IDP uses he saml-idp module.
A e ecei ing he SAMLReques om he SP, he IDP e i ies i oge he
wi h he au hen ica ion eques he clien has also p o ided he ce i ica e. I ha
is he case, a e i ica ion p ocess s a s. The IDP checks i he clien ce i ica e
has been signed by he Ce i ica ion Au ho i y (CA) i expec s, whe he i has
6h ps://www.openbankingeu ope.eu/q sps-and-eidas/
7h ps://gi hub.com/s bk/ c-saml-node.
expi ed, and inally whe he i has been e oked. The la e ope a ion is achie ed
by an API call o he OCSP se ice, which exposes an API ha accep s as inpu
a ce i ica e, checks i i s se ial numbe belongs o he lis o e oked ones and
e u ns ‘good’, ‘ e oked’, o ‘unknown’ acco dingly.
I all hese checks a e success ul and he use g an s access o hei da a o
he SP, he SAMLResponse is gene a ed and sen back o he SP, which pa ses
i and shows he con ained a ibu es.
The SAML implemen a ion has been designed wi h a iew owa ds in e-
g a ion wi h ou con aine -based iden i y managemen aining en i onmen ,
Mic o-Id-Gym [5].
4.2 Ve i iable C eden ials
Ve i iable C eden ials (VC) allow Issue s o issue Claims - signed s a emen s
abou Subjec s. Issue s a e iden i ied by a URI, Subjec s may be iden i ied by a
URI o a se o a ibu es.
We highligh he ollowing s eps aken o adap he VC da a model [26] o
ou use case, and we no e ha he issue has o p o ide in o ma ion abou i sel
and he c eden ials i has issued ia speci ic endpoin s, in a manne no unlike an
iden i y p o ide . The endpoin s a e o be aken as ollowing he issue ’s domain,
h ps://<issue hos >8. An example o an issued VC is shown in Lis ing A
(Sec ion A).
e i ica ion The VC has an embedded p oo p ope y cons uc ed as a digi al
signa u e wi h he issue ’s non- epudia ion p i a e key, co esponding o
hei us p o ide -issued non- epudia ion ce i ica e. The public key can
be ob ained om he con olle documen a he /issue endpoin .
c eden ial ype and con ex We needed o in oduce he subjec a ibu es
o eIDAS unique iden i ie and IBAN in he VC issued by he ASPSP. This
was done by de ining a cus om con ex , which he issue makes a ailable
h ough an /c eden ial/iban endpoin .
issuance, expi a ion, and s a us Issuance and expi a ion da es a e added,
and a /c eden ial/s a us endpoin can be called o check whe he he
VC has been e oked.
5 Rela ed wo k
An applica ion o VCs o a inancial use case (KYC) was shown in [21], based on
he FIDO UAF p o ocol in an adap a ion desc ibed by he same au ho s in [22].
The subjec is assumed o ha e al eady been en olled wi h a ibu e au ho i ies,
which issue VCs ha can be used as pa o he KYC p ocess. B oadly speaking,
his use o VCs is simila o he one he e p oposed. Howe e , FIDO is s ic ly an
au hen ica ion p o ocol, no co e ing iden i ica ion. In [22], a new public-p i a e
8In ou simple nodejs-based p oo -o -concep implemen a ion, his is localhos ol-
lowed by a po iden i ying he se ice p o ide .
key pai is c ea ed o each au hen ica o -se ice p o ide pai , so he e is no such
no ion as a unique iden i ie o he subjec ; his is by design, o p i acy easons.
The exclusi e use o FIDO in his manne hus equi es issuing a sepa a e VC
o he same subjec o e e y new se ice p o ide , wi h an exponen ial inc ease
in VCs o be managed, and seems coun e -in ui i e o he use case o con ac
signing.
In ou p oposal, he use o a unique iden i ie o he subjec is one o he
key ea u es le e aged om eIDAS. The use o FIDO2 au hen ica o s may hen
play an impo an ole as pa o eID schemes, o ins ance as p oposed in a
FIDO alliance whi e pape on he use o FIDO2 o eIDAS [17], ei he using he
au hen ica o in lieu o he eID ca d i sel , o o au hen ica e he subjec o a
QTSP emo ely s o ing hei Quali ied Ce i ica e and p i a e key.
6 Lessons lea ned and conclusion
Added alue The main non- i ial alue de i ed om his p oposal is a highe
deg ee o assu ance in he con ac o e ing phase o he Con ac ing Se ice
P o ide . While he e a e some cos s and echnical know-how equi ed in becom-
ing a Se ice P o ide unde eIDAS, hese a e p edic able cos s and expec ed o
be qui e small, as opposed o cos s incu ed as a consequence o aud, li iga ion
agains epudia ion, and plain e o s due o manually en e ed da a.
The abili y o pe o m iden i y p oo ing emo ely is o cou se highly alu-
able, bu on i s own i is enabled by eIDAS as an explici design goal, and
is no new o speci ic o his p oposal. A he same ime, o a inancial use
case i is ex emely plausible o use an eIDAS login as a s a ing poin since i
s ongly con ibu es o an ASPSP’s AML compliance. The addi ion o Ve i iable
C eden ials based on eIDAS is a syne gy expec ed o enable an ecosys em o
high-assu ance con ac ing se ices.
ASPSP as VC Issue s The solu ions adop ed by inancial se ices p o ide s
o en o m he gold s anda d o iden i y p oo ing and au hen ica ion, and in
some cases banks ac as iden i y p o ide s hemsel es (e.g. BankID [3]). I is no
un easonable o assume ha inancial ins i u ions would be willing o o e VC
issuing se ices; he se -up in ol ed is in some ways less one ous, in he sense
ha hey do no equi e ede a ion be ween Issue and Ve i ie , and he Subjec
is esponsible o hei sha ing.
Wi h e e ence o he API commonly p oposed o comply wi h PSD2, VCs
also appea mo e adequa e o sha ing long- e m in o ma ion ha may be con-
side ed an a ibu e o he subjec , as opposed o li e in o ma ion abou hei
ASPSP-managed accoun , such as a ailabili y o unds and ini ia ion o paymen s
e c. In ou p oposal, a con ac ing SP does no ha e o ake he subjec ’s iden i y
a ibu es and eques in o ma ion abou a ela ed IBAN h ough a PISP; he
SP can immedia ely ma ch he subjec ’s au hen ica ion o he subjec o he VC
and only has o e i y he alidi y o he VC i sel .
