forked from hesusruiz/did-method-elsi
-
Notifications
You must be signed in to change notification settings - Fork 2
/
authnplain.xhtml
2576 lines (2286 loc) · 241 KB
/
authnplain.xhtml
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 xmlns="http://www.w3.org/1999/xhtml" lang="en"><head><meta name="viewport" content="width=device-width, initial-scale=1" /><meta charset="utf-8" /><meta name="generator" content="ReSpec 34.1.4" /><style>dfn{cursor:pointer}
.dfn-panel{position:absolute;z-index:35;min-width:300px;max-width:500px;padding:.5em .75em;margin-top:.6em;font-family:"Helvetica Neue",sans-serif;font-size:small;background:#fff;color:#000;box-shadow:0 1em 3em -.4em rgba(0,0,0,.3),0 0 1px 1px rgba(0,0,0,.05);border-radius:2px}
.dfn-panel:not(.docked)>.caret{position:absolute;top:-9px}
.dfn-panel:not(.docked)>.caret::after,.dfn-panel:not(.docked)>.caret::before{content:"";position:absolute;border:10px solid transparent;border-top:0;border-bottom:10px solid #fff;top:0}
.dfn-panel:not(.docked)>.caret::before{border-bottom:9px solid #a2a9b1}
.dfn-panel *{margin:0}
.dfn-panel b{display:block;color:#000;margin-top:.25em}
.dfn-panel ul a[href]{color:#333}
.dfn-panel>div{display:flex}
.dfn-panel a.self-link{font-weight:700;margin-right:auto}
.dfn-panel .marker{padding:.1em;margin-left:.5em;border-radius:.2em;text-align:center;white-space:nowrap;font-size:90%;color:#040b1c}
.dfn-panel .marker.dfn-exported{background:#d1edfd;box-shadow:0 0 0 .125em #1ca5f940}
.dfn-panel .marker.idl-block{background:#8ccbf2;box-shadow:0 0 0 .125em #0670b161}
.dfn-panel a:not(:hover){text-decoration:none!important;border-bottom:none!important}
.dfn-panel a[href]:hover{border-bottom-width:1px}
.dfn-panel ul{padding:0}
.dfn-panel li{margin-left:1em}
.dfn-panel.docked{position:fixed;left:.5em;top:unset;bottom:2em;margin:0 auto;max-width:calc(100vw - .75em * 2 - .5em - .2em * 2);max-height:30vh;overflow:auto}</style>
<title>Authentication and Authorization with Verifiable Credentials</title>
<meta property="og:title" content="Authentication and Authorization with Verifiable Credentials" />
<meta property="og:type" content="website" />
<meta property="og:description" content="Authentication and Authorization with Verifiable Credentials" />
<meta property="og:site_name" content="Authn with Verifiable Credentials" />
<meta property="og:url" content="https://alastria.github.io/did-method-elsi/authzn.html" />
<link rel="stylesheet" href="./assets/templates/respec/additional.css" />
<style id="respec-mainstyle">@keyframes pop{
0%{transform:scale(1,1)}
25%{transform:scale(1.25,1.25);opacity:.75}
100%{transform:scale(1,1)}
}
:is(h1,h2,h3,h4,h5,h6,a) abbr{border:none}
dfn{font-weight:700}
a.internalDFN{color:inherit;border-bottom:1px solid #99c;text-decoration:none}
a.externalDFN{color:inherit;border-bottom:1px dotted #ccc;text-decoration:none}
a.bibref{text-decoration:none}
.respec-offending-element:target{animation:pop .25s ease-in-out 0s 1}
.respec-offending-element,a[href].respec-offending-element{text-decoration:red wavy underline}
@supports not (text-decoration:red wavy underline){
.respec-offending-element:not(pre){display:inline-block}
.respec-offending-element{background:url(data:image/gif;base64,R0lGODdhBAADAPEAANv///8AAP///wAAACwAAAAABAADAEACBZQjmIAFADs=) bottom repeat-x}
}
#references :target{background:#eaf3ff;animation:pop .4s ease-in-out 0s 1}
cite .bibref{font-style:normal}
a[href].orcid{padding-left:4px;padding-right:4px}
a[href].orcid>svg{margin-bottom:-2px}
.toc a,.tof a{text-decoration:none}
a .figno,a .secno{color:#000}
ol.tof,ul.tof{list-style:none outside none}
.caption{margin-top:.5em;font-style:italic}
table.simple{border-spacing:0;border-collapse:collapse;border-bottom:3px solid #005a9c}
.simple th{background:#005a9c;color:#fff;padding:3px 5px;text-align:left}
.simple th a{color:#fff;padding:3px 5px;text-align:left}
.simple th[scope=row]{background:inherit;color:inherit;border-top:1px solid #ddd}
.simple td{padding:3px 10px;border-top:1px solid #ddd}
.simple tr:nth-child(even){background:#f0f6ff}
.section dd>p:first-child{margin-top:0}
.section dd>p:last-child{margin-bottom:0}
.section dd{margin-bottom:1em}
.section dl.attrs dd,.section dl.eldef dd{margin-bottom:0}
#issue-summary>ul{column-count:2}
#issue-summary li{list-style:none;display:inline-block}
details.respec-tests-details{margin-left:1em;display:inline-block;vertical-align:top}
details.respec-tests-details>*{padding-right:2em}
details.respec-tests-details[open]{z-index:999999;position:absolute;border:thin solid #cad3e2;border-radius:.3em;background-color:#fff;padding-bottom:.5em}
details.respec-tests-details[open]>summary{border-bottom:thin solid #cad3e2;padding-left:1em;margin-bottom:1em;line-height:2em}
details.respec-tests-details>ul{width:100%;margin-top:-.3em}
details.respec-tests-details>li{padding-left:1em}
.self-link:hover{opacity:1;text-decoration:none;background-color:transparent}
aside.example .marker>a.self-link{color:inherit}
.header-wrapper{display:flex;align-items:baseline}
:is(h2,h3,h4,h5,h6):not(#toc>h2,#abstract>h2,#sotd>h2,.head>h2){position:relative;left:-.5em}
:is(h2,h3,h4,h5,h6):not(#toch2)+a.self-link{color:inherit;order:-1;position:relative;left:-1.1em;font-size:1rem;opacity:.5}
:is(h2,h3,h4,h5,h6)+a.self-link::before{content:"§";text-decoration:none;color:var(--heading-text)}
:is(h2,h3)+a.self-link{top:-.2em}
:is(h4,h5,h6)+a.self-link::before{color:#000}
@media (max-width:767px){
dd{margin-left:0}
}
@media print{
.removeOnSave{display:none}
}</style><meta name="description" content="We describe here a mechanism to use Verifiable Credentials to perform Authentication and Access Control leveraging the eIDAS trust framework and using advanced or qualified signatures and seals to provide a high level of legal certainty and specially enjoying the presumption of non-repudiation provided by those eIDAS signatures." /><style>var{position:relative;cursor:pointer}
var[data-type]::after,var[data-type]::before{position:absolute;left:50%;top:-6px;opacity:0;transition:opacity .4s;pointer-events:none}
var[data-type]::before{content:"";transform:translateX(-50%);border-width:4px 6px 0 6px;border-style:solid;border-color:transparent;border-top-color:#000}
var[data-type]::after{content:attr(data-type);transform:translateX(-50%) translateY(-100%);background:#000;text-align:center;font-family:"Dank Mono","Fira Code",monospace;font-style:normal;padding:6px;border-radius:3px;color:#daca88;text-indent:0;font-weight:400}
var[data-type]:hover::after,var[data-type]:hover::before{opacity:1}</style><script id="initialUserConfig" type="application/json">{
"latestVersion": "https://alastria.github.io/did-method-elsi/authzn.html",
"edDraftURI": "https://alastria.github.io/did-method-elsi/authzn.html",
"github": "https://github.com/alastria/did-method-elsi/blob/main/authzn.html",
"editors": [
{
"company": "JesusRuiz",
"companyURL": "https://hesusruiz.github.io/hesusruiz",
"email": "hesusruiz@gmail.com",
"name": "Jesus Ruiz"
}
],
"authors": [
{
"company": "JesusRuiz",
"companyURL": "https://hesusruiz.github.io/hesusruiz",
"email": "hesusruiz@gmail.com",
"name": "Jesus Ruiz"
},
{
"company": "nicos AG",
"companyURL": "https://www.nicos-ag.com/",
"email": "jlangkau@nicos-ag.com",
"name": "Jörg Langkau "
}
],
"localBiblio": {
"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)",
"id": "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",
"id": "dif.presentationexchange"
},
"EIDAS2-REG": {
"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",
"id": "eidas2-reg"
},
"ENISA-QES": {
"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",
"id": "enisa-qes"
},
"ENISA-QSEAL": {
"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",
"id": "enisa-qseal"
},
"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-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",
"id": "etsi-jades"
},
"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",
"id": "etsi-legalperson"
},
"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",
"id": "nist-auth"
},
"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",
"id": "openid.core"
},
"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",
"id": "openid.siop2"
},
"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",
"id": "openid.vci"
},
"OpenID.VP": {
"date": "21 April 2023",
"href": "https://openid.net/specs/openid-4-verifiable-presentations-1_0.html",
"title": "OpenID for Verifiable Presentations",
"id": "openid.vp"
},
"RFC6749": {
"href": "https://www.rfc-editor.org/rfc/rfc6749.html",
"title": "The OAuth 2.0 Authorization Framework",
"id": "rfc6749"
},
"RFC7515": {
"href": "https://www.rfc-editor.org/rfc/rfc7515",
"title": "JSON Web Signature (JWS)",
"id": "rfc7515"
},
"RFC7519": {
"href": "https://www.rfc-editor.org/rfc/rfc7519",
"title": "JSON Web Token (JWT)",
"id": "rfc7519"
},
"RFC8414": {
"href": "https://www.rfc-editor.org/rfc/rfc8414",
"title": "OAuth 2.0 Authorization Server Metadata",
"id": "rfc8414"
},
"RFC8725": {
"href": "https://www.rfc-editor.org/rfc/rfc8725",
"title": "JSON Web Token Best Current Practices",
"id": "rfc8725"
}
},
"publishISODate": "2023-07-05T00:00:00.000Z",
"generatedSubtitle": "05 July 2023"
}</script><link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/2021/base.css" /></head>
<body class="h-entry toc-inline"><div class="head">
<h1 id="title" class="title">Authentication and Authorization with Verifiable Credentials</h1>
<p id="w3c-state"> <time class="dt-published" datetime="2023-07-05">05 July 2023</time></p>
<details open="">
<summary>More details about this document</summary>
<dl>
<dt>Latest published version:</dt><dd>
<a href="https://alastria.github.io/did-method-elsi/authzn.html">https://alastria.github.io/did-method-elsi/authzn.html</a>
</dd>
<dt>Latest editor's draft:</dt><dd><a href="https://alastria.github.io/did-method-elsi/authzn.html">https://alastria.github.io/did-method-elsi/authzn.html</a></dd>
<dt>History:</dt><dd>
<a href="https://github.com/alastria/did-method-elsi/blob/main/authzn.html/commits/">Commit history</a>
</dd>
<dt>Editor:</dt><dd class="editor p-author h-card vcard">
<span class="p-name fn">Jesus Ruiz</span> (<a class="p-org org h-org" href="https://hesusruiz.github.io/hesusruiz">JesusRuiz</a>)
</dd>
<dt>Authors:</dt><dd class="editor p-author h-card vcard">
<span class="p-name fn">Jesus Ruiz</span> (<a class="p-org org h-org" href="https://hesusruiz.github.io/hesusruiz">JesusRuiz</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Jörg Langkau </span> (<a class="p-org org h-org" href="https://www.nicos-ag.com/">nicos AG</a>)
</dd>
<dt>Feedback:</dt><dd>
<a href="https://github.com/alastria/did-method-elsi/blob/main/authzn.html/">GitHub alastria/did-method-elsi</a>
(<a href="https://github.com/alastria/did-method-elsi/blob/main/authzn.html/pulls/">pull requests</a>,
<a href="https://github.com/alastria/did-method-elsi/blob/main/authzn.html/issues/new/choose">new issue</a>,
<a href="https://github.com/alastria/did-method-elsi/blob/main/authzn.html/issues/">open issues</a>)
</dd>
</dl>
</details>
<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>
<hr title="Separator for header" />
</div>
<section id="abstract" class="introductory"><h2>Abstract</h2>
<p>We describe here a mechanism to use Verifiable Credentials to perform Authentication and Access Control leveraging the eIDAS trust framework and using advanced or qualified signatures and seals to provide a high level of legal certainty and specially enjoying the presumption of non-repudiation provided by those eIDAS signatures.
</p>
</section><nav id="toc"><h2 class="introductory" id="table-of-contents">Table of Contents</h2><ol class="toc"><li class="tocline"><a class="tocxref" href="#abstract">Abstract</a></li><li class="tocline"><a class="tocxref" href="#conformance"><bdi class="secno">1. </bdi>Conformance</a></li><li class="tocline"><a class="tocxref" href="#authentication-and-authorization-with-verifiable-credentials"><bdi class="secno">2. </bdi>Authentication and Authorization with Verifiable Credentials</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#introduction"><bdi class="secno">2.1 </bdi>Introduction</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#signature_benefits"><bdi class="secno">2.1.1 </bdi>Signature of the Verifiable Credentials</a></li><li class="tocline"><a class="tocxref" href="#a-taxonomy-of-verifiable-credentials"><bdi class="secno">2.1.2 </bdi>A taxonomy of Verifiable Credentials</a></li><li class="tocline"><a class="tocxref" href="#verifiableid"><bdi class="secno">2.1.3 </bdi>Authentication requires a VerifiableID</a></li><li class="tocline"><a class="tocxref" href="#access-control-requires-a-verifiable-authorisation"><bdi class="secno">2.1.4 </bdi>Access Control requires a Verifiable Authorisation</a></li><li class="tocline"><a class="tocxref" href="#combining-verifiableid-and-verifiable-authorisation-in-the-learcredential"><bdi class="secno">2.1.5 </bdi>Combining VerifiableID and Verifiable Authorisation in the LEARCredential</a></li><li class="tocline"><a class="tocxref" href="#the-learcredential-for-some-identification-processes"><bdi class="secno">2.1.6 </bdi>The LEARCredential for some identification processes</a></li></ol></li><li class="tocline"><a class="tocxref" href="#the-learcredential-through-an-example"><bdi class="secno">2.2 </bdi>The LEARCredential through an example</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#claims-identifying-the-employee"><bdi class="secno">2.2.1 </bdi>Claims identifying the employee</a></li><li class="tocline"><a class="tocxref" href="#did-of-the-employee"><bdi class="secno">2.2.2 </bdi>DID of the employee</a></li><li class="tocline"><a class="tocxref" href="#legalrepresentative"><bdi class="secno">2.2.3 </bdi><code>legalRepresentative</code></a></li><li class="tocline"><a class="tocxref" href="#rolesandduties-of-the-lear"><bdi class="secno">2.2.4 </bdi><code>rolesAndDuties</code> of the LEAR</a></li><li class="tocline"><a class="tocxref" href="#assembling-the-pieces-together"><bdi class="secno">2.2.5 </bdi>Assembling the pieces together</a></li></ol></li><li class="tocline"><a class="tocxref" href="#issuing-the-learcredential"><bdi class="secno">2.3 </bdi>Issuing the LEARCredential</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#overview"><bdi class="secno">2.3.1 </bdi>Overview</a></li><li class="tocline"><a class="tocxref" href="#authentication"><bdi class="secno">2.3.2 </bdi>Authentication</a></li><li class="tocline"><a class="tocxref" href="#credential-offer"><bdi class="secno">2.3.3 </bdi>Credential Offer</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#credential-offer-parameters"><bdi class="secno">2.3.3.1 </bdi>Credential Offer Parameters</a></li><li class="tocline"><a class="tocxref" href="#contents-of-the-qr-code"><bdi class="secno">2.3.3.2 </bdi>Contents of the QR code</a></li></ol></li><li class="tocline"><a class="tocxref" href="#credential-issuer-metadata"><bdi class="secno">2.3.4 </bdi>Credential Issuer Metadata</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#credential-issuer-metadata-parameters"><bdi class="secno">2.3.4.1 </bdi>Credential Issuer Metadata Parameters</a></li></ol></li><li class="tocline"><a class="tocxref" href="#oauth-2-0-authorization-server-metadata"><bdi class="secno">2.3.5 </bdi>OAuth 2.0 Authorization Server Metadata</a></li><li class="tocline"><a class="tocxref" href="#access-token"><bdi class="secno">2.3.6 </bdi>Access Token</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#token-request"><bdi class="secno">2.3.6.1 </bdi>Token Request</a></li><li class="tocline"><a class="tocxref" href="#successful-token-response"><bdi class="secno">2.3.6.2 </bdi>Successful Token Response</a></li><li class="tocline"><a class="tocxref" href="#token-error-response"><bdi class="secno">2.3.6.3 </bdi>Token Error Response</a></li></ol></li><li class="tocline"><a class="tocxref" href="#request-and-receive-credential"><bdi class="secno">2.3.7 </bdi>Request and receive Credential</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#binding-the-issued-credential-to-the-identifier-of-the-end-user-possessing-that-credential"><bdi class="secno">2.3.7.1 </bdi>Binding the Issued Credential to the identifier of the End-User possessing that Credential</a></li><li class="tocline"><a class="tocxref" href="#credential-request"><bdi class="secno">2.3.7.2 </bdi>Credential Request</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#proof_type"><bdi class="secno">2.3.7.2.1 </bdi>Proof Type</a></li></ol></li><li class="tocline"><a class="tocxref" href="#credential-response"><bdi class="secno">2.3.7.3 </bdi>Credential Response</a></li><li class="tocline"><a class="tocxref" href="#credential-error-response"><bdi class="secno">2.3.7.4 </bdi>Credential Error Response</a></li><li class="tocline"><a class="tocxref" href="#credential-issuer-provided-nonce"><bdi class="secno">2.3.7.5 </bdi>Credential Issuer Provided Nonce</a></li></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#authenticating-with-verifiable-credentials"><bdi class="secno">2.4 </bdi>Authenticating with Verifiable Credentials</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#overview-0"><bdi class="secno">2.4.1 </bdi>Overview</a></li><li class="tocline"><a class="tocxref" href="#starting-the-openid-for-verifiable-presentations-flow"><bdi class="secno">2.4.2 </bdi>Starting the OpenID for Verifiable Presentations flow</a></li><li class="tocline"><a class="tocxref" href="#generating-the-authorization-request"><bdi class="secno">2.4.3 </bdi>Generating the Authorization Request</a></li><li class="tocline"><a class="tocxref" href="#verification-of-the-authorization-request"><bdi class="secno">2.4.4 </bdi>Verification of the Authorization Request</a></li><li class="tocline"><a class="tocxref" href="#creating-and-sending-the-authorization-response"><bdi class="secno">2.4.5 </bdi>Creating and sending the Authorization Response</a></li><li class="tocline"><a class="tocxref" href="#authenticating-the-user-with-the-learcredential"><bdi class="secno">2.4.6 </bdi>Authenticating the user with the LEARCredential</a></li></ol></li><li class="tocline"><a class="tocxref" href="#accesscontrol"><bdi class="secno">2.5 </bdi>Access control with Verifiable Credentials</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#overview-1"><bdi class="secno">2.5.1 </bdi>Overview</a></li><li class="tocline"><a class="tocxref" href="#determine-the-authorization-policies-which-apply-to-the-request"><bdi class="secno">2.5.2 </bdi>Determine the Authorization Policies which apply to the request</a></li><li class="tocline"><a class="tocxref" href="#determine-which-trusted-issuer-lists-should-be-queried"><bdi class="secno">2.5.3 </bdi>Determine which Trusted Issuer Lists should be queried</a></li><li class="tocline"><a class="tocxref" href="#query-the-trusted-issuer-lists"><bdi class="secno">2.5.4 </bdi>Query the Trusted Issuer Lists</a></li><li class="tocline"><a class="tocxref" href="#compute-the-decision-and-allow-or-not-access"><bdi class="secno">2.5.5 </bdi>Compute the decision and allow (or not) access</a></li><li class="tocline"><a class="tocxref" href="#summary-of-the-authorization-process"><bdi class="secno">2.5.6 </bdi>Summary of the authorization process</a></li></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#participants"><bdi class="secno">A. </bdi>Example scenario: Participants in the ecosystem</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#participant"><bdi class="secno">A.1 </bdi>GoodAir: the company that wants to perform the process</a></li><li class="tocline"><a class="tocxref" href="#coo-chief-operating-officer-of-goodair"><bdi class="secno">A.2 </bdi>COO (Chief Operating Officer) of GoodAir</a></li><li class="tocline"><a class="tocxref" href="#realtruth-a-trust-service-provider"><bdi class="secno">A.3 </bdi>RealTruth: a Trust Service Provider</a></li><li class="tocline"><a class="tocxref" href="#john-doe-an-administrative-employee-of-goodair"><bdi class="secno">A.4 </bdi>John Doe: an administrative employee of GoodAir</a></li><li class="tocline"><a class="tocxref" href="#dome-an-instance-of-a-data-space-for-smart-cities"><bdi class="secno">A.5 </bdi>DOME: an instance of a Data Space for Smart Cities</a></li></ol></li><li class="tocline"><a class="tocxref" href="#request_scope"><bdi class="secno">B. </bdi>Request Scope</a></li><li class="tocline"><a class="tocxref" href="#glossary"><bdi class="secno">C. </bdi>Glossary</a></li><li class="tocline"><a class="tocxref" href="#references"><bdi class="secno">D. </bdi>References</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#normative-references"><bdi class="secno">D.1 </bdi>Normative references</a></li></ol></li></ol></nav>
<section id="conformance"><div class="header-wrapper"><h2 id="x1-conformance"><bdi class="secno">1. </bdi>Conformance</h2><a class="self-link" href="#conformance" aria-label="Permalink for Section 1."></a></div><p>As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.</p><p>
The key words <em class="rfc2119">MAY</em>, <em class="rfc2119">MUST</em>, <em class="rfc2119">MUST NOT</em>, <em class="rfc2119">OPTIONAL</em>, <em class="rfc2119">RECOMMENDED</em>, and <em class="rfc2119">REQUIRED</em> in this document
are to be interpreted as described in
<a href="https://datatracker.ietf.org/doc/html/bcp14">BCP 14</a>
[<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc2119" title="Key words for use in RFCs to Indicate Requirement Levels">RFC2119</a></cite>] [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc8174" title="Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words">RFC8174</a></cite>]
when, and only when, they appear in all capitals, as shown here.
</p>
</section>
<section id="authentication-and-authorization-with-verifiable-credentials"><div class="header-wrapper"><h2 id="x2-authentication-and-authorization-with-verifiable-credentials"><bdi class="secno">2. </bdi>Authentication and Authorization with Verifiable Credentials</h2><a class="self-link" href="#authentication-and-authorization-with-verifiable-credentials" aria-label="Permalink for Section 2."></a></div>
<section id="introduction"><div class="header-wrapper"><h3 id="x2-1-introduction"><bdi class="secno">2.1 </bdi>Introduction</h3><a class="self-link" href="#introduction" aria-label="Permalink for Section 2.1"></a></div>
<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>. 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>We describe here a mechanism to use Verifiable Credentials to perform Authentication and Access Control leveraging the eIDAS trust framework and using advanced or qualified signatures and seals to provide a high level of legal certainty and specially enjoying the presumption of non-repudiation provided by those eIDAS signatures.
</p>
<table style="width:100%;"><tbody><tr><td class="xwarnt"><aside class="xwarna">
<p>We focus here on <code>legal persons</code>. It is out of scope the identification and authentication of <code>natural persons</code> (except when acting as representatives of the legal person, see below). Whenever eIDAS2 and the EUDIW (European Digital Identity Wallet) are ready, we will support that mechanism for identification and access control.
</p>
</aside></td></tr></tbody></table>
<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>
<ul class="plain">
<li id="160.Authentication"><a href="#160.Authentication" class="selfref"><b>Authentication</b></a>
<div>
<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="#verifiableid" 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 proof 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 proposal of this document, 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 qualified certificate for electronic seals issued to the Participant by an EU Qualified Trusted Services Provider (QTSP), and the signature of the credential is an advanced or qualified electronic signature using the format JAdES (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 associated to the eIDAS certificate used to sign the credential, can check if the issuer of the credential is a participant in a given Data Space by looking for that unique identifier in the Trusted Participant List managed by that Data Space.
<div>
<p>This unique number is the unique <code>organizationIdentifier</code> inside the certificates for legal persons and certificates for natural persons acting as representatives of legal persons, defined in <cite><a data-matched-text="[[[ETSI-LEGALPERSON]]]" href="https://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.02.01_60/en_31941203v010201p.pdf">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</a></cite>.
</p>
</div>
<div>
<p>Any legal person that can already engage in electronic transactions in the internal market has 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 Data Space / 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 Data Space.
</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>
</div>
<div>
</div></li><li id="194.Access_Control"><a href="#194.Access_Control" class="selfref"><b>Access Control</b></a>
<div>
<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.
</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 yet detailed in 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') 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>
</div>
</li>
</ul>
<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 Consumer Protection Directive).
</p>
<section id="signature_benefits"><div class="header-wrapper"><h4 id="x2-1-1-signature-of-the-verifiable-credentials"><bdi class="secno">2.1.1 </bdi>Signature of the Verifiable Credentials</h4><a class="self-link" href="#signature_benefits" aria-label="Permalink for Section 2.1.1"></a></div>
<p>We use <code>qualified certificates for electronic seals</code> provided by eIDAS Qualified Trust Services Providers (QTSPs) to seal credentials with advanced electronic seals (AdESeal) or with qualified electronic seals (QESeal) with the JSON Advanced Electronic Signature format (JAdES).
</p>
<p>We also use <code>qualified certificates for electronic signatures</code> issued by a QTSP to authorised representatives of the legal person, to sign credentials with advanced electronic signatures (AdES) or with qualified electronic signatures (QES) with the JSON Advanced Electronic Signature format (JAdES).
</p>
<p>This mechanism for sealing/signing the Verifiable Credentials has the following properties:
</p>
<ul class="plain">
<li><b>Provides high assurance of the identity of the creator of the credential.</b>
<div>
<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 seal is issued to the persons representing the company and not to unauthorised persons.
</p>
</div>
</li>
<li><b>Enables authorised representative of the legal person to act on behalf of the legal person.</b>
<div>
<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>
</div>
<div>
<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>
</div>
<div>
<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>
</div>
<div>
<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>
</div>
</li>
<li><b>Provides high level of legal certainty and interoperability.</b>
<div>
<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>
</div>
<div>
<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 [<cite><a class="bibref" data-link-type="biblio" href="#bib-enisa-qes" title="Security guidelines on the appropriate use of qualified electronic signatures">ENISA-QES</a></cite>] and [<cite><a class="bibref" data-link-type="biblio" href="#bib-enisa-qseal" title="Security guidelines on the appropriate use of qualified electronic seals">ENISA-QSEAL</a></cite>]).
</p>
</div>
<div>
<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>
</div>
<div>
<p>Beyond the technical interoperability, the eIDAS Regulation also ensures the international recognition of electronic signatures, and not limited to the EU.
</p>
</div>
</li>
</ul>
</section>
<section id="a-taxonomy-of-verifiable-credentials"><div class="header-wrapper"><h4 id="x2-1-2-a-taxonomy-of-verifiable-credentials"><bdi class="secno">2.1.2 </bdi>A taxonomy of Verifiable Credentials</h4><a class="self-link" href="#a-taxonomy-of-verifiable-credentials" aria-label="Permalink for Section 2.1.2"></a></div>
<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 to 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 id="fig-classes-of-credentials"><img src="builtassets/plantuml_47747c7c84b49ce4c8b0f3159b566ffc.png" alt="" />
<figcaption><a class="self-link" href="#fig-classes-of-credentials">Figure <bdi class="figno">1</bdi></a> <span class="fig-title">Classes of credentials</span></figcaption></figure>
<p>The sections below refer to this diagram for each type of credential discussed.
</p>
</section>
<section id="verifiableid"><div class="header-wrapper"><h4 id="x2-1-3-authentication-requires-a-verifiableid"><bdi class="secno">2.1.3 </bdi>Authentication requires a VerifiableID</h4><a class="self-link" href="#verifiableid" aria-label="Permalink for Section 2.1.3"></a></div>
<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"><div class="header-wrapper"><h4 id="x2-1-4-access-control-requires-a-verifiable-authorisation"><bdi class="secno">2.1.4 </bdi>Access Control requires a Verifiable Authorisation</h4><a class="self-link" href="#access-control-requires-a-verifiable-authorisation" aria-label="Permalink for Section 2.1.4"></a></div>
<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"><div class="header-wrapper"><h4 id="x2-1-5-combining-verifiableid-and-verifiable-authorisation-in-the-learcredential"><bdi class="secno">2.1.5 </bdi>Combining VerifiableID and Verifiable Authorisation in the LEARCredential</h4><a class="self-link" href="#combining-verifiableid-and-verifiable-authorisation-in-the-learcredential" aria-label="Permalink for Section 2.1.5"></a></div>
<p>In many use cases, it is possible to simplify the authentication and access control by combining in a single credential both a VerifiableID (authentication) and a Verifiable Authorisation (for access control).
</p>
<p>The resulting credential is called LEARCredential and it is very useful when the holder/subject wants to use decentralised IAM mechanisms implemented by Relying Parties which are federated in a decentralised way using a common Trust Anchor Framework.
</p>
<p>The concept of LEARCredential is described in the diagram above.
</p>
<p>The appointed employee will perform the 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>ppointed <b>R</b>epresentative).
</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 Qualified Trust Service Provider, 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 <cite><a data-matched-text="[[[ETSI-JADES]]]" href="https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf">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</a></cite>
</li>
</ul>
<p>The LEARCredential includes claims identifying the employee 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 employee (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 appointed employee to <b>use the credential as an online authentication mechanism</b> in a portal, by proving that the holder of the credential is the same person 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 person presenting the LEARCredential is the same as the one identified in the credential</b>
</li>
<li><b>A legal representative of the organisation has attested that the person has the powers described in the credential</b>
</li>
</ul>
<p>This enables the person presenting the LEARCredential to start the process and to provide any additional required documentation, preferably 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:
</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 will appoint a legal entity representative (LEAR) by generating and signing a Verifiable Credential which:
</p>
<ul>
<li>Includes identification data of an employee of the organisation
</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 employee, enabling him to prove that he 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 <cite><a data-matched-text="[[[DID-ELSI]]]" href="https://alastria.github.io/did-method-elsi/">DID ETSI Legal person Semantic Identifier Method Specification (did:elsi)</a></cite>.
</p>
<p>The high-level view of the process is described in the following diagram, when a COO (Chief Operating Officer) appoints an employee to perform some processes:
</p>
<figure id="fig-high-level-view-of-issuance-of-learcredential"><img src="builtassets/plantuml_53418b3092cb323db978af09dc064024.png" alt="" />
<figcaption><a class="self-link" href="#fig-high-level-view-of-issuance-of-learcredential">Figure <bdi class="figno">2</bdi></a> <span class="fig-title">High level view of issuance of LEARCredential</span></figcaption></figure>
</section>
<section id="the-learcredential-for-some-identification-processes"><div class="header-wrapper"><h4 id="x2-1-6-the-learcredential-for-some-identification-processes"><bdi class="secno">2.1.6 </bdi>The LEARCredential for some identification processes</h4><a class="self-link" href="#the-learcredential-for-some-identification-processes" aria-label="Permalink for Section 2.1.6"></a></div>
<p>But <b>any entity can issue VerifiableIDs</b>, though the acceptance by Relying Parties can not be ensured because it is the Relying Party the only one deciding if it trusts on the issuer and its process for generating the VerifiableID.
</p>
<p>DOME will make use of the future eIDAS2 VerifiableIDs when they are available and when they make sense in the context of DOME. But DOME defines some specific types of VerifiableIDs that are derived from eIDAS certificates for signatures/seals using the regulated standards for signatures, achieving a level of assurance that provides an acceptable level of legal certainty and reduced risk of repudiation.
</p>
<p>An example is the LEARCredential described in a section above, which has the same level of legal certainty as any document signed with the same certificates (like a contract or an invoice).
</p>
<p>Similarly, a Product provider (like GoodAir) who decides to use the DOME Trust and IAM framework or a compatible one for managing access to associated services by customers of their products will typically define specific types of VerifiableIDs if the standard ones in DOME or the existing and widely accepted ones are not suitable for the provider. In general, if a provider can use an existing and already used VerifiableID then it will facilitate potential customers access to its product because issuers of the VerifiableID do not have to modify or adapt their existing issuing processes.
</p>
</section>
</section>
<section id="the-learcredential-through-an-example"><div class="header-wrapper"><h3 id="x2-2-the-learcredential-through-an-example"><bdi class="secno">2.2 </bdi>The LEARCredential through an example</h3><a class="self-link" href="#the-learcredential-through-an-example" aria-label="Permalink for Section 2.2"></a></div>
<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 [<cite><a class="bibref" data-link-type="biblio" href="#bib-openid.vci" title="OpenID for Verifiable Credential Issuance">OpenID.VCI</a></cite>] 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"><div class="header-wrapper"><h4 id="x2-2-1-claims-identifying-the-employee"><bdi class="secno">2.2.1 </bdi>Claims identifying the employee</h4><a class="self-link" href="#claims-identifying-the-employee" aria-label="Permalink for Section 2.2.1"></a></div>
<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><a class="self-link" href="#lear-appointment-letter-1">Figure <bdi class="figno">3</bdi></a> <span class="fig-title">LEAR subject identification data.
</span></figcaption>
</figure>
<p>From the above form we can derive the following claims using the example data:
</p>
<table style="width:100%;"><tbody><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">"johndoe@goodair.com"</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></tbody></table>
</section>
<section id="did-of-the-employee"><div class="header-wrapper"><h4 id="x2-2-2-did-of-the-employee"><bdi class="secno">2.2.2 </bdi>DID of the employee</h4><a class="self-link" href="#did-of-the-employee" aria-label="Permalink for Section 2.2.2"></a></div>
<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 is 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%;"><tbody><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></tbody></table>
<p>In this example, the signatures performed with the private key can not be JAdES-compliant ([<cite><a class="bibref" data-link-type="biblio" href="#bib-etsi-jades" 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">ETSI-JADES</a></cite>]), 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%;"><tbody><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">"johndoe@goodair.com"</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></tbody></table>
</section>
<section id="legalrepresentative"><div class="header-wrapper"><h4 id="x2-2-3-legalrepresentative"><bdi class="secno">2.2.3 </bdi><code>legalRepresentative</code></h4><a class="self-link" href="#legalrepresentative" aria-label="Permalink for Section 2.2.3"></a></div>
<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%;"><tbody><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></tbody></table>
<table style="width:100%;"><tbody><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></tbody></table>
</section>
<section id="rolesandduties-of-the-lear"><div class="header-wrapper"><h4 id="x2-2-4-rolesandduties-of-the-lear"><bdi class="secno">2.2.4 </bdi><code>rolesAndDuties</code> of the LEAR</h4><a class="self-link" href="#rolesandduties-of-the-lear" aria-label="Permalink for Section 2.2.4"></a></div>
<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><a class="self-link" href="#lear-appointment-letter-2">Figure <bdi class="figno">4</bdi></a> <span class="fig-title">LEAR roles and duties.
</span></figcaption>
</figure>
<table style="width:100%;"><tbody><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></tbody></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%;"><tbody><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></tbody></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%;"><tbody><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></tbody></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"><div class="header-wrapper"><h4 id="x2-2-5-assembling-the-pieces-together"><bdi class="secno">2.2.5 </bdi>Assembling the pieces together</h4><a class="self-link" href="#assembling-the-pieces-together" aria-label="Permalink for Section 2.2.5"></a></div>
<p>With the above values for the example, the complete LEARCredential would become something like this:
</p>
<table style="width:100%;"><tbody><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">"johndoe@goodair.com"</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></tbody></table>
</section>
</section>
<section id="issuing-the-learcredential"><div class="header-wrapper"><h3 id="x2-3-issuing-the-learcredential"><bdi class="secno">2.3 </bdi>Issuing the LEARCredential</h3><a class="self-link" href="#issuing-the-learcredential" aria-label="Permalink for Section 2.3"></a></div>
<section id="overview"><div class="header-wrapper"><h4 id="x2-3-1-overview"><bdi class="secno">2.3.1 </bdi>Overview</h4><a class="self-link" href="#overview" aria-label="Permalink for Section 2.3.1"></a></div>
<p>In this example we use what we call a <i>profile</i> of the [<cite><a class="bibref" data-link-type="biblio" href="#bib-openid.vci" title="OpenID for Verifiable Credential Issuance">OpenID.VCI</a></cite>] 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><a class="self-link" href="#iss-overview">Figure <bdi class="figno">5</bdi></a> <span class="fig-title">Overview of participants.
</span></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"><div class="header-wrapper"><h4 id="x2-3-2-authentication"><bdi class="secno">2.3.2 </bdi>Authentication</h4><a class="self-link" href="#authentication" aria-label="Permalink for Section 2.3.2"></a></div>
<figure id="iss-authentication">
<p><img src="images/issuance/issuance_authentication.svg" alt="" />
</p>
<figcaption><a class="self-link" href="#iss-authentication">Figure <bdi class="figno">6</bdi></a> <span class="fig-title">Issuance authentication.
</span></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%;"><tbody><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></tbody></table>
</section>
<section id="credential-offer"><div class="header-wrapper"><h4 id="x2-3-3-credential-offer"><bdi class="secno">2.3.3 </bdi>Credential Offer</h4><a class="self-link" href="#credential-offer" aria-label="Permalink for Section 2.3.3"></a></div>
<figure id="iss-credentialoffer">
<p><img src="images/issuance/issuance_credentialoffer.svg" alt="" />
</p>
<figcaption><a class="self-link" href="#iss-credentialoffer">Figure <bdi class="figno">7</bdi></a> <span class="fig-title">Credential offer.
</span></figcaption>
</figure>
<p>In this profile the wallet does not have to implement the Credential Offer Endpoint described in section 4 of [<cite><a class="bibref" data-link-type="biblio" href="#bib-openid.vci" title="OpenID for Verifiable Credential Issuance">OpenID.VCI</a></cite>].
</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 [<cite><a class="bibref" data-link-type="biblio" href="#bib-openid.vci" title="OpenID for Verifiable Credential Issuance">OpenID.VCI</a></cite>].
</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"><div class="header-wrapper"><h5 id="x2-3-3-1-credential-offer-parameters"><bdi class="secno">2.3.3.1 </bdi>Credential Offer Parameters</h5><a class="self-link" href="#credential-offer-parameters" aria-label="Permalink for Section 2.3.3.1"></a></div>
<p>This profile restricts the options available in section 4.1.1 of [<cite><a class="bibref" data-link-type="biblio" href="#bib-openid.vci" title="OpenID for Verifiable Credential Issuance">OpenID.VCI</a></cite>]. The profile defines a Credential Offer object containing the following parameters:
</p>
<ul>
<li><code>credential_issuer</code>: <em class="rfc2119">REQUIRED</em>. The URL of the Credential Issuer that will be used by the Wallet to obtain one or more Credentials.
</li>
<li><code>credentials</code>: <em class="rfc2119">REQUIRED</em>. 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 <em class="rfc2119">MUST</em> 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 <em class="rfc2119">MUST</em> 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%;"><tbody><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></tbody></table>
</div>
</li>
<li><code>grants</code>: <em class="rfc2119">REQUIRED</em>. 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>: <em class="rfc2119">REQUIRED</em>. The code representing the Credential Issuer's authorization for the Wallet to obtain Credentials of a certain type. This code <em class="rfc2119">MUST</em> be short lived and single-use. This parameter value <em class="rfc2119">MUST</em> be included in the subsequent Token Request with the Pre-Authorized Code Flow.
</li>
<li><code>user_pin_required</code>: <em class="rfc2119">REQUIRED</em>. The [<cite><a class="bibref" data-link-type="biblio" href="#bib-openid.vci" title="OpenID for Verifiable Credential Issuance">OpenID.VCI</a></cite>] standard says it is <em class="rfc2119">RECOMMENDED</em>, 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 <em class="rfc2119">RECOMMENDED</em> to send a PIN via a separate channel. The PIN value <em class="rfc2119">MUST</em> 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%;"><tbody><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></tbody></table>
</section>
<section id="contents-of-the-qr-code"><div class="header-wrapper"><h5 id="x2-3-3-2-contents-of-the-qr-code"><bdi class="secno">2.3.3.2 </bdi>Contents of the QR code</h5><a class="self-link" href="#contents-of-the-qr-code" aria-label="Permalink for Section 2.3.3.2"></a></div>
<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%;"><tbody><tr><td class="codecolor">
<pre class="nohighlight precolor"><span style="color:#008080">https://www.goodair.com/credential-offer?</span>