-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
3693 lines (3484 loc) · 322 KB
/
index.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>Authentication and authorization of entities acting on behalf of legal persons with Verifiable Credentials under eIDAS framework</title>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<!-- Opengraph Facebook Meta Tags -->
<meta property="og:title" content="Authentication and authorization of entities acting on behalf of legal persons with Verifiable Credentials under eIDAS framework">
<meta property="og:type" content="website">
<meta property="og:description" content="Authentication and authorization of entities acting on behalf of legal persons with Verifiable Credentials under eIDAS framework">
<meta property="og:site_name" content="Authn with Verifiable Credentials">
<meta property="og:url" content="https://DOME-Marketplace.github.io/powers-of-representation/index.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/index.html",
edDraftURI: "https://DOME-Marketplace.github.io/powers-of-representation/index.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: "9 August 2024",
href: "https://openid.net/specs/openid-4-verifiable-presentations-1_0.html",
title: "OpenID for Verifiable Presentations - draft 21",
},
"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 © 2023, 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>
<h1 id='title'>Authentication and authorization of entities acting on behalf of legal persons with Verifiable Credentials under eIDAS framework
</h1>
<h2 id='subtitle'>Implementing efficient Powers of Representation with the <code>LEAR Credential</code> and <code>did:elsi</code>
</h2>
<section id='abstract'>
<p>We describe a mechanism for efficient <b>Decentralised Identity and Access Management in B2B</b> ecosystems, enabling a high level of legal certainty, reduced manual processes and reduced dependency on third parties for the operation of the ecosystem. The mechanism uses eIDAS X.509 certificates issued by a <a href="#qualified trust service provider" class="xref">qualified trust service provider</a> (QTSP), combined with advanced or qualified signatures and seals of Verifiable Credentials, to implement an eMandate document (delegation of powers) which can be used for authentication and authorisation using the delegated powers inside the credential.
</p>
<p>The mechanism enables authentication and access control of <b>entities acting on behalf of a legal person</b> with much more descriptive power and flexibility than trying to use just X.509 certificates of representation, and in a more efficient and automated way than using just signed PDFs.
</p>
<p>The mechanism is aligned with the upcoming EDIW (European Digital Identity Wallet) and its supporting eIDAS2 regulation, but it advances the state of the art by focusing entirely on <b>legal persons</b> with an implementation that <b>can be used today without the need to wait for future supporting regulation</b>.
</p>
<p>In particular, we support natural persons acting on behalf of legal entities (e.g., employees or contractors of a business), interacting with other legal entities. The mechanism is <b>not recommended for natural persons acting as citizens</b>, even if technically the mechanism could be adapted. For citizens we recommend to wait for eIDAS2 and EDIW.
</p>
<p>The mechanism leverages Verifiable Credentials and the existing eIDAS framework by:
</p>
<ul>
<li>making the credential a <b>machine-readable e-mandate</b> by embedding authorisation information in the credential (in the form of delegation of powers) using a formal language and binding it to the identities of the issuer and subject.
</li>
<li>making the credential a <b>legally binding document</b> under the [[eIDAS]] framework, by signing the credential with an advanced or qualified seal/signature.
</li>
<li>making the credential an <b>authentication mechanism</b>, by binding the identities of the subject and holder of the credential so it can be used for authentication.
</li>
</ul>
<p>In this way, the credential is a <b>legally binding machine-readable document where the issuer attests that it delegates the set of powers specified in the credential to the user identified as the subject of the credential</b>.
</p>
<p>The subject can then <b>use the credential to authenticate to a Relying Party</b> because the identities of holder and subject of the credential are bound to the same identity.
</p>
<p>This mechanism leverages the eIDAS trust framework using advanced or qualified signatures and seals to provide a <b>high level of legal certainty and enjoying the presumption of non-repudiation in the courts</b>, something that does not happen when using other types of basic signatures.
</p>
</section>
<section id='conformance'>
</section>
<section id='Problem Statement'><h2>Problem Statement</h2>
<p>Representation powers and mandates are an essential element for businesses establishing relationships with other businesses, governments and customers, because in many cases <b>natural persons act on behalf of legal persons</b> and depending on the sensitivity of the involved data/processes the Relying Party may want to enforce a high level of legal compliance and reduce associated legal risks.
</p>
<p>Electronic powers of representation and mandates are an <b>explicit objective of the European Digital Identity Wallet</b> (EDIW) and the proposed amendment to eIDAS to support it:
</p>
<blockquote>
<p>To achieve <b>simplification and cost reduction benefits to persons and businesses across the Union, including by enabling powers of representation and e-mandates</b>, Member States should issue EDIWs relying on common standards and technical specifications to ensure seamless interoperability and to adequately increase the IT security, strengthen robustness against cyber-attacks and thus significantly reduce the potential risks of ongoing digitalisation for citizens and businesses.
</p>
<figcaption>—[[[eIDAS2.Regulation]]]
</figcaption>
</blockquote>
<p>The traditional way to solve the problem of powers of representation is by using cumbersome processes associated to onboarding and Know-Your-Customer (KYC) procedures, in many cases manual processes and paper/PDF documents that the Relying Party verifies until it is satisfied with the level of legal risk assumed when allowing a Principal to access some services on behalf of the Participant. Those setup processes are normally cumbersome, slow and people-intensive, creating a lot of friction in the initial stages of using a service, especially when strong identification is required by the nature of the service.
</p>
<p>Standard eIDAS certificates of representation can help (see an example <a href="https://eadtrust.eu/en/electronic-certificates/legal-entity-representative/">Certificate of Legal Entity Representative</a> issued by a qualified trust service provider), but they tend to be for natural persons with full powers of representation, or for very standard use cases.
</p>
<p>For a more granular specification of the powers of a natural person when acting on behalf of a legal person, other solutions have been implemented in different Member States, but they are typically centralised, non-interoperable among countries and limited to the services provided by the Public Administration. In the private sector there is not any standardised solution and basically every company does it their own way.
</p>
<p><b>Verifiable Credentials</b> can be a good instrument to implement a machine-readable and legally-binding e-mandate with much more descriptive power and flexibility than trying to use just certificates of representation, while maintaining the same level of compliance and legal risk than with traditional processes, and this is the reason why it is included in the objectives of the upcoming eIDAS2 regulation.
</p>
<p>However, currently there are important barriers that hinder the adoption of an EU-wide solution for cross-border transfer of representation information, one of the most relevant being the <b>lack of a common semantic framework</b>.
</p>
<p>Representation is complex, and electronic mandates schemes and policies are basically national and usually do not contemplate the possibility to use those mandates in cross-border scenarios. The problem of mandates when accessing services from a Public Administration is extremely complex, so <b>we focus here on the private sector</b>: when the Relying Party is a legal person from the private sector.
</p>
<p>In order to have a simple, flexible and powerful mechanism using Verifiable Credentials, the main requirements are the following:
</p>
<ul>
<li id='REQ-01_83'><b>REQ-01</b>: <b>The credential is an e-mandate</b>, by embedding authorisation information in the credential and binding it to the identities of the issuer and subject. We call such a credential a "Verifiable Authorisation".
<div>
<p>There must be a <b>controlled vocabulary</b> that can be used to express in a formal language (e.g. ODRL) the semantics of the powers delegated to a Principal by the Participant.
</p>
</div>
</li>
<li id='REQ-02_87'><b>REQ-02</b>: <b>The Relying Party does not have to know in advance the Principal</b> accessing its services on behalf of a Participant.
<div>
<p>However, the Relying Party should have an easy authentication mechanism based on Verifiable Credentials to ensure that the entity accessing the services is the same entity identified in the e-mandate, and so that it has the required powers to access the service.
</p>
</div>
<div>
<p>Ideally, to simplify the authentication and authorisation process for the Relying Party, the same credential that is a mandate (we call it a Verifiable Authorisation) can be used for authentication (we call it a VerifiableID). Of course, we could use different credentials and even a "traditional" authentication mechanism, but having a single credential that can be used both for authentication and authorisation (using the powers specified in the mandate) is what we describe here.
</p>
</div>
</li>
<li id='REQ-03_93'><b>REQ-03</b>: There may be several Principals accessing the services of a Relying Party on behalf of the same Participant, and each Principal may have different powers assigned by the Participant that enable them to access different (possibly overlapping) sets of services with different privileges.
<div>
<p>The Relying Party specifies the powers that need to be validated for each service (the scope the access is requested on, and the type of representation that the Service provider allows). Each individual service may require different sets of powers, at the sole discretion of the Relying Partly (of course always in synch with the agreement formalised with the Participant).
</p>
</div>
<div>
<p>The Participant grants the authorisations to the Principals at its own discretion. Only the Principals that have the powers required by an individual service can access that service. The Participant may have more powers than strictly required (for example, full representation of the legal entity).
</p>
</div>
</li>
<li id='REQ-04_99'><b>REQ-04</b>: The Relying Party can <b>reduce the legal risks and associated costs of litigation</b> in court by leveraging the <b>presumption of non-repudiation</b> associated to the use of an eIDAS advanced/qualified seal/signature for the Verifiable Credential.
<div>
<p>Of course, the Relying Party is free to request from Participants other types of signatures, if it is willing to assume the higher level of legal risk. We define here a mechanism which can have the same level as a document with a handwritten signature (when using qualified electronic signatures/seals).
</p>
</div>
<div>
<p>In this way the credential is a <b>legally binding machine-readable document where the issuer (Participant) attests that it delegates the set of powers specified in the credential to the user identified as the subject of the credential (Principal)</b>.
</p>
</div>
</li>
<li id='REQ-05_105'><b>REQ-05</b>: The Relying Party can verify that the issuer of the credential corresponds to a <b>real-world identity which is fully accountable</b> for the contents of the credential, without needing any additional third-party, trust framework or participant list associated to a given Data Space or Federation.
<div>
<p>Using an eIDAS signature/seal for the credential, the current EU legal and trust framework in place since 2016 is enough for the Relying Party to verify that the Participant has issued a legally-binding mandate to the Principal.
</p>
</div>
</li>
</ul>
<p>With all these properties, the credential is a <b>legally binding machine-readable document where the issuer attests that it delegates the set of powers specified in the credential to the user identified as the subject of the credential</b>. The subject can then <b>use the credential to authenticate to a Relying Party</b> because the identities of holder and subject are bound.
</p>
<p>This mechanism leverages the eIDAS trust framework using advanced or qualified signatures and seals to provide a <b>high level of legal certainty and enjoying the presumption of non-repudiation in the courts</b>, something that does not happen when using other types of basic signatures.
</p>
</section>
<section id='Introduction to Authentication and Authorization with Verifiable Credentials'><h2>Introduction to Authentication and Authorization with Verifiable Credentials</h2>
<p>In a typical B2B ecosystem, the agreements between a product/service provider and the consumer are formalised among legal persons (also known in this document as 'organisations').
</p>
<p>However, when interacting in the context of execution of the agreement, typically other entities are acting on behalf of the legal persons both for the consumer organisation and for the service provider organisation.
</p>
<p>For example, an employee of the consumer organisation may start, on behalf of his employer, an interaction with the provider organisation to perform a process needed for the procurement and provision of a service. In this case, the provider organisation should authenticate the natural person and apply appropriate access control policies to ensure that the natural person is really entitled by the consumer organisation to perform the intended process.
</p>
<p>Another example is when a device, server machine or a service controlled by the consumer organisation interacts with a service provider in an automated way (“controlled” means in this context that the device, machine or service is operating under the responsibility of the legal person). Before allowing the entity to access protected resources, the provider organisation should authenticate the entity and apply appropriate access control policies to ensure that the entity is really entitled by the consumer organisation to perform the intended process.
</p>
<p>In the context of authentication and access management, the legal person acting as consumer organisation will be named <code>Participant</code>. The digital representation of an entity acting on behalf of a Participant is referred to as a <code>Principal</code>. In Human-to-Machine (H2M) scenarios, the <code>Principal</code> is a natural person (typically an employee or contractor), while in Machine-to-Machine (M2M) scenarios the <code>Principal</code> can be a device, an application or any other automated entity without legal personality under eIDAS. However, when the context is clear and we need to refer to eIDAS legal terms, we will use the term <code>user</code> (defined in the Glossary) to denote a natural or legal person, or a natural person representing a legal person using a wallet to authenticate.
</p>
<p>The legal entity acting as service provider and performing authentication and access management will be called <code>Relying Party</code>.
</p>
<p>The approach is similar to the on-behalf-of actor model described in [[Actor-DataSpaces]] but our focus is on the compliance with the eIDAS legal framework to enable not only Data Spaces but any type of ecosystem to leverage the eIDAS trust framework and achieve a high level of legal certainty with the presumption of non-repudiation in the courts.
</p>
<p>The mechanism described here allows a Relying Party receiving a Verifiable Credential from a principal engaging in an authentication process to perform the following verifications:
</p>
<table class='deftable'>
<tr><td style='padding-left: 0px;'><b>Authentication</b></td></tr><tr><td style='padding-left: 20px;'>
<ul>
<li><b>Non-tampering</b>. The Relying Party can verify that the credential was not tampered with since it was generated, thanks to the digital signature of the credential.
</li>
<li><b>Binding the Principal with the subject inside the credential</b>. The Relying Party can verify that the principal presenting the credential is the same principal identified as the subject inside the credential by using the cryptographic material inside the credential that was embedded in a secure and private way during the credential issuance process. See section <a href="#verifiable_id" class="xref">Authentication requires a VerifiableID</a> for more details.
<div>
<p>The degree of trust in this verification depends on the degree of trust that the Relying Party puts on the processes that the Participant uses to issue the credentials.
</p>
</div>
<div>
<p>However, as described below, the usage of eIDAS signatures to sign the credential makes the Participant legally liable for any problems in the binding of the identities of the holder and subject of the credential. Specifically, compliance to the eIDAS specifications and regulation for electronic seals and signatures provides <b>presumption of non-repudiation and the burden of disputing it in the courts rests on the Participant, not on the Relying Party</b>.
</p>
</div>
<div>
<p>This is important because it provides the incentives in the proper places: the Participant is incentivised to create the credential in the proper way, and the Relying Party is incentivised to perform its due diligence in verifying the credential. By using the eIDAS signatures, no party has to assume the burden if the technical validity of the signature is disputed in court. Only the contents of the credential can be under discussion. See section <a href="#signature_benefits" class="xref">Signature of the Verifiable Credentials</a> for more details.
</p>
</div>
<div>
<p>In the mechanism described here, the verification is enabled by embedding inside the credential a public key corresponding to a private key that was generated by the principal during the issuance process. See below for the details, including an optional mechanism by embedding an existing eIDAS certificate issued by a QTSP when the principal is a natural person or a legal person (different from the Participant).
</p>
</div>
</li>
<li><b>Binding of issuer with a real-world identity</b>. The Relying Party can verify that the credential was issued by somebody controlling a private key associated to a given real-world identity.
<div>
<p>The verification is enabled because the Verifiable Credential is sealed with an eIDAS <a href="#qualified certificate for electronic seal" class="xref">qualified certificate for electronic seal</a> issued to the Participant by a <a href="#qualified trust service provider" class="xref">qualified trust service provider</a> (QTSP) in the [[[EU_Trusted_Lists]]], and the signature of the credential is an advanced or qualified electronic signature using the [[JAdES]] format (JSON Advanced Electronic Signature) as defined in the eIDAS regulation.
</p>
</div>
<div>
<p>Of course, we also support electronic signatures with qualified certificates for electronic signatures issued by QTSPs to <b>natural persons acting as representatives of legal persons</b>.
</p>
</div>
<div>
<p>This verification ensures that an organisation with a real-world legal identity under the eIDAS Trust Framework has signed the credential being presented by a natural person identified as the subject of the credential.
</p>
</div>
<div>
<p>This verification <b>does not say anything about whether the organisation is a participant</b> in a given Data Space or not. See next point for such verification.
</p>
</div>
</li>
<li><b>Verify that the real-world identity is a Participant</b>. The Relying Party, using the unique identifier in the eIDAS certificate used to sign the credential, can check if the issuer of the credential is a participant in a given ecosystem by looking for that unique identifier in the Trusted Participant List managed by that ecosystem.
<div>
<p>This unique identifier is the unique <code>organizationIdentifier</code> defined in [[[ETSI-LEGALPERSON]]], which is inside the certificates for legal persons and certificates for natural persons acting as representatives of legal persons.
</p>
</div>
<div>
<p>Any legal person that can already engage in electronic transactions in the internal market can have an eIDAS certificate including such a unique identifier, which is used in all types of legally-binding signatures like invoices, contracts, etc.
</p>
</div>
<div>
<p>We assume here that the onboarding process of each ecosystem does not invent a new "local-only" identifier but uses the one that is already valid for electronic transactions in the internal market. Or at least, that the global eIDAS unique identifier is associated with whatever private identifier is invented by the ecosystem.
</p>
</div>
<div>
<p>We assume that the eIDAS unique identifier is used during onboarding to update a given Trusted Participant List with the identity of the new participant. That identity is composed of the unique identifier in the eIDAS framework and any additional attributes that may be relevant for the ecosystem. See below for the structure of the unique eIDAS identifier.
</p>
</div>
</li>
</ul>
</td></tr>
<tr><td style='padding-left: 0px;'><b>Access Control</b></td></tr><tr><td style='padding-left: 20px;'>
<ul>
<li><b>Binding the Participant to the delegated powers to the Principal</b>. The Relying Party can verify that the legal person (the Participant) or a representative of the legal person (in eIDAS terms) has delegated a specific set of powers to the subject identified inside the credential (who is the same person holding and presenting the credential, as described above in 'authentication').
<div>
<p>This is enabled because the credential includes a <b>set of claims that state in a formal language the delegated powers</b>, and the credential has been sealed/signed using an eIDAS certificate using the eIDAS advanced/qualified electronic signature format, described in more detail later in this document.
</p>
</div>
<div>
<p>Alternatively, the credential can include a pointer to an external document (which could be another credential) describing in detail the delegated powers. In this case, the linking mechanism should provide a tamper-evident mechanism to avoid undetected modifications to the original external document, for example using [[Cryptographic Hyperlinks]].
</p>
</div>
<div>
<p>Thanks to the usage of eIDAS signatures, the credential is effectively a legal document with the same legal validity as any other document in any format supported by the eIDAS signature scheme. The Relying Party can verify (and prove in court if needed) with a high level of legal certainty that the legal person issuing the credential (the Participant) has declared that the holder/subject of the credential has the powers stated inside the credential (or linked by the credential).
</p>
</div>
<div>
<p>Actually, the entity identified as a subject in the credential, and that is receiving the delegated powers, is not restricted to be a natural person and can be of different types. Anything that can be expressed in paper or PDF format can be also expressed in the Verifiable Credential format. For example, it can be an employee, a customer or a machine or device under the responsibility of the legal person signing the credential.
</p>
</div>
</li>
<li>The Relying Party can use the claims mentioned above, expressed as a formal language (e.g. [[ODRL]]), to perform access control. The specific mechanism is not in the scope of this document.
<div>
<p>For example, the credential can just specify the role(s) of the entity identified in the credential (e.g. 'finance administrator' for an employee, 'gold customer' for a customer, 'humidity sensor' for a machine) and the Relying Party can evaluate a set of arbitrarily complex policy rules associated to the role(s) for access control.
</p>
</div>
<div>
<p>Alternatively, the credential could specify more complex rules which the Relying Party can combine if needed with additional policy rules to make the final decision.
</p>
</div>
</li>
</ul>
</td></tr>
</table>
<p>To achieve all of the above, we define specific types of Verifiable Credentials with a format and a mechanism which specify:
</p>
<ol>
<li>a way to sign the credentials;
</li>
<li>a way to bind the identity of the holder of a credential to the identity of the subject inside the credential;
</li>
<li>and a way to embed authorisation information in the credential describing the powers that the legal entity has delegated to the subject inside the credential.
</li>
</ol>
<p>The mechanisms described here can be used to generate credentials to employees, contractors, customers and even to machines and devices acting on behalf of an organisation. The schema is identical, except the issuance process is probably a little bit different and the roles and duties embedded in the credentials have different legal implications (but always in line with the legal framework, for example with the <a href="https://commission.europa.eu/law/law-topic/consumer-protection-law/consumer-contract-law/consumer-rights-directive_en#:~:text=About%20the%20directive,-The%20Consumer%20Rights&text=It%20aligns%20and%20harmonises%20national,they%20shop%20in%20the%20EU.">Consumer rights directive</a>).
</p>
<section id='signature_benefits'><h2>Signature of the Verifiable Credentials</h2>
<p>We use a <a href="#qualified certificate for electronic seal" class="xref">qualified certificate for electronic seal</a> provided by an eIDAS <a href="#qualified trust service provider" class="xref">qualified trust service provider</a> (QTSP) to seal credentials with an <a href="#advanced electronic seal" class="xref">advanced electronic seal</a> (AdESeal) or <a href="#qualified electronic seal" class="xref">qualified electronic seal</a> (QESeal) with the JSON Advanced Electronic Signature format ([[JAdES]]).
</p>
<p>We also use a <a href="#qualified certificate for electronic signature" class="xref">qualified certificate for electronic signature</a> issued by a QTSP to authorised representatives of the legal person, to sign credentials with an <a href="#advanced electronic signature" class="xref">advanced electronic signature</a> (AdES) or with a <a href="#qualified electronic signature" class="xref">qualified electronic signature</a> (QES) with the JSON Advanced Electronic Signature format (JAdES).
</p>
<p>This is described in the following figure:
</p>
<figure id='Trust Framework-Signatures2'><img class='figureshadow' src='images/eIDAS Trust Framework-Signatures2.drawio.png' alt='Signatures of JSON documents'>
<figcaption>Signatures of JSON documents</figcaption></figure>
<p>This mechanism for sealing/signing the Verifiable Credentials has the following properties:
</p>
<table class='deftable'>
<tr><td style='padding-left: 0px;'><b>Provides high assurance of the identity of the creator of the credential.</b></td></tr><tr><td style='padding-left: 20px;'>
<p>The seals/signatures provide <b>high assurance of the identity of the creator of the credential</b>. For example, it will be difficult for a malicious user to obtain a qualified seal certificate in the name of a company, because the QTSP will be responsible to check that such a seal is issued to the persons representing the company and not to unauthorised persons.
</p>
</td></tr>
<tr><td style='padding-left: 0px;'><b>Enables authorised representatives of the legal person to act on behalf of the legal person.</b></td></tr><tr><td style='padding-left: 20px;'>
<p>The mechanism provides <b>high legal predictability</b>, including for the qualified electronic signature the benefits of its <b>legal equivalence to handwritten signatures</b>.
</p>
<p>As stated by the eIDAS Regulation, when a transaction requires a qualified electronic seal from a legal person, a qualified electronic signature from the authorised representative of the legal person should be equally acceptable.
</p>
<p>It is possible to certify elements that are bound to the signatory such as a title (e.g. Director), a link with its employer, etc. Because the QTSP is trusted for verifying the information it certifies, the Relying Party can get a high level of confidence in such information conveyed with the signature through the signatory's certificate.
</p>
<p>In this way, the Relying Party receiving Verifiable Credentials can have the same legal certainty than with any other document in other formats (e.g. PDF) signed with AdES or QES signatures or with handwritten signatures (in the case of QES).
</p>
</td></tr>
<tr><td style='padding-left: 0px;'><b>Provides a high level of legal certainty and interoperability.</b></td></tr><tr><td style='padding-left: 20px;'>
<p>Any basic signature benefits from the non-discrimination rule, which means that a Court in an EU Member State cannot reject it automatically as being invalid simply because they are in electronic form.
</p>
<p>However, their dependability is lower than that of an AdES/AdESeal or QES/QESeal because the signatory may be required to prove the security of the technology being used if the validity of the signature is disputed before a court. This requires significant costs and efforts that could be avoided with relative ease by opting for the more established and standardised advanced and qualified signature solutions. It may also be the case that the relying parties have no applications or tools to validate such signature, when not based on standards; in such a scenario, the signature may be legally valid and technologically robust, but of limited use (see [[ENISA-Qualified Electronic Signatures]] and [[ENISA-Qualified Electronic Seals]]).
</p>
<p>For these interoperability reasons, QES/QESeal that are based on recognised EU standards are preferable unless the parties operate purely in a local context where the acceptance and usability of the chosen signature solution is sufficiently certain.
</p>
<p>Beyond the technical interoperability, the eIDAS Regulation also ensures the international recognition of electronic signatures, and not limited to the EU.
</p>
</td></tr>
</table>
</section>
<section id='A taxonomy of Verifiable Credentials'><h2>A taxonomy of Verifiable Credentials</h2>
<p>The objectives defined in the introduction can be achieved in different ways. We define here an approach that standardises the detailed mechanisms so it can be adopted easily by anyone who wants to obtain the associated benefits. If the approach is adopted in an ecosystem, it provides a high level of interoperability among the participants in the ecosystem, reducing also the risks associated with mistakes in the implementation.
</p>
<p>To describe precisely the approach, we define a taxonomy of the relevant classes of Verifiable Credentials that we need.
</p>
<p>For the purpose of this discussion we use a diagram derived from the taxonomy <a href="https://ec.europa.eu/digital-building-blocks/wikis/display/EBSIDOC/Data+Models+and+Schemas">defined in EBSI</a>:
</p>
<figure><img class='figureshadow' src='builtassets/plantuml_9f01927a70a78cd7d7d7cf2e5f5880d8.png' alt='Classes of credentials'>
<figcaption>Classes of credentials</figcaption></figure>
<p>And this is the chain of trust from the "Authentic sources" to the credential that the employee (for example) holds.
</p>
<figure><img class='figureshadow' src='builtassets/plantuml_dbd5762468f231440ee031c579da5bb8.png' alt='Chain of trust'>
<figcaption>Chain of trust</figcaption></figure>
<p>The sections below refer to this diagram for each type of credential discussed.
</p>
</section>
<section id='verifiable_id'><h2>Authentication requires a VerifiableID</h2>
<p>Not all types of Verifiable Credentials can be used as a mechanism for online authentication, because the Relying Party (the entity receiving the Verifiable Credential in an authentication process) needs to bind the identity of the user sending the credential to the claims attested about the subject inside the credential.
</p>
<p>For example, in the case of a Diploma as a Verifiable Credential (a Verifiable Diploma), the credential is a Verifiable Attestation which indicates that the subject has certain skills or has achieved certain learning outcomes through formal or non-formal learning context. However, as in the case with normal Diplomas in paper of PDF format, this credential can be presented by anyone that holds the credential. In other words, the credential binds the identity of the subject with the claims inside the credential, but does not bind the identity of the holder of the credential with the identity of the subject of the credential, which requires a special mechanism in the issuance process.
</p>
<p>Most Verifiable Credentials will be issued as Verifiable Attestations, acting as efficient machine-processable and verifiable equivalent to their analog counterparts. Their purpose is to attest some attributes about the subject of the credential and not act as a mechanism for online authentication.
</p>
<p>Instead, <b>a <code>VerifiableID</code> is a special form of a Verifiable Credential that a natural or legal person can use in an electronic identification process as evidence of whom he/she/it is</b> (comparable with a passport, physical IDcard, driving licence, social security card, member-card…).
</p>
<p>VerifiableIDs can be of different types and be issued by different entities with different levels of assurance (in eIDAS terminology). They are issued with the purpose of serving as authentication mechanisms in online processes. In the near future, VerifiableIDs of the highest level of assurance (LoA High) will be issued to citizens and businesses by their governments under eIDAS2.
</p>
<p>We describe in this document a way to issue VerifiableID credentials and how a Relying Party can perform authentication by accepting that credential.
</p>
</section>
<section id='Access Control requires a Verifiable Authorisation'><h2>Access Control requires a Verifiable Authorisation</h2>
<p>Once the user is authenticated, the system should make a decision to grant or reject an access request to a protected resource from an already authenticated subject, based on what the subject is authorised to access.
</p>
<p>Let's take the example of when a Service Provider signs an agreement with a Service Consumer organisation (a legal person), and the Service Provider wants to allow access to some services to employees of the Consumer organisation under the conditions of the agreement.
</p>
<p>In most cases, granting access is not an all-or-nothing decision. In general, the agreement between the Service Provider and Service Consumer specifies that only a subset of the employees of the Consumer organisation can access the services, and even in that subset not all employees have the same powers when accessing the services. For example, some employees have access to the administration of the service, some can perform some create/update/delete operations in a subset of the services, and some employees can only have read access to a subset of the services.
</p>
<p>To allow for this granularity in an authentication and access control process, in general the entity willing to perform an action on a protected resource has to present (in a Verifiable Presentation) a VerifiableID and possibly one or more additional Verifiable Attestations.
</p>
<p>At least one of the credentials should include claims identifying the employee (or any other subject) and a formal description of the concrete powers that have been delegated by the legal representative of the organisation, enabling the determination by the Service Provider whether the user is entitled to access a service and the operations that the user can perform on that service.
</p>
<p>We define later a standard mechanism and format for a Verifiable Credential that enables this functionality in a simple, secure and with high degree of legal certainty compatible with eIDAS.
</p>
<p>Such a credential is called a Verifiable Authorization, represented in the figure above.
</p>
</section>
<section id='Combining VerifiableID and Verifiable Authorisation in the LEARCredential'><h2>Combining VerifiableID and Verifiable Authorisation in the LEARCredential</h2>
<p>In many use cases, it is possible to simplify the authentication and access control by combining in a single credential both a VerifiableID (for authentication) and a Verifiable Authorisation (for access control).
</p>
<p>We call the resulting credential a LEARCredential and it is very useful when the holder/subject wants to use a decentralised IAM mechanisms implemented by Relying Parties which are federated in a decentralised way using a common Trust Anchor Framework.
</p>
<p>We repeat here the taxonomy diagram to facilitate the description of the LEARCredential.
</p>
<figure><img class='figureshadow' src='builtassets/plantuml_9f01927a70a78cd7d7d7cf2e5f5880d8.png' alt='The LEARCredential'>
<figcaption>The LEARCredential</figcaption></figure>
<p>The subject identified in the credential can authenticate to perform a protected process by using a special type of Verifiable Credential called <code>LEARCredential</code> (from <b>L</b>egal <b>E</b>ntity <b>A</b>uthorised <b>R</b>epresentation).
</p>
<p>To achieve a high level of legal certainty under eIDAS, the LEARCredential is:
</p>
<ul>
<li>signed or sealed with an eIDAS certificate which is either:
<div>
<ul>
<li>a <b>certificate for electronic seals</b> issued to a legal person by a <a href="#qualified trust service provider" class="xref">qualified trust service provider</a>, or
</li>
<li>a <b>certificate for electronic signatures</b>, issued to a <b>legal representative of the legal person</b> by a qualified trust service provider.
</li>
</ul>
</div>
</li>
<li>signed using the <b>JSON Advanced Electronic Signature</b> format described in [[[JAdES]]]
</li>
</ul>
<p>The LEARCredential includes claims identifying the subject of the credential and a description of the concrete powers that have been delegated by the legal representative of the organisation.
</p>
<p>By signing/sealing the credential with an eIDAS certificate, the legal representative attests that the powers described in the credential have been delegated to the subject (maybe under some conditions, also described in the credential).
</p>
<p>In this way, the LEARCredential has the same legal status as any other document in other formats (e.g., PDF) signed in an eIDAS-compliant way, but with all the advantages provided by the Verifiable Credential format.
</p>
<p>In addition, the LEARCredential includes cryptographic material that allows the subject of the credential to <b>use the credential as an online authentication mechanism</b> in a portal or API, by proving that the holder of the credential is the same entity identified in the credential.
</p>
<p>Any Verifier that trusts the eIDAS Trust Framework will be able to verify that:
</p>
<ul>
<li><b>The entity presenting the LEARCredential (the holder) is the same as the one identified in the subject of the credential</b>
</li>
<li><b>A legal representative of the organisation has attested that the subject has the powers described in the credential</b>
</li>
</ul>
<p>This enables the entity presenting the LEARCredential to start the process and to provide any additional required documentation as additional Verifiable Credentials to enable automatic verification of compliance with the process requirements (including Gaia-X credentials issued by the Compliance Service of Gaia-X).
</p>
<p>Both types of eIDAS certificates mentioned above are an electronic attestation <b>that links electronic seal/signature validation data to a legal person and confirms the name of that person</b>. This way, the certificate, usually linked to the sealed/signed document, can be used to verify the identity of the creator of the seal/signature and whether the document has been sealed/signed using the corresponding private key.
</p>
<p>Before issuing a certificate like the above, the qualified trust service provider (QTSP) performs validations against <code>Authentic Sources</code> to authenticate the identity of the organisation under the eIDAS framework:
</p>
<ul>
<li>The data concerning the business name or corporate name of the organisation.
</li>
<li>The data relating to the constitution and legal status of the subscriber.
</li>
<li>The data concerning the extent and validity of the powers of representation of the applicant.
</li>
<li>The data concerning the tax identification code of the organisation or equivalent code used in the country to whose legislation the subscriber is subject.
</li>
</ul>
<p>The person controlling the above certificates can authorise a subject to perform some operations on behalf of the organisation (LEAR) by generating and signing a Verifiable Credential which:
</p>
<ul>
<li>Includes identification data of a subject
</li>
<li>Includes claims stating the delegation of specific powers to perform a set of specific processes on behalf of the organisation
</li>
<li>Includes a public key where the corresponding private key is controlled by the subject, enabling the subject to prove that she/he/it is the holder of the credential when it is being used in an authentication process like the ones used as examples in this document.
</li>
</ul>
<p>The LEARCredential uses the <code>did:elsi</code> method for the identifiers of legal persons involved in the process, to facilitate the DID resolution and linkage with the eIDAS certificates. The <code>did:elsi</code> method is specified in [[[DID-ELSI]]]. But any other suitable DID method can be used if desired.
</p>
<p>The high-level view of the process is described in the following diagram, where the legal entity representative of a company appoints an employee to perform some processes with a third party (the Relying Party):
</p>
<figure><img class='figureshadow' src='builtassets/plantuml_1c84d3666027477e2d28e680104280b3.png' alt='High level view of issuance of LEARCredential to an employee'>
<figcaption>High level view of issuance of LEARCredential to an employee</figcaption></figure>
</section>
<section id='Introduction to the LEARCredential through an example'><h2>Introduction to the LEARCredential through an example</h2>
<p>In this section we describe in detail the LEARCredential and for illustrative purpose we use example attributes from a fictitious ecosystem whose participants are described in Appendix <a href="#participants" class="xref">Example scenario: DOME Marketplace</a>.
</p>
<p>In this example the LEARCredential will be generated using the eIDAS certificate of representation of the COO (Chief Operation Officer) of the organisation that will be issuing the credential (GoodAir).
</p>
<p>The credential will be generated with an application that the COO will use as Issuer of the LEARCredential and that allows the employee to receive the credential using his credential wallet, using [[OpenID.VCI]] to achieve compliance with the EDIW Wallet ARF.
</p>
<p>This application enables the COO to attest the information required to create the LEARCredential, specifying the employee information and the specific type of LEARCredential. In general, there may be different instances of LEARCredentials for different purposes. One employee can have more than one LEARCredential, each having a different delegation of powers for different environments.
</p>
<p>The specific detailed use case here is the issuance of a LEARCredential to an employee to enable that employee to perform the onboarding process in an ecosystem. But exactly the same process with different attested attributes can be used by any organisation to issue credentials that can be accepted by other organisations for authentication and access control to any protected resources that they manage.
</p>
<p>The essential components of a LEARCredential are the following:
</p>
<ul>
<li><b>Claims identifying the employee who is appointed to be a LEAR</b>
</li>
<li><b>DID of the employee to enable authentication</b>
</li>
<li><b>Claims identifying the legal representative</b>
</li>
<li><b>The specific powers delegated by the legal representative to the employee</b>
</li>
<li><b>Advanced/Qualified signature of the credential</b>
</li>
</ul>
<p>These concepts are elaborated in the following sections. To facilitate understanding of the concepts and how the LEAR Credential maps with the equivalent mechanism used today with PDFs, we use the textual documents that are used for enrolling an organisation in the <a href="https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/home">European Commission Funding & tenders</a> system. The forms we use as example are the ones required by the Commission to enable an organisation to appoint a Legal Entity Appointed Representative (LEAR). This is precisely the origin of the name we use for the LEAR Credential.
</p>
<p>However, one difference is that in the example we will generate a LEAR Credential which can be used to interact with the DOME Marketplace described in Appendix <a href="#participants" class="xref">Example scenario: DOME Marketplace</a>, instead of with the Funding & tenders portal.
</p>
<section id='Claims identifying the employee (the mandatee)'><h2>Claims identifying the employee (the mandatee)</h2>
<p>These are claims identifying the subject of the credential, the person who will act as LEAR. Each ecosystem can define their own depending on their specific requirements.
</p>
<p>In addition, each organisation can specify their own for enabling access to its products/services. However, it is recommended to use a set of claims that are agreed upon by all participants in the ecosystem unless there are specific requirements for not doing so. This includes not only the amount of claims but also their syntax and semantics.
</p>
<p>The relevant section of the document for the EU Commission Funding & tenders portal is shown here:
</p>
<figure id='lear-appointment-letter-1'><img class='figureshadow' src='images/lear-appointment-letter-1.png' alt='LEAR subject identification data.'>
<figcaption>LEAR subject identification data.</figcaption></figure>
<p>From the above form we can derive the following claims using the example data:
</p>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
<span style="color:#d14">"mandatee"</span><span style="color:#a61717;background-color:#e3d2d2">:</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">"gender"</span>: <span style="color:#d14">"M"</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>
}
</pre></td></tr></table>
</section>
<section id='DID of the employee'><h2>DID of the employee</h2>
<p>In this example we use the <code>did:key</code> method for the DID of the employee, which provides a very high level of privacy and given the way the LEARCredential is generated it supports the verification of the chain of responsibility with a proper level of guarantee.
</p>
<p>If the highest levels of assurance and legal compliance are desired and the employee has an eIDAS certificate for signatures (in this case a personal one would be enough, not one like the COO), we could use the <code>elsi:did</code> method for identification of the employee. However, the organisation (GoodAir in our example) should make sure that the employee is aware of and agree to the possible privacy implications of doing so, given the personal details leaked from the eIDAS certificate. In any case, if the business interactions the the employee will perform already require some personal details to be in the LEAR Credential (as in the example with the EU Commission used here), using an eIDAS personal certificate of the employee should not be a problem. However, we keep using the <code>did:key</code> identifier for the employee, to show how the system can work with it and ensure complete privacy if required.
</p>
<p>Those personal details are exactly the same as if the employee signs any document with a digital certificate, but care should be taken by the organisation because in this case the signature would be done "on behalf of" his employer and not as an individual personal action.
</p>
<p>Even though this is not unique to the <code>did:elsi</code> method, this also implies that the onboarding service has to handle those personal details in the same way as if it would be accepting any other document signed with a certificate for signatures, and ensure compliance with GDPR. This is "business as usual" when using digital signatures, but we want to make sure that this is taken care of when implementing the authentication and access control mechanisms described in this document.
</p>
<p>This DID for the employee is an additional claim to the ones presented above, using the <code>id</code> field in the <code>credentialSubject</code> object.
</p>
<p>Using this DID method has an additional advantage: the DID identifier corresponds to a keypair that is generated during the LEARCredential issuance process, where the private key is generated by the wallet of the employee and it is always under his control.
</p>
<p>This private key controlled by the employee can be used to sign challenges from Relying Parties that receive the credential to prove that the person sending the credential is the same person that is identified in the <code>credentialSubject</code> object of the LEARCredential.
</p>
<p>It is this property that makes this credential a VerifiableID that can be used for online authentication.
</p>
<p>An example DID for the employee could be:
</p>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
{
<span style="color:#000080">"id"</span>: <span style="color:#d14">"did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"</span>
}
</pre></td></tr></table>
<p>In this example, the signatures performed with the private key can not be JAdES-compliant ([[JAdES]]), but if the LEARCredential is attached to any other credential that is signed with this private key, then they can be traced up to the eIDAS certificate of the COO and so the chain of responsibility can be determined, up to the root of trust which is the identity of the trust service used by the QTSP that issued the eIDAS certificate of the COO of the company.
</p>
<p>With the DID for the employee, the set of claims identifying him would be then:
</p>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
<span style="color:#d14">"mandatee"</span><span style="color:#a61717;background-color:#e3d2d2">:</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">"gender"</span>: <span style="color:#d14">"M"</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>
}
</pre></td></tr></table>
</section>
<section id='legalRepresentative (the mandator)'><h2>legalRepresentative (the mandator)</h2>
<p>This section identifies the natural person (the COO of GoodAir in our example) who is a legal representative of the legal person (GoodAir) and that is nominating the employee identified in the credential.
</p>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
<span style="color:#d14">"mandator"</span><span style="color:#a61717;background-color:#e3d2d2">:</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>
}
</pre></td></tr></table>
<table style='width:100%;margin:1em 0;'><tr><td class='xnotet'><aside class='xnotea'><p class='xnotep'>NOTE: Attributes for natural and legal persons</p>
<p>The attributes for natural persons and legal persons are derived from the <a href="https://ec.europa.eu/digital-building-blocks/wikis/download/attachments/467109280/eidas_saml_attribute_profile_v1.0_2.pdf?version=1&modificationDate=1639417533738&api=v2">eIDAS SAML Attribute Profile (eIDAS Technical Sub-group, 22 June 2015)</a>.
</p>
<p>All attributes for the eIDAS minimum data sets can be derived from the <a href="https://ec.europa.eu/isa2/solutions/core-vocabularies_en/">ISA Core Vocabulary</a> and <a href="https://joinup.ec.europa.eu/collection/semic-support-centre/specifications">https://joinup.ec.europa.eu/collection/semic-support-centre/specifications</a>.
</p>
<p>In the case of natural persons refer to the <a href="https://joinup.ec.europa.eu/asset/core_person/asset_release/core-person-vocabulary">Core Person Vocabulary</a> and in the case of legal persons refer to definitions for <a href="https://joinup.ec.europa.eu/asset/core_business/asset_release/core-business-vocabulary">Core Business Vocabulary</a>.
</p>
</aside></td></tr></table>
</section>
<section id='Roles and Duties of the LEAR: the powers of representation'><h2>Roles and Duties of the LEAR: the powers of representation</h2>
<p>The LEARCredential should include a formal description with specific powers that are delegated by the legal representative (mandator) to the employee (mandatee). In the example with the LEAR for the EU Funding & tenders portal, it corresponds to the roles and duties of the LEAR. The analog description in our example, which uses natural language is:
</p>
<figure id='lear-appointment-letter-2'>
<p><img src="images/lear-appointment-letter-2.png" alt="" />
</p>
<figcaption>LEAR roles and duties.
</figcaption>
</figure>
<p>When we translate this section to a formal language to represent powers of representation, the object inside the credential could be:
</p>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
<span style="color:#d14">"mandate"</span><span style="color:#a61717;background-color:#e3d2d2">:</span> {
<span style="color:#000080">"id"</span>: <span style="color:#d14">"bb1482e1-0513-4c90-9c80-98a2e4d14984"</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">"gender"</span>: <span style="color:#d14">"M"</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">"tmf_type"</span>: <span style="color:#d14">"Domain"</span>,
<span style="color:#000080">"tmf_name"</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">"Process"</span>]
}
],
<span style="color:#000080">"lifeSpan"</span>: {
<span style="color:#000080">"startDateTime"</span>: <span style="color:#d14">"2023-10-01"</span>,
<span style="color:#000080">"endDateTime"</span>: <span style="color:#d14">"2025-10-01"</span>
}
}
</pre></td></tr></table>
<p>In the above example, we have specified that the <code>mandator</code> (the legal representative) has delegated to the <code>mandatee</code> (the employee) one single power to access services in the DOME ecosystem (specified with the fields <code>type</code> and <code>name</code>) with the specific capability to perform the onboarding of the company in the DOME ecosystem (specified with the fields <code>function</code>and <code>action</code>). The actual data model, which can be used to express mor complex delegations is described in more detail in another section of the document.
</p>
</section>
<section id='Assembling the pieces together'><h2>Assembling the pieces together</h2>
<p>With the above values for the example, the complete LEARCredential would become something like this:
</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">"issuanceDate"</span>: <span style="color:#d14">"2024-03-22T14:00:00Z"</span>,
<span style="color:#000080">"validFrom"</span>: <span style="color:#d14">"2024-03-22T14:00:00Z"</span>,
<span style="color:#000080">"expirationDate"</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">"bb1482e1-0513-4c90-9c80-98a2e4d14984"</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">"gender"</span>: <span style="color:#d14">"M"</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">"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">"Process"</span>]
}
],
<span style="color:#000080">"lifeSpan"</span>: {
<span style="color:#000080">"startDateTime"</span>: <span style="color:#d14">"2024-03-22T14:00:00Z"</span>,
<span style="color:#000080">"endDateTime"</span>: <span style="color:#d14">"2025-03-22T14:00:00Z"</span>
}
}
}
}
</pre></td></tr></table>
</section>
</section>
</section>
<section id='Authenticating with Verifiable Credentials'><h2>Authenticating with Verifiable Credentials</h2>
<p>We focus here on how to perform authentication using Verifiable Credentials. Access control is the subject of another section.
</p>
<p>Authentication requires a special type of Verifiable Credential called a <code>VerifiableID</code>. For the examples illustrating the mechanism we will use a LEARCredential, which is at the same time a <code>VerifiableID</code> and a <code>Verifiable Authorization</code>. The LEARCredential is a powerful mechanism that can be used both for authentication and sophisticated access control. In this section we will focus only on authentication using the LEARCredential.
</p>
<p>To make the description concrete and more understandable, we describe how the system works in DOME. But the system is general enough to be used in any other environment with similar requirements.
</p>
<p>The authentication mechanism supports both Human-To-Machine (H2M) and Machine-To-Machine (M2M) flows, which are described in the next sections.
</p>
<section id='Authentication in Human-To-Machine scenarios'><h2>Authentication in Human-To-Machine scenarios</h2>
<p>For completeness, the figure below describes at a high level how both H2M and M2M flows work. This section describes the H2M flow and M2M is described in the next.
</p>
<figure id='fig-authentication-overview'><img class='figureshadow' src='images/authentication/DOMEAuthentication-Authentication-flow-overview.drawio.png' alt='Authentication overview'>
<figcaption>Authentication overview</figcaption></figure>
<p>For the explanation, we will asume that there is a user who wants to interact with a web Application using her Internet browser in her PC/Laptop. The user has a VerifiableID (the LEARCredential) in her EUDI-compatible Wallet, and the application has integrated the mechanism provided by DOME to authenticate with Verifiable Credentials (if they are a VerifiableID, as explained above in this document).
</p>
<p>DOME provides a component (the VCVerifier), which makes very easy for applications to integrate authentication with Verifiable Credentials. If the application programmer knows how to use <a href="https://en.wikipedia.org/wiki/Social_login">Social Login</a>, then she already knows who to integrate authentication with Verifiable Credentials.
</p>
<p>For the Application, the VCVerifier is just an OpenID Provider (OP), connecting to it using the standard <a href="https://openid.net/developers/how-connect-works/">OpenID Connect</a> protocol.
</p>
<p>The Application is an OIDC Relying Party requiring End-User Authentication and Claims from the VCVerifier (we will see later how exactly). The Application does not need any knowledge about how to talk to the Wallet to receive the Verifiable Credential from the user. This complexity is hidden from the application by the VCVerifier.
</p>
<p>Once the Verifier has successfully authenticated the user and received the Verifiable Credential from her Wallet, it returns to the Application (using the standard OpenID Connect protocol) both the Verifiable Credential and an Access Token that the Application can use to access protected resources as in any other OpenID Connect flow.
</p>
<p>The Application receives the Verifiable Credential as a claim (JSON object) via the flows of OpenID Connect, so the only knowledge that the Application needs is the structure of the Verifiable Credential, to be able to use the information inside to know who is the authenticated user and the powers of that user. This is no different from using the "Login with Google" or "Login with Facebook" buttons, where the Application needs to know the structure of the claims that it received from those OpenId Providers.
</p>
<p>The following sections provide more details on the flows.
</p>
<section id='start_authentication'><h2>Starting the authentication process</h2>
<p>The user interacts with the web interface of the Application, and at some point the Application wants to authenticate the user so it presents a "Login" button, to authenticate with a Verifiable Credential which in our case will be a LEARCredential issued to the user. This authentication mechanism can coexist with other mechanisms, if the application implementer wants.
</p>
<p>We will use interchangeable the terms Relying Party and Application, because in this context the Application adopts the role of OIDC Relaying Party.
</p>
<p>When the user clicks the "Login" button, the application redirects the user to the VCVerifier, which will authenticate the user and request the LEARCredential. The Relying Party tells the VCVerifier which is the concrete Verifiable Credential that is requesting via the <code>scope</code> parameter of the OIDC Authentication Request that is sent to the VCVerifier.
</p>
<p>The VCVerifier then starts an OpenID for Verifiable Presentations flow [[OpenID.VP]] with the Wallet of the user. In this context, the VCVerifier acts as a Relying Party and the Wallet as an OpenID Provider.
</p>
<p>In other words, the VCVerifier has internally two components with different roles, depending on who is the other party:
<ul>
<li>When talking with the Application, the VCVerifier is an OpenID Provider and the Application is a Relying Party.
</li>
<li>When talking with the Wallet, the VCVerifier is a Relying Party and the Wallet is an OpenID Provider.
</li>
</ul>
</p>
<p>In this way, the VCVerifier hides much of the complexity for both the Application and the Wallet in real-world authentication scenarios.
</p>
<p>The detailed flow is as follows.
</p>
<figure><img class='figureshadow' src='builtassets/plantuml_27c9e158e03f77bb97fb91f683065918.png' alt='Starting the authentication phase'>
<figcaption>Starting the authentication phase</figcaption></figure>
<ul class='plain'>
<li id='1_766'><b>1</b> The User navigates with her Laptop/PC browser to access the web interface of the Application (we will call it the "portal" from now on).
<div>
<p>We assume in this scenario a cross-device interaction, that is, the user accesses the portal services with a PC browser, but authentication is performed with a mobile using Verifiable Credentials, as in typical 2-factor authentication.
</p>
</div>
</li>
<li id='2_770'><b>2</b> The browser sends a request to the portal web server.
</li>
<li id='3_772'><b>3</b> The portal sends an Authentication Request to the authorization endpoint of the VCVerifier by redirecting the user to the corresponding page of the VCVerifier.
<div>
<p>The Authentication Request MUST use the Authorization Code Flow, which means that all tokens (including the claims of the Verifiable Credential) are returned from the Token Endpoint.
</p>
</div>
<div>
<p>The Authorization Code Flow returns an Authorization Code to the Client, which can then exchange it for an ID Token and an Access Token directly. The VCVerifier MUST authenticate the Client before exchanging the Authorization Code for an Access Token.
</p>
</div>
<div>
<p>The Authorization Request MUST be signed by the Client, and MUST use the <code>request_uri</code> parameter which enables the request to be passed by reference, as described in section <a href="https://openid.net/specs/openid-connect-core-1_0.html#RequestUriParameter">6.2. Passing a Request Object by Reference</a> of the OpenID Connect spec.
</p>
</div>
<div>
<p>The <code>request_uri</code> value is a URL referencing a resource containing a Request Object value, which is a JWT containing the request parameters. This URL MUST use the https scheme.
</p>
</div>
<div>
<p>The following is an example HTTP 302 redirect response by the Client, which triggers the browser of the user to make an Authentication Request to the Authorization Endpoint of the VCVerifier (with line wraps within values for display purposes only).
</p>
</div>
<div>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
HTTP/1.1 302 Found
Location: https://verifier.dome-marketplace.org/authorize?
response_type=code
&client_id=did:key:wejkdew87fwhef9833f4
&request_uri=https%3A%2F%2Fdome-marketplace.org%2Fapi%2Fv1%2Frequest.jwt
%23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj
&scope=openid%20learcred
</pre></td></tr></table>
</div>
<div>
<p>Note in the above Authentication Request the following:
<ul>
<li><code>client_id</code> MUST be the <code>did</code> assigned to the Client machine, either during configuration of the DOME infrastructure (e.g., the BAE Marketplace or the Ticketing system), or during onboarding of the CSP (one of the machines of the CSP).
</li>
<li><code>scope</code> MUST include <code>learcredential</code> in addition to the required <code>openid</code>, so the VCVerifier knows that it has to request the LEARCredential from the Wallet. Other scopes can be defined for requesting other credentials, but this is out of scope of this document. To request a LEARCredential, the <code>scope</code> parameter MUST have the value "<code>openid learcredential</code>".
</li>
</ul>
</p>
</div>
</li>
<li id='4_799'><b>4</b> At this point, the VCVerifier knows that it has to request a LEARCredential from the Wallet. Until now, the VCVerifier was acting as an OpenID Provider/Authorization Server for the Client. To talk to the Wallet, the VCVerifier has to use the OpenID for Verifiable Presentations (OID4VP) protocol, where the VCVerifier acts as a Client.
<div>
<p>According to the OID4VP spec, the VCVerifier has to send an Authorization Request to the Wallet. This request should not be confused with the Authorization Request that the Application sent to the VCVerifier, even if they have the same name. Both are Authentications Requests, but in different contexts. They are related (the end result is to obtain a Verifiable Credential for the Application), but they are used between different components of the system.
</p>
</div>
<div>
<p>The VCVerifier MUST use the flow defined in section <a href="https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-3.2">3.2. Cross Device Flow</a> of the OID4VP spec, using a QR Code for the Authorization Request.
</p>
</div>
<div>
<p>In particular, in order to keep the size of the QR Code small and be able to sign the Request Object, the actual Authorization Request MUST contain just a Request URI according to [RFC9101], which the wallet uses to retrieve the actual Authorization Request data.
</p>
</div>
<div>
<p>The following is an example of an Authorization Request which refers to the Authorization Request Object through the request_uri parameter. The Authorization Request is displayed displayed to the End-User as a QR Code
</p>
</div>
<div>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
openid4vp://?client_id=https%3A%2F%2Fverifier.dome-marketplace.org
&request_uri=https%3A%2F%2Fverifier.dome-marketplace.org%2fauth_request%2F567545564
</pre></td></tr></table>
</div>
</li>
<li id='5_813'><b>5</b> The QR code is displayed in the user browser with instructions to scan it and go to the URL inside it.
<div>
<figure id='qr_code_authreq'>
<p><img src="images/qrcode-authreq2.png" alt="" />
</p>
<figcaption>Example of the DOME Marketplace login screen
</figcaption>
</figure>
</div>
</li>
<li id='6_821'><b>6</b> The user scans the QR with her wallet and tells the wallet to go to the URL in the QR.
</li>