-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathauthn.html
2319 lines (2168 loc) · 202 KB
/
authn.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://alastria.github.io/did-method-elsi/authn.html">
<script src="https://www.w3.org/Tools/respec/respec-w3c" async="" class="remove"></script>
<script class="remove">
var respecConfig = {
latestVersion: "https://alastria.github.io/did-method-elsi/authn.html",
edDraftURI: "https://alastria.github.io/did-method-elsi/authn.html",
github: "https://github.com/alastria/did-method-elsi/blob/main/authn.html",
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",
},
"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: "04 June 2023",
href: "https://alastria.github.io/did-method-elsi/",
title: "DID ETSI Legal person Semantic Identifier Method Specification (did:elsi)",
},
"DID-ONBOARDING": {
date: "04 June 2023",
href: "https://alastria.github.io/did-method-elsi/onboarding.html",
title: "Onboarding example with LEARCredential using 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",
},
"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: "3 February 2023",
href: "https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html",
title: "OpenID for Verifiable Credential Issuance",
},
"OpenID.VP": {
date: "21 April 2023",
href: "https://openid.net/specs/openid-4-verifiable-presentations-1_0.html",
title: "OpenID for Verifiable Presentations",
},
"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",
},
"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 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>We describe a mechanism enabling <b>Decentralised Identity and Access Management in B2B</b> ecosystems which require a high level of legal certainty, reduced manual processes and reduced dependency in third parties for the operation of the ecosystem. It combines eIDAS X.509 certificates issued by QTSPs with advanced or qualified signatures and seals of Verifiable Credentials.
</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 can be used today without the need to wait for future supporting regulation.
</p>
<p>The mechanism is <b>not recommended for natural persons</b>, even if technically could be adapted. For natural persons 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 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 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='conformance'>
</section>
<section id='Authentication and Authorization with Verifiable Credentials'><h2>Authentication and Authorization with Verifiable Credentials</h2>
<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 this 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 QTSP <a href="https://eadtrust.eu/en/electronic-certificates/legal-entity-representative/">Certificate of Legal Entity Representative</a>), but they tend to be for natural persons with full powers 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 typically centralised, non-interoperable among them 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 become 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, being one of the most relevant 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 will focus here on the private sector</b>: when both the Relying Party and the Participant are legal persons 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'><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".
<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>
</li>
<li id='REQ-02'><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.
<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.
</p>
<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 enable 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>
</li>
<li id='REQ-03'><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 that enable them to access different (possibly overlapping) sets of services.
<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>
<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>
</li>
<li id='REQ-04'><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.
<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>
<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>
</li>
<li id='REQ-05'><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.
<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>
</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'><h2>Introduction</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 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>In the context of authentication and access management, the legal entity acting as consumer organisation will be named <code>Participant</code>. The digital representation of a natural person, acting on behalf of a Participant, is referred to as a <code>Principal</code>. 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 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 seal</b>. For example, it will be difficult for a malicious user to get 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 src='builtassets/plantuml_47747c7c84b49ce4c8b0f3159b566ffc.png' alt=''>
<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 src='builtassets/plantuml_e4338e4c75a470db448bc8cde251a4ee.png' alt=''>
<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 src='builtassets/plantuml_47747c7c84b49ce4c8b0f3159b566ffc.png' alt=''>
<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 is desired.
</p>
<p>The high-level view of the process is described in the following diagram, using as an example a COO (Chief Operating Officer) acting a legal entity representative and appointing an employee to perform some processes:
</p>
<figure><img src='builtassets/plantuml_53418b3092cb323db978af09dc064024.png' alt=''>
<figcaption>High level view of issuance of LEARCredential to an employee</figcaption></figure>
</section>
</section>
<section id='The LEARCredential through an example'><h2>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: Participants in the ecosystem</a>.
</p>
<p>In this example the LEARCredential will be generated using the eIDAS certificate of the COO (Chief Operation Officer) of the organisation that will be issuing the credential.
</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 EUDI 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</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 roles and duties of the LEAR</b>
</li>
<li><b>Advanced/Qualified signature of the credential</b>
</li>
</ul>
<p>These concepts are elaborated in the following sections.
</p>
<section id='Claims identifying the employee'><h2>Claims identifying the employee</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>For our example, we use the same that are used for accessing the European Commission portal. The claims in the credential are the digital equivalent of their analog counterparts, displayed here for illustration.
</p>
<figure id='lear-appointment-letter-1'>
<p><img src="images/lear-appointment-letter-1.png" alt="" />
</p>
<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:#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">"postal_address"</span>: <span style="color:#d14">""</span>,
<span style="color:#000080">"email"</span>: <span style="color:#d14">"[email protected]"</span>,
<span style="color:#000080">"telephone"</span>: <span style="color:#d14">""</span>,
<span style="color:#000080">"fax"</span>: <span style="color:#d14">""</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, 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.
</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 here.
</p>
<p>In this example we assume the usage of the <code>did:key</code> method for the employee to protect his privacy as much as possible.
</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..
</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:#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">"postal_address"</span>: <span style="color:#d14">""</span>,
<span style="color:#000080">"email"</span>: <span style="color:#d14">"[email protected]"</span>,
<span style="color:#000080">"telephone"</span>: <span style="color:#d14">""</span>,
<span style="color:#000080">"fax"</span>: <span style="color:#d14">""</span>,
<span style="color:#000080">"mobile_phone"</span>: <span style="color:#d14">"+34787426623"</span>
}
</pre></td></tr></table>
</section>
<section id='legalRepresentative'><h2>legalRepresentative</h2>
<p>This section identifies the natural person (the COO) 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">"legalRepresentative"</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%;'><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'><h2>Roles and Duties of the LEAR</h2>
<p>The LEARCredential should include a formal description with the roles and duties of the LEAR. This is the digital equivalent to the analog description in our example, which uses natural language:
</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>
<table style='width:100%;'><tr><td class='xnotet'><aside class='xnotea'>
<p>We do not yet have defined the actual mechanism that will be used for describing formally the roles and duties of the LEAR. The way we specify them below is just an example. There is work ongoing to define the detailed mechanism formally (e.g. with ODRL), and it is expected to change. This example is intended only to describe the concepts in detail.
</p>
</aside></td></tr></table>
<p>The <code>rolesAndDuties</code> object points to an externally hosted object with the roles and duties of the LEAR. This external object can be either a machine-interpretable definition of the roles and duties in the credential, or just an external definition of the roles and duties in natural language. The ideal approach is the first option, expressing the semantics with a proper machine-readable language, because this will allow automatic access control at the granularity of the individual sentences of that expression language. The <code>rolesAndDuties</code> object can also have the definition embedded into it, instead of having a pointer to an external object.
</p>
<p>A simplistic implementation of the object inside the credential could be:
</p>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
<span style="color:#d14">"rolesAndDuties"</span><span style="color:#a61717;background-color:#e3d2d2">:</span> [
{
<span style="color:#000080">"type"</span>: <span style="color:#d14">"LEARCredential"</span>,
<span style="color:#000080">"id"</span>: <span style="color:#d14">"https://dome-marketplace.eu//lear/v1/6484994n4r9e990494"</span>
}
]
</pre></td></tr></table>
<p>Where the last part of the url can correspond to the hash of the external linked document to ensure that any modification or tampering can be detected. The contents of that object ata that url 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">"https://dome-marketplace.eu//lear/v1/6484994n4r9e990494"</span>,
<span style="color:#000080">"target"</span>:<span style="color:#d14">"https://bae.dome-marketplace.eu/"</span>
<span style="color:#d14">"roleNames"</span>: [<span style="color:#d14">"seller"</span>, <span style="color:#d14">"customer"</span>]
}
]
</pre></td></tr></table>
<p>In the above example, we have specified that the roles object referenced in the credential with <code>id: https://dome-marketplace.eu//lear/v1/6484994n4r9e990494</code> is granting the employee of GoodAir (in our example) to access services in the DOME marketplace (specified with the field <code>target</code>) with the roles <code>seller</code> and <code>customer</code> (which are the roles of the <a href="https://business-api-ecosystem.readthedocs.io/en/latest/index.html">FIWARE BAE component</a>).
</p>
<p>If <code>target</code> is omitted, the roles would apply to any target organisation. If we need to specify more than one target organisation, the array should include as many objects as required.
</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/2018/credentials/v1"</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">"LEARCredential"</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">"2022-03-22T14:00:00Z"</span>,
<span style="color:#000080">"validFrom"</span>: <span style="color:#d14">"2022-03-22T14:00:00Z"</span>,
<span style="color:#000080">"expirationDate"</span>: <span style="color:#d14">"2023-03-22T14:00:00Z"</span>,
<span style="color:#000080">"credentialSubject"</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">"postal_address"</span>: <span style="color:#d14">""</span>,
<span style="color:#000080">"email"</span>: <span style="color:#d14">"[email protected]"</span>,
<span style="color:#000080">"telephone"</span>: <span style="color:#d14">""</span>,
<span style="color:#000080">"fax"</span>: <span style="color:#d14">""</span>,
<span style="color:#000080">"mobile_phone"</span>: <span style="color:#d14">"+34787426623"</span>,
<span style="color:#000080">"legalRepresentative"</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">"rolesAndDuties"</span>: [
{
<span style="color:#000080">"type"</span>: <span style="color:#d14">"LEARCredential"</span>,
<span style="color:#000080">"id"</span>: <span style="color:#d14">"https://dome-marketplace.eu//lear/v1/6484994n4r9e990494"</span>
}
]
}
}
</pre></td></tr></table>
</section>
</section>
<section id='Issuing the LEARCredential'><h2>Issuing the LEARCredential</h2>
<section id='Overview'><h2>Overview</h2>
<p>In this example we use what we call a <i>profile</i> of the [[OpenID.VCI]] protocol. The standard is very flexible, and we restrict the different options available in the standard and implement a set of the options with given values that are adequate for our use case, without impacting flexibility in practice.
</p>
<p>The following figure describes the main components that interact in the issuance of a credential in this profile.
</p>
<p>The description of the issuance process is general enough to be used for many types of credentials, but the text includes notes describing the concrete application of the process to the case of the LEARCredential.
</p>
<figure id='iss-overview'>
<p><img src="images/issuance/issuance_background.svg" alt="" />
</p>
<figcaption>Overview of participants.
</figcaption>
</figure>
<p><b>End user</b>
</p>
<p>This profile is valid for both natural and juridical persons, but because we are focusing on the issuance of the LEARCredential, in the detailed examples below we assume a natural person as the user.
</p>
<p><b>Wallet</b>
</p>
<p>The wallet is assumed to be a Web application with a wallet backend, maybe implemented as a PWA so it has some offline capabilities and can be installed in the device, providing a user experience similar to a native application. Private key management and most sensitive operations are performed in a backend server, operated by an entity trusted by the end user. Other profiles can support native and completely offline PWA mobile applications, for end users.
</p>
<p>This type of wallet supports natural persons, juridical persons and natural persons who are legal entity representatives of juridical persons. For juridical persons the wallet is usually called an <code>enterprise wallet</code> but we will use here just the term <code>wallet</code> unless the distinction is required.
</p>
<p>In this profile we assume that the wallet is not previously registered with the Issuer and that the wallet does not expose public endpoints that are called by the Issuer, even if the wallet has a backend server that could implement those endpoints. That makes the wallet implementations in this profile to be very similar in interactions to a full mobile implementation, making migration to a full mobile implementation easier.
</p>
<p>In other words, from the point of view of the Issuer, the wallet in this profile is almost indistinguishable from a full mobile wallet.
</p>
<p><b>User Laptop</b>
</p>
<p>For clarity of exposition, we assume in this profile that the End User starts the interactions with the Issuer with an internet browser (user agent) in her laptop. However, there is nothing in the interactions which limits those interactions to a laptop form factor and the End User can interact with any internet browser in any device (mobile, tablet, kiosk).
</p>
<p><b>Issuer</b>
</p>
<p>In this profile we assume that the Issuer is composed of two components:
</p>
<ul>
<li><b>Authorization server</b>: the backend component implementing the existing authentication/authorization functionalities for the Issuer entity.
</li>
<li><b>Issuer backend</b>: the main server implementing the business logic as a web application and additional backend APIs required for issuance of credentials.
</li>
</ul>
<p>The Issuer backend and the Authorization server could be implemented as a single component in an actual deployment, but we assume here that they are separated to make the profile more general, especially for big entities and also when using Trust Service Providers for cloud signature and credential issuance, for example.
</p>
<p><b>Authentication of End User and previous Issuer-End User relationship</b>
</p>
<p>We assume that the Issuer and End User have a previous relationship and that the Issuer has performed the KYC required by regulation and needed to be able to issue Verifiable Credentials attesting some attributes about the End User. We assume that there is an existing trusted authentication mechanism (not necessarily related to Verifiable Credentials) that the End User employs to access protected resources from the Issuer. For example, the user is an employee or a customer of the Issuer, or the Issuer is a Local Administration and the End User is a citizen living in that city.
</p>
</section>
<section id='Authentication'><h2>Authentication</h2>
<figure id='iss-authentication'>
<p><img src="images/issuance/issuance_authentication.svg" alt="" />
</p>
<figcaption>Issuance authentication.
</figcaption>
</figure>
<p>Before requesting a new credential, the End User has to authenticate with the Issuer with whatever mechanism is already implemented by the Issuer. This profile does not require that it is based on OIDC, Verifiable Credentials or any other specific mechanism.
</p>
<p>The level of assurance (LoA) of this authentication mechanism is one of the factors that will determine the confidence that the Verifiers can have on the credentials received by them from a given Issuer.
</p>
<table style='width:100%;'><tr><td class='xnotet'><aside class='xnotea'><p class='xnotep'>NOTE: LEARCredential</p>
<p>In the case of the LEARCredential, the End User (John Doe) is an employee of GoodAir and in order to receive the credential John first has to authenticate into the company systems using whatever mechanism GoodAir uses for employee authentication.
</p>
<p>Being a modern company, GoodAir uses Verifiable Credentials IAM but this is not a requirement for the issuance of the LEARCredential.
</p>
</aside></td></tr></table>
</section>
<section id='Credential Offer'><h2>Credential Offer</h2>
<figure id='iss-credentialoffer'>
<p><img src="images/issuance/issuance_credentialoffer.svg" alt="" />
</p>
<figcaption>Credential offer.
</figcaption>
</figure>
<p>In this profile the wallet does not have to implement the Credential Offer Endpoint described in section 4 of [[OpenID.VCI]].
</p>
<p>Instead, the Credential Issuer renders a QR code containing a reference to the Credential Offer that can be scanned by the End-User using a Wallet, as described in section 4.1 of [[OpenID.VCI]].
</p>
<p>According to the spec, the Credential Offer object is a JSON object containing the Credential Offer parameters and can be sent by value or by reference. To avoid problems with the size of the QR travelling in the URL, this profile requires that the QR contains the <code>credential_offer_uri</code>, which is a URL using the <code>https</code> scheme referencing a resource containing a JSON object with the Credential Offer parameters. The <code>credential_offer_uri</code> endpoint should be implemented by the Issuer backend.
</p>
<section id='Credential Offer Parameters'><h2>Credential Offer Parameters</h2>
<p>This profile restricts the options available in section 4.1.1 of [[OpenID.VCI]]. The profile defines a Credential Offer object containing the following parameters:
</p>
<ul>
<li><code>credential_issuer</code>: REQUIRED. The URL of the Credential Issuer that will be used by the Wallet to obtain one or more Credentials.
</li>
<li><code>credentials</code>: REQUIRED. A JSON array, where every entry is a JSON string. To achieve interoperability faster, this profile defines a global Trusted Credential Schemas List where well-known credential schemas are defined, in addition to the individual credentials that each Issuer can define themselves. The string value MUST be one of the id values in one of the objects in the <code>credentials_supported</code> metadata parameter of the Trusted Credential Schemas List (described later), or one of the id values in one of the objects in the <code>credentials_supported</code> Credential Issuer metadata parameter provided by the Credential Issuer. When processing, the Wallet MUST resolve this string value to the respective object. The credentials defined in the global Trusted Credential Schema List have precedence over the ones defined by the Credential Issuer.
<div>
<table style='width:100%;'><tr><td class='xnotet'><aside class='xnotea'><p class='xnotep'>NOTE: LEARCredential</p>
<p>The only credential being offered in our case is the LEARCredential, so this is the credential schema that should be specified here. The LEARCredential is a credential known globally to the DOME ecosystem, so its schema should be published and be available in the Trusted Credential Schemas List.
</p>
</aside></td></tr></table>
</div>
</li>
<li><code>grants</code>: REQUIRED. A JSON object indicating to the Wallet the Grant Type <code>pre-authorized_code</code>. This grant is represented by a key and an object, where the key is <code>urn:ietf:params:oauth:grant-type:pre-authorized_code</code>. In this profile the credential issuance flow requires initial authentication of the End User by the Credential Issuer, so the Pre-Authorized Code Flow achieves a good level of security and we do not need the more general Authorization Code Flow.
<div>
<p>In other scenarios like when the wallet is a native mobile application and the user interacts with the Issuer exclusively with the mobile (without the laptop), then the Authorization Code Flow has to be used. This can be described in detail in a different profile.
</p>
</div>
</li>
</ul>
<p>The grant object contains the following values:
</p>
<ul>
<li><code>pre-authorized_code</code>: REQUIRED. The code representing the Credential Issuer's authorization for the Wallet to obtain Credentials of a certain type. This code MUST be short lived and single-use. This parameter value MUST be included in the subsequent Token Request with the Pre-Authorized Code Flow.
</li>
<li><code>user_pin_required</code>: REQUIRED. The [[OpenID.VCI]] standard says it is RECOMMENDED, but this profile specifies the user pin to achieve a greater level of security. This field is a boolean value specifying whether the Credential Issuer expects presentation of a user PIN along with the Token Request in a Pre-Authorized Code Flow. Default is false. This PIN is intended to bind the Pre-Authorized Code to a certain transaction in order to prevent replay of this code by an attacker that, for example, scanned the QR code while standing behind the legit user. It is RECOMMENDED to send a PIN via a separate channel. The PIN value MUST be sent in the <code>user_pin</code> parameter with the respective Token Request.
</li>
</ul>
<p>The following non-normative example shows a Credential Offer object where the Credential Issuer offers the issuance of one Credential ("LEARCredential"):
</p>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
{
<span style="color:#000080">"credential_issuer"</span>: <span style="color:#d14">"https://www.goodair.com"</span>,
<span style="color:#000080">"credentials"</span>: [
<span style="color:#d14">"LEARCredential"</span>
],
<span style="color:#000080">"grants"</span>: {
<span style="color:#000080">"urn:ietf:params:oauth:grant-type:pre-authorized_code"</span>: {
<span style="color:#000080">"pre-authorized_code"</span>: <span style="color:#d14">"asju68jgtyk9ikkew"</span>,
<span style="color:#000080">"user_pin_required"</span>: <span style="color:#000;font-weight:bold">true</span>
}
}
}
</pre></td></tr></table>
</section>
<section id='Contents of the QR code'><h2>Contents of the QR code</h2>
<p>Below is a non-normative example of the Credential Offer displayed by the Credential Issuer as a QR code when the Credential Offer is passed by reference, as required in this profile:
</p>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
<span style="color:#008080">https://www.goodair.com/credential-offer?</span>
<span style="color:#008080">credential_offer_uri</span><span style="color:#000;font-weight:bold">=</span><span style="color:#d14">https%3A%2F%2Fserver%2Eexample%2Ecom%2Fcredential-offer%2F5j349k3e3n23j</span>
</pre></td></tr></table>
<p>Which in plain text would be:
</p>
<table style="width:100%;"><tr><td class="codecolor">
<pre class='nohighlight precolor'>
<span style="color:#008080">https://www.goodair.com/credential-offer?</span>
<span style="color:#008080">credential_offer_uri</span><span style="color:#000;font-weight:bold">=</span><span style="color:#d14">https://www.goodair.com/credential-offer/5j349k3e3n23j</span>
</pre></td></tr></table>
<p>To increase security, the Issuer MUST make sure that every Credential Offer URI is unique for all credential offers created. This is the purpose of the nonce (<code>5j349k3e3n23j</code>) at the end of the url in the example. Issuers can implement whatever mechanism they wish, as far as it is transparent to the wallet.
</p>
</section>
</section>
<section id='Credential Issuer Metadata'><h2>Credential Issuer Metadata</h2>
<p>The Wallet backend retrieves the Credential Issuer's configuration using the Credential Issuer Identifier that was received in the Credential Offer.
</p>
<p>A Credential Issuer is identified in this context by a case sensitive URL using the https scheme that contains scheme, host and, optionally, port number and path components, but no query or fragment components. No DID is used in this context.
</p>
<p>Credential Issuers MUST make a JSON document available at the path formed by concatenating the string <code>/.well-known/openid-credential-issuer</code> to the Credential Issuer Identifier. If the Credential Issuer value contains a path component, any terminating / MUST be removed before appending <code>/.well-known/openid-credential-issuer</code>.
</p>
<p><code>openid-credential-issuer</code> MUST point to a JSON document compliant with this specification and MUST be returned using the <code>application/json</code> content type.
</p>
<p>The retrieval of the Credential Issuer configuration is illustrated below.
</p>
<figure id='iss-issuermetadata'>
<p><img src="images/issuance/issuance_issuermetadata.svg" alt="" />
</p>
<figcaption>Issuer metadata.
</figcaption>
</figure>
<section id='Credential Issuer Metadata Parameters'><h2>Credential Issuer Metadata Parameters</h2>
<p>The object contained in <code>openid-credential-issuer</code> contains the following:
</p>
<ul>
<li><code>credential_issuer</code>: REQUIRED. The Credential Issuer's identifier.
</li>
<li><code>credential_endpoint</code>: REQUIRED. URL of the Credential Issuer's Credential Endpoint. This URL MUST use the https scheme and MAY contain port, path and query parameter components.
</li>
<li><code>credentials_supported</code>: REQUIRED. A JSON array containing a list of JSON objects, each of them representing metadata about a separate credential type that the Credential Issuer can issue. The JSON objects in the array MUST conform to the structure of the Section XXXX.
</li>
</ul>
<p>TODO: define a global directory of credentials supported to eliminate requirement for each individual Issuer to publish its own list.