-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathonboarding.html
1032 lines (979 loc) · 74 KB
/
onboarding.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Onboarding and Service Certification in DOME - draft 3</title>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<!-- Opengraph Facebook Meta Tags -->
<meta property="og:title" content="Onboarding and Service Certification in DOME - draft 3">
<meta property="og:type" content="website">
<meta property="og:description" content="Onboarding and Service Certification in DOME">
<meta property="og:site_name" content="Onboarding and Service Certification in DOME">
<meta property="og:url" content="https://dome-marketplace.github.io/powers-of-representation/onboarding.html">
<script src="https://www.w3.org/Tools/respec/respec-w3c" async="" class="remove"></script>
<script class="remove">
var respecConfig = {
latestVersion: "https://dome-marketplace.github.io/powers-of-representation/onboarding.html",
edDraftURI: "https://dome-marketplace.github.io/powers-of-representation/onboarding.html",
github: "https://github.com/dome-marketplace/powers-of-representation",
editors: [
{
company: "JesusRuiz",
companyURL: "https://hesusruiz.github.io/",
email: "[email protected]",
name: "Jesus Ruiz",
},
],
authors: [
{
name: "The DOME project participants",
},
],
localBiblio: {
"Actor-DataSpaces": {
date: "April 2023",
href: "https://dl.acm.org/doi/pdf/10.1145/3543873.3587645",
title: "Extending Actor Models in Data Spaces",
},
"Apodera": {
date: "2012",
href: "https://ec.europa.eu/digital-building-blocks/wikis/display/EIDCOMMUNITY/STORK+2.0+WP3+-+Legal+and+Trust+Analysis?preview=/84415420/84415378/STORK_2_0_D3_3_MandateAttribute_Management_Report_v_1_0.pdf",
title: "Electronic Register of Powers",
},
"Cryptographic Hyperlinks": {
date: "May 2021",
href: "https://w3c-ccg.github.io/hashlink/",
title: "Cryptographic Hyperlinks",
},
"DEP-DSS": {
date: "2019-10",
href: "https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/Qualified+electronic+signature+-+QES+validation+algorithm",
publisher: "European Commission",
title: "Algorithm for Validation of qualified and advanced signatures and seals",
},
"DID-DNS": {
href: "https://tools.ietf.org/html/draft-mayrhofer-did-dns-01",
publisher: "IETF",
status: "Internet Draft",
title: "The Decentralized Identifier (DID) in the DNS",
},
"DID-ELSI": {
date: "February 2024",
href: "https://dome-marketplace.github.io/did-method-elsi/",
title: "DID ETSI Legal person Semantic Identifier Method Specification (did:elsi)",
},
"DID-PRIMER": {
href: "https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/did-primer.md",
publisher: "Rebooting the Web of Trust 2017",
title: "DID Primer",
},
"DIF.PresentationExchange": {
href: "https://identity.foundation/presentation-exchange/spec/v2.0.0/",
title: "Presentation Exchange 2.0.0",
},
"EDIW.ARF": {
date: "20 April 2023",
href: "https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/arf.md",
title: "EUDI Wallet Architecture and Reference Framework 1.1.0",
},
"ENISA-Qualified Electronic Seals": {
date: "June 2017",
href: "https://www.enisa.europa.eu/publications/security-guidelines-on-the-appropriate-use-of-qualified-electronic-seals",
title: "Security guidelines on the appropriate use of qualified electronic seals",
},
"ENISA-Qualified Electronic Signatures": {
date: "December 2016",
href: "https://www.enisa.europa.eu/publications/security-guidelines-on-the-appropriate-use-of-qualified-electronic-signatures",
title: "Security guidelines on the appropriate use of qualified electronic signatures",
},
"ETSI-CERTOVERVIEW": {
date: "2020-07",
href: "https://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.04.02_20/en_31941201v010402a.pdf",
publisher: "ETSI",
title: "ETSI EN 319 412-1 V1.4.2 (2020-07) - Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures",
},
"ETSI-LEGALPERSON": {
date: "2020-07",
href: "https://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.02.01_60/en_31941203v010201p.pdf",
publisher: "ETSI",
title: "ETSI EN 319 412-3 V1.2.1 (2020-07) - Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 3: Certificate profile for certificates issued to legal persons",
},
"EU_Trusted_Lists": {
href: "https://digital-strategy.ec.europa.eu/en/policies/eu-trusted-lists",
title: "EU Trusted Lists",
},
"JAdES": {
date: "2021-03",
href: "https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf",
publisher: "ETSI",
title: "ETSI TS 119 182-1 V1.1.1 (2021-03) - Electronic Signatures and Infrastructures (ESI); JAdES digital signatures; Part 1: Building blocks and JAdES baseline signatures",
},
"NIST-AUTH": {
date: "October 2016",
href: "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-178.pdf",
title: "NIST Special Publication 800-178: A Comparison of Attribute Based Access Control (ABAC) Standards for Data Service Applications",
},
"ODRL": {
date: "February 2018",
href: "https://www.w3.org/TR/odrl-model/",
title: "ODRL Information Model 2.2",
},
"OWASP-TRANSPORT": {
href: "https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet",
title: "Transport Layer Protection Cheatsheet",
},
"OpenID.Core": {
date: "8 November 2014",
href: "http://openid.net/specs/openid-connect-core-1_0.html",
title: "OpenID Connect Core 1.0 incorporating errata set 1",
},
"OpenID.SIOP2": {
date: "28 January 2022",
href: "https://openid.bitbucket.io/connect/openid-connect-self-issued-v2-1_0.html",
title: "Self-Issued OpenID Provider v2",
},
"OpenID.VCI": {
date: "8 February 2024",
href: "https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html",
title: "OpenID for Verifiable Credential Issuance - draft 13",
},
"OpenID.VP": {
date: "29 November 2023",
href: "https://openid.net/specs/openid-4-verifiable-presentations-1_0-20.html",
title: "OpenID for Verifiable Presentations - draft 20",
},
"RFC6749": {
href: "https://www.rfc-editor.org/rfc/rfc6749.html",
title: "The OAuth 2.0 Authorization Framework",
},
"RFC7515": {
href: "https://www.rfc-editor.org/rfc/rfc7515",
title: "JSON Web Signature (JWS)",
},
"RFC7519": {
href: "https://www.rfc-editor.org/rfc/rfc7519",
title: "JSON Web Token (JWT)",
},
"RFC8414": {
href: "https://www.rfc-editor.org/rfc/rfc8414",
title: "OAuth 2.0 Authorization Server Metadata",
},
"RFC8725": {
href: "https://www.rfc-editor.org/rfc/rfc8725",
title: "JSON Web Token Best Current Practices",
},
"RPaM-Ontology": {
date: "2020",
href: "https://github.com/everis-rpam/RPaM-Ontology/wiki/Ontology-Development-Report",
title: "Representation Powers and Mandates (RPaM) Ontology",
},
"STORK2.MandateReport": {
date: "2012",
href: "https://ec.europa.eu/digital-building-blocks/wikis/display/EIDCOMMUNITY/STORK+2.0+WP3+-+Legal+and+Trust+Analysis?preview=/84415420/84415378/STORK_2_0_D3_3_MandateAttribute_Management_Report_v_1_0.pdf",
title: "STORK 2.0: D.3.3 – Mandate/Attribute Management Report",
},
"eIDAS": {
href: "https://digital-strategy.ec.europa.eu/en/policies/discover-eidas",
title: "Discover eIDAS",
},
"eIDAS-SAML_V1.2": {
date: "August 2019",
href: "https://ec.europa.eu/digital-building-blocks/wikis/download/attachments/467109280/eIDAS%20SAML%20Attribute%20Profile%20v1.2%20Final.pdf",
title: "eIDAS SAML Attribute Profile. Version 1.2",
},
"eIDAS.Regulation": {
date: "23 July 2014",
href: "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG",
title: "Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC",
},
"eIDAS2.Regulation": {
date: "March 2023",
href: "https://www.europarl.europa.eu/doceo/document/A-9-2023-0038_EN.html",
title: "REPORT on the proposal for a regulation of the European Parliament and of the Council amending Regulation (EU) No 910/2014 as regards establishing a framework for a European Digital Identity",
},
},
};
</script>
<link rel="stylesheet" href="./assets/templates/respec/additional.css">
</head>
<body>
<p class="copyright">
Copyright © 2024 the document editors/authors. Text is available under the
<a rel="license" href="https://creativecommons.org/licenses/by/4.0/legalcode">
Creative Commons Attribution 4.0 International Public License</a>
</p>
<section id='abstract'>
<p>This document describes the DOME Onboarding process and its associated Digital Identity Management system, used to interact with DOME services.
</p>
</section>
<section id='Overview of Onboarding and Service Certification'><h2>Overview of Onboarding and Service Certification</h2>
<p>Before your company can publish Product Offerings in the DOME Marketplace, the following steps have to be performed:
</p>
<ol>
<li><b>Onboarding of the company</b> in the DOME Marketplace, requiring:
<ul>
<div>
<li><b>Identification and verification of the legal representative</b> and the right of representation.
<div>
<p>The employee performing the onboarding process has to be able to demonstrate to the DOME Operator that it has the powers required to act on behalf of your company for the process of onboarding in DOME. The employee can be a legal representative or an employee "nominated" by a legal representative for the specific purpose of performing the process of onboarding in DOME.
</p>
</div>
</li>
</div>
<div>
<li><b>Identification of legal person (the company)</b> on the basis of documents and data submitted, and verification of the submitted information on the basis of information obtained from a reliable and independent source.
<div>
<p>You have to demonstrate that your company is incorporated and that is has basic legal capacity to act in the EU internal market.
</p>
</div>
</li>
</div>
</ul>
</li>
<li><b>Certification of each Product Offering</b>, required to be able to publish a product offering in the marketplace. It is done for each product offering.
<div>
<p>For each product offering that you want to publish in the DOME Marketplace, your company has to demonstrate that the product complies with the requirements setup by DOME (as per the requirements from the European Commission and Member States).
</p>
</div>
</li>
</ol>
<p>We describe in this document both processes, because they are very interrelated: you have to prove some facts about your company and its product offereings before they are published in the DOME Marketplace. The mechanisms for those proofs are very similar.
</p>
<section id='Onboarding of your company in DOME'><h2>Onboarding of your company in DOME</h2>
<p>If your company is already using eIDAS certificates (e.g., for digitally signing PDFs, invoices or other types of documents), then the process can be performed digitally. Using advanced or qualified signatures facilitates a fully digital and automated cross-border onboarding process, and at the same time provides a reasonable balance between automation, convenience, and level of legal certainty and security.
</p>
<p>However, there are still countries in the EU which are lagging in the widespread use of eIDAS signatures. This is expected to change soon, given the push provided by the introduction of eIDAS2 and thanks to a timely implementation of the European Digital Identity Wallet by the Member States (they will be obliged to issue Digital Identity Wallets within 12 months of the entry into force of the Regulation).
</p>
<p>This is the reason why, in the mean time, we provide two mechanisms for onboarding in DOME:
</p>
<ol>
<li>A <b>digital and automated cross-border onboarding</b> process based on signatures under the current eIDAS legal framework and aligned at the same time with eIDAS2, which provides a reasonable balance between automation, convenience, and level of legal certainty and security. This is the preferred mechanism.
</li>
<li>A <b>“classical” manual process</b>, which is more <b>cumbersome, lengthy, and inconvenient</b> than the digital one, but is available as an exceptional temporary measure to those companies not yet at the required level of digitalisation in the eIDAS framework and which are not capable of using eIDAS digital signatures.
</li>
</ol>
<p>The diagram below describes an overview of both processes
</p>
<figure><img class='figureshadow' src='builtassets/plantuml_b50b13ff55985e0faf33e87f7924e21d.png' alt='Overview of onboarding processes'>
<figcaption>Overview of onboarding processes</figcaption></figure>
</section>
<section id='Service Certification in DOME'><h2>Service Certification in DOME</h2>
<p>TBD.
</p>
</section>
</section>
<section id='Digital onboarding process'><h2>Digital onboarding process</h2>
<p>The digital onboarding process is the following:
</p>
<ol>
<li>A legal representative of your company authorises an employee to perform the process of onboarding. This is done by issuing a LEARCredential to the employee.
</li>
<li>The authorised employee starts the onboarding process in the DOME onboarding portal, authenticating with the LEARCredential. The employee completes the forms presented by the DOME portal, and the onboarding process is completed.
</li>
</ol>
<p>Both steps are described below.
</p>
<section id='Issuing the LEARCredential'><h2>Issuing the LEARCredential</h2>
<section id='Go to the DOME Issuer portal'><h2>Go to the DOME Issuer portal</h2>
<p>The DOME Issuer portal is located at https://dome.mycredential.eu/ and below is an image of the screen.
</p>
<figure><img class='figureshadow' src='images/dome_issuer/dome_issuer_home.png' alt='DOME Issuer portal'>
<figcaption>DOME Issuer portal</figcaption></figure>
<p>The site is intended for Legal Representatives of companies who want to issue one or more LEARCredentials to one or more employees of the company. A LEARCredential is a type of Verifiable Credential which enables an employee, nominated by a legal representative, to act on behalf of an organisation with restricted powers with respect to third-parties.
</p>
<p>The issuer (the creator) of the LEARCredential must be a legal representative of the company. The legal representative will sign the LEARCredential with an eIDAS digital certificate, which can be either a personal one or a certificate of representation.
</p>
<p>The receiver of the LEARCredential (both the subject and holder of the credential) can be any employee (or contractor) of the company. The legal representative will delegate a restricted set of powers to that person. Those restricted powers are included inside the credential and can be verified by any Relying party to whom the holder presents the LEARCredential.
</p>
<p>If you are a legal representative of the company and you have an eIDAS certificate installed in your PC, click on the yellow button to start the process:
</p>
<figure style='width:30%'><img class='figureshadow' src='images/dome_issuer/login_as_legal_representative.png' alt='Go to Issuer'>
<figcaption>Go to Issuer</figcaption></figure>
</section>
<section id='Select the eIDAS certificate to use'><h2>Select the eIDAS certificate to use</h2>
<p>Once you click the button, you will be directed to the page of the DOME Issuer to start creating LEARCredentials.
</p>
<p>The browser will request that you select the certificate to use, with a screen like the following:
</p>
<figure><img class='figureshadow' src='images/dome_issuer/select_certificate.png' alt='Select certificate'>
<figcaption>Select certificate</figcaption></figure>
</section>
<section id='Register for the service'><h2>Register for the service</h2>
<p>The first time you enter, you must register and verify your company email, using the following screen.
</p>
<figure><img class='figureshadow' src='images/dome_issuer/register_email.png' alt='Register email'>
<figcaption>Register email</figcaption></figure>
<p>Enter your email address and click the button "Register (if this is the first time)".
</p>
<p>You will receive an email requesting confirmation, which is needed before you can logon in the system.
</p>
<p>If you do not receive the email (from [email protected]), please check in spam just in case your email client has automatically classified it as spam.
</p>
<p>Once you have verified your email you can logon in the system using the same screen as above.
</p>
</section>
<section id='List of LEARCredentials'><h2>List of LEARCredentials</h2>
<p>After logging in for the first time, you will see an empty screen like the following. Click on the button to create a new LEARCredential.
</p>
<figure><img class='figureshadow' src='images/dome_issuer/list_of_offers_1.png' alt='List of Offers 1'>
<figcaption>List of Offers 1</figcaption></figure>
</section>
<section id='LEARCredentialForm'><h2>LEARCredentialForm</h2>
<p>A form to fill the data of the LEARCredential appears, like the following:
</p>
<figure><img class='figureshadow' src='images/dome_issuer/credential_form_1.png' alt='LEARCredential form'>
<figcaption>LEARCredential form</figcaption></figure>
<p>The form has the following sections:
</p>
<section id='Mandator'><h2>Mandator</h2>
<p>The Mandator is the person delegating a restricted set of powers onto an employee (the Mandatee). This part of the form is pre-filled with information coming from the eIDAS certificate that was used to enter into the application, plus the email address that was registered and verified.
</p>
<p>You do not have to enter anything else in this section.
</p>
<figure><img class='figureshadow' src='images/dome_issuer/mandator.png' alt='Mandator'>
<figcaption>Mandator</figcaption></figure>
</section>
<section id='Mandatee'><h2>Mandatee</h2>
<p>The Mandatee is the employee (or subcontractor) who receives a restricted set of powers to act on behalf of the company with third-parties. In our case, the employee will be empowered to perform the Onboarding process in DOME, and maybe to create Product Offerings in the Marketplace.
</p>
<p>You have to fill the data corresponding to the employee that you want to nominate to perform the Onboarding process. After creating the LEARCredential, the employee will receive a notification in the email address that you entered in the form.
<figure><img class='figureshadow' src='images/dome_issuer/mandatee.png' alt='Mandatee'>
<figcaption>Mandatee</figcaption></figure>
</p>
</section>
<section id='Powers'><h2>Powers</h2>
<p>These are the specific powers that the Mandator (you) is delegating on the Mandatee (the employee).
</p>
<p>The LEARCredential is a general purpose electronic Mandate, but in our case we need only two powers:
</p>
<li>Execute the Onboarding process in DOME
</li>
<li>Create/Update/Delete one or more Product Offerings in the DOME Marketplace
</li>
<figure><img class='figureshadow' src='images/dome_issuer/powers.png' alt='Powers'>
<figcaption>Powers</figcaption></figure>
<p>You can assign each power to a different employee (with one LEARCredential for each employee), or both powers to the same employee (with one LEARCredential including both powers). You can even generate more than one LEARCredential with the same or different powers to one or more employees. This is up to you and how you want to distribute the powers among your employees.
</p>
<p>The Mandate in the form of a Verifiable Credential behaves like its paper counterpart with regards to these properties.
</p>
<p>For Onboarding, make sure that the employee receives at least the Onboarding power:
</p>
<figure><img class='figureshadow' src='images/dome_issuer/powers_onboarding.png' alt='Onboarding'>
<figcaption>Onboarding</figcaption></figure>
</section>
</section>
<section id='Create a first version of the LEARCredential'><h2>Create a first version of the LEARCredential</h2>
<p>Press the "Create" button at the bottom of the form. This will take you to a screen with the machine-readable representation of the new LEARCredential. Do not worry, you do not have to understand this, but if you do (or somebody in your company) it is a good way to see the actual contents that will go inside the LEARCredential, before sending it to the employee.
</p>
<figure><img class='figureshadow' src='images/dome_issuer/json_credential_offer.png' alt='JSON model Onboarding'>
<figcaption>JSON model Onboarding</figcaption></figure>
<p>Click the button at the bottom of the screen to save the draft version of the credential and send a notification to the target employee via email.
</p>
</section>
<section id='List of created LEARCredentials'><h2>List of created LEARCredentials</h2>
<p>You are taken back to the list of LEARCredentials that you have created. If this is the first time that you have created a credential, thee screen looks like the following.
</p>
<figure><img class='figureshadow' src='images/dome_issuer/list_of_offers_one_credential.png' alt='List of one credential'>
<figcaption>List of one credential</figcaption></figure>
<p>The button "View" at the left of every item allows you to review the credential, and also to send a reminder email to the target employee, in case the employee has not yet retrieved the credential.
</p>
<p>LEARCredentials have three states:
</p>
<li><b>offered</b>: A draft version of the credential has been created with all required information about Mandator, Mandatee and the Powers of Representation. A notification via email has been sent to the employee who will receive the powers. The name <code>offered</code> denotes that the employee has to accept the credential and load it to the Wallet of th eemployee.
</li>
<li><b>tobesigned</b>: The employee has accepted the LEARCredential, after reviewing the information contained in it. This step is necessary because the LEARCredential contains cryptographic material which will allow the employee to authenticate to DOME, and that cryptographic material can only be generated by the Wallet of the employee, to ensure the solo control of the private key.
</li>
<li><b>signed</b>: After the employee accepts the credential, you have to sign it with your eIDAS certificate. After your signature, the credential is signed and ready to be loaded by the employee in her Wallet and use it.
</li>
</ul>
</section>
<section id='The employee receives a notification for the LEARCredential'><h2>The employee receives a notification for the LEARCredential</h2>
<p>The employee receives an email notification like the one below.
</p>
<figure><img class='figureshadow' src='images/dome_issuer/employee_offer_notification.png' alt='Employee email notification initial'>
<figcaption>Employee email notification initial</figcaption></figure>
<p>When clicking on the button, the employee is directed to the DOME Issuer portal to review and (possibly) confirm the LEARCredential.
</p>
<p>The screen that the employee sees is similar to the one below.
</p>
<figure><img class='figureshadow' src='images/dome_issuer/employee_credential_accept_portal.png' alt='Employee Issuer portal initial'>
<figcaption>Employee Issuer portal initial</figcaption></figure>
<p>The employee has several possibilities for receiving and using the LEARCredential. The employee can use any Wallet which is compatible with the current EDIW implementation.
</p>
<p>However, while the market matures, DOME offers a reference implementation of a Wallet which is the one we will use for the description of the onboarding process.
</p>
<p>The DOME Wallet is a web application that can be used in several types of devices: mobile, tablet, PC. It supports iOS, Android, Windows, Mac, Linux and other environments where a standards-compliant implementation of an Internet browser is available (like ChromeOS).
</p>
<p>The functionalities of the DOME Wallet are not as comprehensive as in native implementations, but they are enough to support the requirements of the DOME Marketplace.
</p>
<p>For this tutorial, we will use the DOME Wallet and for simplicity we will assume the employee uses the Wallet in the same device that was used to present the previous screen.
</p>
<p>In order to proceed, the employee clicks on the following link (even if the device is not a mobile):
</p>
<figure><img class='figureshadow' src='images/dome_issuer/employee_credential_accept_portal_link.png' alt='Employee Issuer portal link'>
<figcaption>Employee Issuer portal link</figcaption></figure>
</section>
<section id='The employee reviews and confirms the LEARCredential'><h2>The employee reviews and confirms the LEARCredential</h2>
<p>When clicking the above link, a new Wallet is automatically provisioned for the employee in the device that the employee is using, and the Wallet presents the draft version of the LEARCredential to the user.
</p>
<p>The employee sees a screen that looks like the following.
</p>
<figure style='width:50%'><img class='figureshadow' src='images/dome_issuer/wallet_review_offered_credential.png' alt='Wallet review offer'>
<figcaption>Wallet review offer</figcaption></figure>
<p>The Wallet displays a preview of the LEARCredential. The credential is marked with a red warning stating that the credential is not yet valid because it is missing the signature from the legal representative. This signature will be performed later.
</p>
<p>The employee has to accept the credential by clicking the button "Save credential". Once this is done, the credential changes to the status <code>tobesigned</code> and is ready to be signed by the legal representative.
</p>
</section>
<section id='The legal representative signs the LEARCredential'><h2>The legal representative signs the LEARCredential</h2>
<p>The legal representative has to use the eIDAS certificate to sign the LEARCredential and there are different ways to perform this signature. We describe here the most common scenario, where the legal representative has installed the certificate in her PC. This is the typical way to sign PDFs (e.g., with Acrobat Reader), and in the same way, the legal representative has to use a program in her PC to sign the LEARCredential.
</p>
<p>DOME provides such a program, called "elsignerw". Installation is very simple and involves simply to download the binary and running it whenever is needed.
</p>
</section>
</section>
</section>
<section id='Manual onboarding process'><h2>Manual onboarding process</h2>
<p>As in the digital case, we also require that the natural person driving the onboarding process should be either a legal representative of the participant or a natural person that has been delegated by a legal representative at least the powers required to perform the onboarding process on behalf of the legal entity.
</p>
<p>Without digital signatures, the process is the following:
</p>
<table class='w3-table-all'>
<tr>
<th>Task
</th>
<th>Mechanism
</th>
</tr>
<tr>
<td>A Legal Representative of the company authorises an employee to perform the process of onboarding
</td>
<td>The legal representative puts a handwritten signature in a document including the identification of the employee and describing the specific powers that the employee has: onboarding in DOME.
<p>In addition, the legal representative provides to the employee an authentic document with the Powers of Attorney proving that the signer of the previous authorisation document is a legal representative of the company.
</p>
</td>
</tr>
<tr>
<td>The authorised employee starts the onboarding process in the DOME portal
</td>
<td>The employee presents the document with the authorisation, to prove that she has the power to act on behalf of the company for the purpose of onboarding in DOME
</td>
</tr>
<tr>
<td>DOME verifies that the employee has the power to act on behalf of the company for the purpose of onboarding
</td>
<td>Verifications are manual: some employee of DOME has to perform, in a trusted manner, the following:
<ol>
<li>Verify that the document with the Powers of Attorney is authentic (probably checking in the business registry of the country of incorporation of the company).
</li>
<li>Verify that the signature in the authorisation document corresponds to the legal representative (eg. is not a picture copied from another document). This is very difficult, unless the legal representative is contacted directly by the DOME employee.
</li>
<li>Verify that the authorisation document is authentic (has not been tampered with since it was signed by the legal representative). This is very difficult, because an unsigned PDF can be modified easily.
</li>
<li>Verify that the powers inside the document are the ones required to perform onboarding in DOME.
</li>
<li>Verify that the person trying to onboard is the same identified in the authorisation document. The DOME employee has to request the national identity document of the employee and check against the authorisation document.
</li>
</ol>
<p>Once verifications are done, the DOME employee has to enable access to the DOME onboarding portal to the company employee.
</p>
</td>
</tr>
<tr>
<td>The employee completes the onboarding process in the DOME portal
</td>
<td>Filling forms in the DOME portal and uploading required additional documents
</td>
</tr>
</table>
</section>
<section id='The LEARCredential as Powers of Representation' class='appendix'><h2>The LEARCredential as Powers of Representation</h2>
<p>The LEARCredential is a machine-readable document representing a Mandate or Powers of Representation. The format used in DOME is a Verifiable Credential using an eIDAS signature to bind the mandate data with the real-world identity of the issuer of the credential.
</p>
<p>We base our design in the [[RPaM-Ontology]], which is a project started in 2018 by the Directorate-General for Informatics (DG-DIGIT) of the European Commission, funded by the ISA Programme, to organise and support the development of an ontology about the Representation of Powers and Mandates, from now on the <b>RPaM Ontology</b>.
</p>
<p>We adapt the results of that project, with simplifications and specialisations, to the concrete environment where we use the LEARCredential. To facilitate the job of the reader of this document, in some sections we copy literal sentences from the RPaM Ontology project, and adapt the texts to our requirements. However, the reader is encouraged to access the original documents for more details and understand the original approach, including the <a href="https://everis-rpam.github.io/Glossary.html">RPaM Ontology Glossary</a>.
</p>
<section id='The Mandate'><h2>The Mandate</h2>
<p>According to the RPaM Glossary, a "<i>mandate is a record that describes the terms under which a mandator grants a representation power to a mandatee</i>".
</p>
<p>The conceptual model for a <code>mandate</code> in DOME is represented below:
</p>
<div class='xcard'>
<header><b>mandate</b>
</header>
<p>The <code>mandate</code> is composed of three related objects described below: <code>mandator</code>, <code>mandatee</code> and <code>power</code>. The <code>mandate</code> object is signed with an advanced or qualified signature using an eIDAS certificate.
</p>
<div class='xcard'>
<header><b>mandator</b>
</header>
<p>The object <code>mandator</code> identifies the employee of the company who is delegating a subset of her powers on the <code>mandatee</code>.
</p>
<p>The <code>mandator</code> is either:
<ul>
<li>a legal representative of the company, according to the official records associated to the incorporation of the organisation (e.g., the business registry of the country of incorporation); or
</li>
<li>an employee who is a <code>mandatee</code> in another <code>mandate</code> where the <code>mandator</code> is a legal representative of the company. We do not support more than two levels of delegation.
</li>
</ul>
</p>
<p>In DOME, the Onboarding process requires that the <code>mandator</code> is the legal representative of the company, to ensure an appropriate level of legal certainty.
Other processes (after onboarding is completed), like creating a ProductOffering, can use any of the above options for the <code>mandator</code>, subject to the limitation of a maximum of two levels of delegation.
</p>
</div>
<div class='xcard'>
<header><b>mandatee</b>
</header>
<p>The <code>mandatee</code> is the person granted with the power to represent (and act as) the company in some specific actions with third-parties. The powers granted to the <code>mandatee</code> must be a subset of the powers of the <code>mandator</code>. For example, an employee (the <code>mandatee</code>) can be empowered by the legal representative of the company (the <code>mandator</code>) to perform the onboarding process in DOME.
</p>
<p>The object <code>mandatee</code> identifies the employee on whom a subset of powers is delegated. The <code>mandatee</code> object contains:
<ul>
<li>A set of attributes of the employee which are required by the specific use case where the LEAR Credential will be used, for example to onboard in the DOME ecosystem and for creating a ProductOffering in the marketplace. Those attributes can be considered equivalent to the fields that would be filled in a form when a "classical" PDF document would be used to authorise an employee.
</li>
<li>A public key associated to the employee and where the employee is the sole controller of the associated private key. This is required to enable the use of the LEARCredential containing the <code>mandate</code> as an efficient, scalable and secure authentication and authorisation mechanism.
</li>
</ul>
</p>
<p>The private key controlled by the employee is used to prove to Relying parties receiving the LEARCredential that the holder and presenter of the credential is the same person identified in the <code>mandatee</code> object.
We support two mechanisms for the public key in the <code>mandatee</code> object:
<ul>
<li>Using a <code>did:key</code> where the employee controls the private key associated to the <code>did:key</code>.
</li>
<li>Using an eIDAS certificate owned by the employee.
</li>
</ul>
</p>
<p>The details of how the public key is bound to the identity of the <code>mandatee</code> can be found later in this document.
</p>
</div>
<div class='xcard'>
<header><b>power</b>
</header>
<p>This object is a list of each specific power that is delegated from the <code>mandator</code> to the <code>mandatee</code>. The powers must be concrete and as constrained as possible, and must follow a taxonomy with the semantics well specified.
</p>
<p>In DOME, we have specified a power taxonomy targeted at the interactions with the DOME Federated Marketplace, supporting not only the onboarding process but also any other interaction after onboarding. The system uses the taxonomy to perform authentication and access control based on the LEARCredential presented by users. This means that the actions are well defined, homogeneous and standardised for the ecosystem. We are basically replacing the current mechanisms for Mandates (e.g., paper or PDF) with a more efficient, machine-processable representation in the form of a Verifiable Credential.
</p>
<p>Our Power Taxonomy could be generalised to other actions involving private sector companies, but it is out of scope of this version of the document.
</p>
</div>
</div>
</section>
<section id='Mapping to a Verifiable Credential'><h2>Mapping to a Verifiable Credential</h2>
<p>We now describe the mapping of the conceptual model into the concrete representation of a Mandate in a LEAR Credential, and more specifically to the <code>jwt_vc_json</code> representation (VC Signed as a JWT, Not Using JSON-LD), which is the one currently used in DOME.
</p>
<p>The <code>mandate</code> is represented in the LEAR Credential as an object inside the <code>credentialSubject</code> object. An example of a complete LEARCredential is the following:
</p>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
{
<span style="color:#000080">"@context"</span>: [
<span style="color:#d14">"https://www.w3.org/ns/credentials/v2"</span>,
<span style="color:#d14">"https://dome-marketplace.eu/2022/credentials/learcredential/v1"</span>
],
<span style="color:#000080">"id"</span>: <span style="color:#d14">"urn:did:elsi:25159389-8dd17b796ac0"</span>,
<span style="color:#000080">"type"</span>: [<span style="color:#d14">"VerifiableCredential"</span>, <span style="color:#d14">"LEARCredentialEmployee"</span>],
<span style="color:#000080">"issuer"</span>: {
<span style="color:#000080">"id"</span>: <span style="color:#d14">"did:elsi:VATES-12345678"</span>
},
<span style="color:#000080">"validFrom"</span>: <span style="color:#d14">"2024-03-22T14:00:00Z"</span>,
<span style="color:#000080">"validTo"</span>: <span style="color:#d14">"2025-03-22T14:00:00Z"</span>,
<span style="color:#000080">"credentialSubject"</span>: {
<span style="color:#000080">"mandate"</span>: {
<span style="color:#000080">"id"</span>: <span style="color:#d14">"urn:did:elsi:25159389-8dd17b796ac0"</span>,
<span style="color:#000080">"validFrom"</span>: <span style="color:#d14">"2024-03-22T14:00:00Z"</span>,
<span style="color:#000080">"validTo"</span>: <span style="color:#d14">"2025-03-22T14:00:00Z"</span>,
<span style="color:#000080">"mandator"</span>: {
<span style="color:#000080">"cn"</span>: <span style="color:#d14">"56565656V Jesus Ruiz"</span>,
<span style="color:#000080">"serialNumber"</span>: <span style="color:#d14">"56565656V"</span>,
<span style="color:#000080">"organizationIdentifier"</span>: <span style="color:#d14">"VATES-12345678"</span>,
<span style="color:#000080">"o"</span>: <span style="color:#d14">"GoodAir"</span>,
<span style="color:#000080">"c"</span>: <span style="color:#d14">"ES"</span>
},
<span style="color:#000080">"mandatee"</span>: {
<span style="color:#000080">"id"</span>: <span style="color:#d14">"did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"</span>,
<span style="color:#000080">"title"</span>: <span style="color:#d14">"Mr."</span>,
<span style="color:#000080">"first_name"</span>: <span style="color:#d14">"John"</span>,
<span style="color:#000080">"last_name"</span>: <span style="color:#d14">"Doe"</span>,
<span style="color:#000080">"email"</span>: <span style="color:#d14">"[email protected]"</span>,
<span style="color:#000080">"mobile_phone"</span>: <span style="color:#d14">"+34787426623"</span>
},
<span style="color:#000080">"power"</span>: [
{
<span style="color:#000080">"id"</span>: <span style="color:#d14">"53493323798"</span>,
<span style="color:#000080">"powerSource"</span>: <span style="color:#d14">"https://eur-lex.europa.eu/eli/reg/2014/910/oj"</span>,
<span style="color:#000080">"tmf_type"</span>: <span style="color:#d14">"Domain"</span>,
<span style="color:#000080">"tmf_domain"</span>: [<span style="color:#d14">"DOME"</span>],
<span style="color:#000080">"tmf_function"</span>: <span style="color:#d14">"Onboarding"</span>,
<span style="color:#000080">"tmf_action"</span>: [<span style="color:#d14">"Execute"</span>]
}
]
}
}
}
</pre></td></tr></table>
<section id='Mandate'><h2>Mandate</h2>
<p>In the above example, we have specified that the <code>mandator</code> (the legal representative of the company) has delegated to the <code>mandatee</code> (the employee who will be the owner of the LEAR Credential) one single power to access services in the DOME ecosystem (specified with the fields <code>tmf_type</code> and <code>tmf_name</code>) with the specific capability to perform the onboarding of the company in the DOME ecosystem (specified with the fields <code>tmf_function</code> and <code>tmf_action</code>). The actual data model, which can be used to express mor complex delegations is described below in more detail.
</p>
<p>The <code>mandate</code> has an optional <code>id</code> field which can be used to identify the Mandate when the Verifiable Credential is used to represent a Mandate which exists in other systems like a <a href="https://sede.administracion.gob.es/PAG_Sede/ServiciosElectronicos/RegistroElectronicoDeApoderamientos.html">centralised eMandate registry</a>. When the Mandate is created with the Verifiable Credential, the <code>id</code> field of the <code>mandate</code> object can be ommitted and the <code>id</code> of the credential can be used to identify the Mandate, and revoke it if needed. To maintain privacy, the <code>id</code> field should not have any relationship with the rest of the data in the Mandate.
</p>
<p>Similarly, the <code>mandate</code> has the optional fields <code>validFrom</code> and <code>validTo</code> which can be used when the credential represents a Mandate that exists externally. The typical use case is when the Mandate in the external system has a big life span and the issuer of the LEARCredential wants the credential to have a smaller life span. In any case, a Relying party receiving the LEARCredential should use the more restrictive life span when performing the verification checks. That is, it must use the biggest of the <code>validFrom</code> claims, and the smallest of the <code>validTo</code> claims.
</p>
</section>
<section id='Mandator500'><h2>Mandator</h2>
<p>There are two possible cases for the Mandator:
</p>
<ol>
<li>The Mandator is the legal representative of the company. In this case, the claims in the <code>mandator</code> object are a subset of the fields in the <code>subject</code> object in the eIDAS certificate that the legal representative uses to sign the LEARCredential. The minimum set of fields are the ones in the example.
</li>
<li>The Mandator is an employee who is the Mandatee in another LEARCredential. In this case, the data in the <code>mandator</code> object must be the same data that appears in the <code>mandatee</code> object of the related LEARCredential.
</li>
</ol>
<p>In this second case, the <code>powerSource</code> in the <code>power</code> object (see later) must be the LEARCredential which was used to delegate the powers to the <code>mandator</code> from the legal representative of the company.
</p>
</section>
<section id='Mandatee511'><h2>Mandatee</h2>
<p>The <code>mandatee</code> object contains a set of attributes of the employee which are required by the specific use case where the LEAR Credential will be used, for example to onboard in the DOME ecosystem and for creating a ProductOffering in the marketplace.
</p>
<p>In DOME, the minimum attributes are <code>title</code>, <code>first_name</code>, <code>last_name</code>, <code>email</code> and <code>mobile_phone</code>.
</p>
<p>In addition, the <code>mandatee</code> object contains a public key where the employee is the sole controller of the associated private key. There are two possible cases:
</p>
<ol>
<li>The employee wants to use her <code>did:key</code> where the employee controls the private key associated to the <code>did:key</code>. In this case, the <code>id</code> claim of the <code>mandatee</code> object is the <code>did:key</code>.
</li>
<li>The employee wants to use her personal or professional eIDAS certificate. In this case, the <code>mandatee</code> object must include two claims: the <code>id</code> claim with the <code>did:key</code> corresponding to the public key in the eIDAS certificate, and the claim <code>x5c</code> with the certificate itsef (which also incudes the public key, but we require the <code>id</code> field for completeness).
</li>
</ol>
</section>
<section id='Power'><h2>Power</h2>
<p>This object is an array where each element is a power that is delegated from the Mandator to the Mandatee. The fields of each power object are:
<ul>
<li><code>id</code>: The identifier of the power, which must be unique in the context of the Credential where it is included. It can be used as a reference when performing access control, for example in the audit records to identify the specific power that was used to grant access to some protected resource.
</li>
<li><code>powerSource</code> (conditional): The Mandator draws the power from one (or more) sources of power, e.g. 1) a concrete Legislation; 2) a piece of evidence (as another Mandate, in which case the mandator was a mandatee in that other mandate) and/or 3) a Natural Person with a specific profession that invest him/her with the authority to order to a mandator with a specific role the creation of a mandate, e.g. a judge authorising a civil servant (a <code>Mandator</code> that is a Natural Person with the appropriate role) to create a mandate for a relative to represent an incapacitated person).
<div>
<p>In DOME, there are three cases with specific sources of power:
</p>
</div>
<div>
<ol>
<li>When the Mandator is a legal representative of the company, and the LEARCredential is signed with the eIDAS certificate of representation of the legal representative. In this case, the <code>powerSource</code> claim can be ommitted as it is implicit in the eIDAS signature. Alternatively, the <code>powerSource</code> claim is an object with the following fields:
<ul>
<div>
<li><code>type</code>, with value "eulaw".
</li>
</div>
<div>
<li><code>evidence</code>, with value <code>"https://eur-lex.europa.eu/eli/reg/2014/910/oj"</code>.
</li>
</div>
</ul>
</li>
<li>When the Mandator is a natural person who is the Mandatee in another LEARCredential. The <code>powerSource</code> claim is an object with the following fields:
<ul>
<div>
<li><code>type</code>, with value "LEARCredential".
</li>
</div>
<div>
<li><code>format</code>, with the value "jwt_vc_json".
</li>
</div>
<div>
<li><code>evidence</code>, with the LEARCredential where the Mandator is a Mandatee, in <code>jwt_vc_json</code> format.
</li>
</div>
</ul>
</li>
<li>When the Mandator is a legal representative of the company, but does not have an eIDAS certificate of representation, the Mandator can not sign the LEARCredential. In this case, there must be a trusted third-party which attests that the Mandator is effectively a legal representative of the company. This trusted third-party must perform the required due diligence to confirm the relationship, and then sign the credential with its eIDAS certificate.
<div>
<p>In DOME, one of the trusted third-parties (trusted by DOME) is the DOME Operator itself, where the employees dedicated to the onboarding of participants perform the manual checks on the documentation provided by the Mandator/Mandatee, and then create and sign the LEARCredential.
</p>
</div>
<div>
<p>In this case, the <code>powerSource</code> claim is an object with the following fields:
<ul>
<li><code>type</code>, with value "attestation".
</li>
<li><code>evidence</code>, with value the eIDAS certificate of the attester.
</li>
</ul>
</p>
</div>
<div>
<p>In this case, the <code>mandate</code> object must contain an additional object called <code>attester</code>, identifying the entity that makes the attestation and with the same fields as the <code>mandator</code> object in the case where the Mandator signs the LEARCredential with an eIDAS certificate.
</p>
</div>
</li>
</ol>
</div>
</li>
<li><code>tmf_type</code>: The type of power, which can be:
<ul>
<div>
<li>"Domain": The mandatee has access to the services (subject to the restrictions defined by <code>action</code> and <code>function</code>) provided by one or more organisations where the services have been classified as belonging to that domain. The classification of services is arbitrary and defined by the service providers. A typical scenario is when some service providers agree on a classification of the services that they provide in the context of an ecosystem (like DOME), and the possible domains are made public, including the mapping to a given set of services in each provider.
</li>
</div>
<div>
<li>"Organization": The mandatee has access only to the services provided by one or more organizations, listed specifically in the power.
</li>
</div>
</ul>
</li>
<li><code>tmf_domain</code>: Required when the <code>tmf_claim</code> has the value "Domain" or "Organization". It is an array with the names of the Domains or Organisations where the Mandatee is authorised to interact with this Mandate.
<div>
<p>The names must be unique (e.g. via a namespace) to avoid potential clashes in different ecosystems.
</p>
</div>
<div>
<p>In DOME, for the powers of onboarding in DOME and for creating a <code>ProductOffering</code>, the <code>tmf_domain</code> claim must be an array with a single item "DOME".
</p>
</div>
</li>
<li><code>tmf_function</code>: A string specifying the name of the function that the Mandatee can perform. The definition of the possible functions is done by the Verifier (the entity with which the Mandatee will interact with the LEAR Credential).
<div>
<p>In DOME, the possible funcions are "Onboarding" and "ProductOffering", which enables the Mandatee to use the services provided by DOME to onboard organisations in the ecosystem and (if it is onboarded previously) to create a ProductOffering.
</p>
</div>
</li>
<li><code>tmf_action</code>: An array with the concrete actions belonging to the function that the Mandatee is allowed to execute.
<div>
<p>In DOME, the possible actions are
<ul>
<li>"Execute" when <code>tmf_function</code> is "Onboarding".
</li>
<li>Any combination of "Create", "Update" and "Delete" when <code>tmf_function</code> is "ProductOffering".
</li>
</ul>
</p>
</div>
</li>
</ul>
</p>
</section>
</section>
</section>
<section id='glossary'><h2>Glossary</h2>
<p>As far as possible and in order to enhance consistency with the regulation, we use in this document the following definitions, which is essentially a subset of the definitions in Article 3 of the document [[eIDAS2.Regulation]] and in the original [[[eIDAS.Regulation]]].
</p>
<p>This is the reason why in some definitions below the description refers to an article or section that does not exist in this document. We have decided to keep the definitions like in the original, as we think it does not limit the understanding of the concept.
</p>
<dl>
<dt id='electronic identification'>electronic identification
</dt>
<dd>means the process of using person identification data in electronic form uniquely representing either a natural or legal person, or a natural person representing a legal person;
</dd>
<dt id='electronic identification means'>electronic identification means
</dt>
<dd>means a material and/or immaterial unit, including European Digital Identity Wallets or ID cards following Regulation 2019/1157, containing person identification data and which is used for authentication for an online or offline service:
</dd>
<dt id='person identification data'>person identification data
</dt>
<dd>means a set of data, issued in accordance with national law, enabling the identity of a natural or legal person, or a natural person representing a legal person to be established;
</dd>
<dt id='electronic identification scheme'>electronic identification scheme
</dt>
<dd>means a system for electronic identification under which electronic identification means, are issued to natural or legal persons or natural persons representing legal or natural persons;
</dd>
<dt id='user'>user
</dt>
<dd>means a natural or legal person, or a natural person representing a legal person using trust services, notified electronic identification means or European Digital Identity Wallets;
</dd>
<dt id='authentication'>authentication
</dt>
<dd>means an electronic process that enables the verification of the origin and integrity of data in electronic form;
</dd>
<dt id='identification'>identification
</dt>
<dd>means an electronic process that establish an unequivocal relationship between a set of data and a natural or legal person;
</dd>
<dt id='validation'>validation
</dt>
<dd>means the process of verifying that an electronic signature, an electronic seal, a European Digital Identity Wallet, an electronic identification mean, a relying party authorisation, person identification data, an electronic attestation of attributes or any electronic certificates for trust services is valid and has not been revoked;
</dd>
<dt id='zero knowledge proof'>zero knowledge proof
</dt>
<dd>means cryptographic methods by which a relying party can validate that a given statement based on the electronic attestation of attributes held in a user's European Digital Identity Wallet is true, without conveying any data related to those electronic attestation of attributes to the relying party;
</dd>
<dt id='relying party'>relying party
</dt>
<dd>means a natural or legal person that relies upon an electronic identification means, including European Digital Identity Wallets, or a trust service, directly or through an intermediary, in order to provide services;
</dd>
<dt id='public sector body'>public sector body
</dt>
<dd>means a state, regional or local authority, a body governed by public law or an association formed by one or several such authorities or one or several such bodies governed by public law, or private entity mandated by at least one of those authorities, bodies or associations to provide public services, when acting under such a mandate;
</dd>
<dt id='body governed by public law'>body governed by public law
</dt>
<dd>means a body defined in point (4) of Article 2(1) of Directive 2014/24/EU of the European Parliament and of the Council (1);
</dd>
<dt id='signatory'>signatory
</dt>
<dd>means a natural person who creates an electronic signature;
</dd>
<dt id='electronic signature'>electronic signature
</dt>
<dd>means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign;
</dd>
<dt id='advanced electronic signature'>advanced electronic signature
</dt>
<dd>means an electronic signature which meets the requirements set out in Article 26;
</dd>
<dt id='qualified electronic signature'>qualified electronic signature
</dt>
<dd>means an advanced electronic signature that is created by a qualified electronic signature creation device, and which is based on a qualified certificate for electronic signatures;
</dd>
<dt id='electronic signature creation data'>electronic signature creation data
</dt>
<dd>means unique data which is used by the signatory to create an electronic signature;
</dd>
<dt id='certificate for electronic signature'>certificate for electronic signature
</dt>
<dd>means an electronic attestation which links electronic signature validation data to a natural person and confirms at least the name or the pseudonym of that person;
</dd>
<dt id='qualified certificate for electronic signature'>qualified certificate for electronic signature
</dt>
<dd>means a certificate for electronic signatures, that is issued by a qualified trust service provider and meets the requirements laid down in Annex I;
</dd>
<dt id='trust service'>trust service
</dt>
<dd>means an electronic service normally provided against payment which consists of:
<ul>
<li>(a) the creation, verification, and validation of electronic signatures, electronic seals or electronic time stamps, electronic registered delivery services, electronic attestation of attributes and certificates related to those services;
</li>
<li>(b) the creation, verification and validation of certificates for website authentication;
</li>
<li>(c) the preservation of electronic signatures, seals or certificates related to those services;
</li>
<li>(d) the electronic archiving of electronic documents;
</li>
<li>(e) the management of remote electronic signature and seal creation devices;
</li>
</ul>
</dd>
<dt id='qualified trust service'>qualified trust service
</dt>
<dd>means a trust service that meets the applicable requirements laid down in this Regulation;
</dd>
<dt id='conformity assessment body'>conformity assessment body
</dt>
<dd>means a body defined in point 13 of Article 2 of Regulation (EC) No 765/2008, which is accredited in accordance with that Regulation as competent to carry out conformity assessment of a qualified trust service provider and the qualified trust services it provides;
</dd>
<dt id='trust service provider'>trust service provider
</dt>
<dd>means a natural or a legal person who provides one or more trust services either as a qualified or as a non-qualified trust service provider;
</dd>
<dt id='qualified trust service provider'>qualified trust service provider
</dt>
<dd>means a trust service provider who provides one or more qualified trust services and is granted the qualified status by the supervisory body;
</dd>
<dt id='electronic seal'>electronic seal
</dt>
<dd>means data in electronic form, which is attached to or logically associated with other data in electronic form to ensure the latter’s origin and integrity;
</dd>
<dt id='advanced electronic seal'>advanced electronic seal
</dt>
<dd>means an electronic seal, which meets the requirements set out in Article 36;
</dd>
<dt id='qualified electronic seal'>qualified electronic seal
</dt>
<dd>means an advanced electronic seal, which is created by a qualified electronic seal creation device, and that is based on a qualified certificate for electronic seal;
</dd>
<dt id='electronic seal creation data'>electronic seal creation data
</dt>
<dd>means unique data, which is used by the creator of the electronic seal to create an electronic seal;
</dd>
<dt id='certificate for electronic seal'>certificate for electronic seal
</dt>
<dd>means an electronic attestation or set of attestations that links electronic seal validation data to a legal person and confirms the name of that person;
</dd>
<dt id='qualified certificate for electronic seal'>qualified certificate for electronic seal
</dt>
<dd>means a certificate for an electronic seal, that is issued by a qualified trust service provider and meets the requirements laid down in Annex III;
</dd>
<dt id='electronic seal creation device'>electronic seal creation device
</dt>
<dd>means configured software or hardware used to create an electronic seal;
</dd>
<dt id='qualified electronic seal creation device'>qualified electronic seal creation device
</dt>
<dd>means an electronic seal creation device that meets mutatis mutandis the requirements laid down in Annex II of [[eIDAS.Regulation]];
</dd>
<dt id='electronic time stamp'>electronic time stamp
</dt>
<dd>means data in electronic form which binds other data in electronic form to a particular time establishing evidence that the latter data existed at that time;
</dd>
<dt id='qualified electronic time stamp'>qualified electronic time stamp
</dt>
<dd>means an electronic time stamp which meets the requirements laid down in Article 42 of [[eIDAS.Regulation]];
</dd>
<dt id='electronic document'>electronic document
</dt>
<dd>means any content stored in electronic form, in particular text or sound, visual or audiovisual recording;
</dd>
<dt id='electronic registered delivery service'>electronic registered delivery service
</dt>
<dd>means a service that makes it possible to transmit data between third parties by electronic means and provides evidence relating to the handling of the transmitted data, including proof of sending and receiving the data, and that protects transmitted data against the risk of loss, theft, damage or any unauthorised alterations;
</dd>
<dt id='qualified electronic registered delivery service'>qualified electronic registered delivery service
</dt>
<dd>means an electronic registered delivery service which meets the requirements laid down in Article 44;
</dd>
<dt id='European Digital Identity Wallet'>European Digital Identity Wallet
</dt>
<dd>means an electronic identification means which securely stores, manages and validates identity data and electronic attestations of attributes, to provide them to relying parties and other users of European Digital Identity Wallets on request, and which enables the creation of qualified electronic signatures and seals;
</dd>
<dt id='attribute'>attribute
</dt>
<dd>is a feature, characteristic or quality of a natural or legal person or of an entity;
</dd>
<dt id='electronic attestation of attributes'>electronic attestation of attributes
</dt>
<dd>means an attestation in electronic form that allows the presentation and authentication of attributes;
</dd>
<dt id='qualified electronic attestation of attributes'>qualified electronic attestation of attributes
</dt>
<dd>means an electronic attestation of attributes, which is issued by a qualified trust service provider and meets the requirements laid down in Annex V;
</dd>
<dt id='authentic source'>authentic source
</dt>
<dd>is a repository or system, held under the responsibility of a public sector body or private entity, that contains attributes about a natural or legal person and is considered to be the primary source of that information or recognised as authentic in Union or national law;
</dd>
<dt id='electronic archiving'>electronic archiving
</dt>
<dd>means a service ensuring preservation of electronic data or documents in order to guarantee their integrity, the accuracy of their origin and legal features throughout the conservation period;
</dd>
<dt id='qualified electronic archiving service'>qualified electronic archiving service
</dt>
<dd>means a service that meets the requirements laid down in Article 45g;
</dd>