-
Notifications
You must be signed in to change notification settings - Fork 3
/
index.html
663 lines (513 loc) · 48.8 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>DID ETSI Legal person Semantic Identifier Method Specification (did:elsi)</title>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<!-- Opengraph Facebook Meta Tags -->
<meta property="og:title" content="DID ETSI Legal person Semantic Identifier Method Specification (did:elsi)">
<meta property="og:type" content="website">
<meta property="og:description" content="A DID method for legal persons, maximising at the same time regulatory compliance, decentralisation and privacy for W3C Verifiable Credentials in the European Union.">
<meta property="og:site_name" content="DID:ELSI Method">
<meta property="og:url" content="https://alastria.github.io/did-method-elsi/">
<script src="https://www.w3.org/Tools/respec/respec-w3c" async="" class="remove"></script>
<script class="remove">
var respecConfig = {
latestVersion: "https://alastria.github.io/did-method-elsi/",
github: "https://github.com/alastria/did-method-elsi",
editors: [
{
company: "JesusRuiz",
companyURL: "https://hesusruiz.github.io/hesusruiz",
email: "[email protected]",
name: "Jesus Ruiz",
},
],
authors: [
{
company: "JesusRuiz",
companyURL: "https://hesusruiz.github.io/hesusruiz",
email: "[email protected]",
name: "Jesus Ruiz",
},
{
company: "DigitelTS",
companyURL: "https://digitelts.es/",
email: "[email protected]",
name: "Alejandro Nieto",
},
{
company: "DigitelTS",
companyURL: "https://digitelts.es/",
email: "[email protected]",
name: "Alejandro Alfonso",
},
{
company: "IN2",
companyURL: "https://www.in2.es/",
email: "[email protected]",
name: "Oriol Canades",
},
],
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-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",
},
"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",
},
"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",
},
"OWASP-TRANSPORT": {
href: "https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet",
title: "Transport Layer Protection Cheatsheet",
},
},
};
</script>
<style>
code {
color: red;
}
</style>
</head>
<body>
<p class="copyright">
Copyright © 2023 the document editors/authors. Text is available under the <a rel="license" href="https://creativecommons.org/licenses/by/4.0/legalcode"> Creative Commons Attribution 4.0 International Public License</a>
</p>
<section id='abstract'>
<p>This is a DID method for <b>legal persons</b>, bridging the world of the eIDAS regulation with the world of W3C Verifiable Credentials, maximising at the same time regulatory compliance, decentralisation and privacy.
</p>
<p>The main use case of the `did:elsi` method is to enable usage of W3C Verifiable Credentials in processes that require high levels of <b>legal certainty, scalability, privacy and eIDAS compliance</b>. It is a good complement to `did:web` in ecosystems like Data Spaces with machine-to-machine interactions, but where some processes can not use `did:web` because they require high levels of legal certainty and compliance that can not be achieved with `did:web` (e.g., onboarding or contract signing processes).
</p>
<p>The `did:elsi` method facilitates the use of <a href="https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf">JAdES digital signatures</a> with Verifiable Credentials, and so it can be used to meet the requirements of <b>electronic signatures, advanced electronic signatures, qualified electronic signatures, electronic seals, advanced electronic seals, and qualified electronic seals</b> as defined in Regulation (EU) No 910/2014 (eIDAS).
</p>
<aside class='note'>
<p><b>Natural persons MUST not</b> use this DID method, or for that matter, any DID method that registers anything related to personal information in any type of Verifiable Registry or shared data store.
</p>
<p>A good DID method for natural persons is `did:key` which is a perfect complement to `did:elsi` to build ecosystems that maximise privacy, regulatory compliance, safety, scalability, and decentralisation.
</p>
</aside>
<p>This DID method is highly decentralised because any legal person than can operate in the digital economy and that can digitally sign a document using an advanced or qualified signature or seal according to eIDAS (like an invoice or a contract) has automatically a DID identifier under the `did:elsi` method without any further action and without any intervention by any third party. If the legal person can not engage in electronic transactions, it must perform whatever process is legally required in its jurisdiction to do so, before it can use this DID method. No third parties, apart from the ones legally required by its jurisdiction, are involved in this DID method.
</p>
<p>The identifiers in this DID method are based on the unique identifiers that are already used in the eIDAS certificates that comply to the relevant ETSI standards for electronic signatures and seals. This is in contrast to most other did methods, which invent or use identifiers and mechanisms that are not well integrated with the legal framework and which are not in general legally recognised in the EU for economic transactions (e.g., they can not be used as legal person identifiers in electronic invoices across the EU).
</p>
<p>With this approach, SSI ecosystems can use W3C Verifiable Credentials that have the same legal status as any other document which uses advanced or qualified electronic signatures and seals, and so can replace easily other documents in less efficient formats, like signed PDFs.
</p>
</section>
<section><h2>Introduction</h2>
<section><h2>Preface</h2>
<p>The <code>elsi</code> DID method specification conforms to the requirements specified in the Decentralized Identifiers v1.0 Specification [[DID-CORE]]. For more information about DIDs and DID method specifications, please also see the [[?DID-PRIMER]]
</p>
</section>
<section id='conformance'>
<!-- href='-' This section is filled automatically by ReSpec.>
</!-->
</section>
<section><h2>Examples</h2>
<p>Some example DIDs are the following:
</p>
<ul>
<li id='list_105.1'>Gaia-X: `did:elsi:VATBE-0762747721` </li>
<li id='list_105.2'>International Data Spaces Association: `did:elsi:VATDE-325984196` </li>
<li id='list_105.3'>Alastria: `did:elsi:VATES-G87936159` </li>
<li id='list_105.4'>IN2: `did:elsi:VATES-B60645900` </li>
<li id='list_105.5'>Digitel TS: `did:elsi:VATES-B47447560` </li>
<li id='list_105.6'>FIWARE Foundation: `did:elsi:VATDE-309937516` </li>
<li id='list_105.7'>TNO: `did:elsi:LEIXG-724500AZSGBRY55MNS59` </li>
</ul>
<p>The corresponding DID Documents are described later in this document.
</p>
</section>
</section>
<section><h2>The did:elsi format</h2>
<p>The format for the `did:elsi` method conforms to the [[DID-CORE]] specification and is simple. It consists of the `did:elsi` prefix, followed by the <code>organizationIdentifier</code> field which is used in the eIDAS certificates for legal persons as defined in [[ETSI-LEGALPERSON]].
</p>
<p>The ABNF for the key format is described below:
</p>
<pre class='abnf'><code>did-key-format := did:elsi:<organizationIdentifier></code></pre>
<section><h2>About the <code>organizationIdentifier</code></h2>
<p>The [[ETSI-LEGALPERSON]] standard states the following about the <code>organizationIdentifier</code> field in the digital certificates for legal persons:
</p>
<blockquote>
<p>The subject field shall include at least the following attributes as specified
in Recommendation ITU-T X.520:
</p>
<ul>
<li id='list_133.1'>countryName </li>
<li id='list_133.2'>organizationName </li>
<li id='list_133.3'><strong>organizationIdentifier</strong> </li>
<li id='list_133.4'>commonName </li>
</ul>
</blockquote>
<p>And regarding the <code>organizationIdentifier</code> attribute it says:
</p>
<blockquote>
<p>The <code>organizationIdentifier</code> attribute shall contain an
identification of the subject organization different from the organization
name. Certificates may include one or more semantics identifiers as
specified in clause 5 of ETSI EN 319 412-1.
</p>
</blockquote>
<p>And the document referenced, [[ETSI-CERTOVERVIEW]] states:
</p>
<blockquote>
<p>When the legal person semantics identifier is included, any present
organizationIdentifier attribute in the subject field shall contain
information using the following structure in the presented order:
</p>
<ul>
<li id='list_154.1'>3 character legal person identity type reference </li>
<li id='list_154.2'>2 character ISO 3166 [2] country code </li>
<li id='list_154.3'>hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)) and </li>
<li id='list_154.4'>identifier (according to country and identity type reference) </li>
</ul>
<p>The three initial characters shall have one of the following defined values:
</p>
<ol>
<li id='list_162.1'><code>VAT</code> for identification based on a national value added tax identification number. </li>
<li id='list_162.2'><code>NTR</code> for identification based on an identifier from a national trade register. </li>
<li id='list_162.3'><code>PSD</code> for identification based on the national authorization number of a payment service provider under Payments Services Directive (EU) 2015/2366 [i.13]. This shall use the extended structure as defined in ETSI TS 119 495 [3], clause 5.2.1. </li>
<li id='list_162.4'><code>LEI</code> for a global Legal Entity Identifier as specified in ISO 17442 [4]. The 2 character ISO 3166 [2] country code shall be set to 'XG'. </li>
<li id='list_162.5'>Two characters according to local definition within the specified country and name registration authority, identifying a national scheme that is considered appropriate for national and European level, followed by the character ":" (colon). </li>
</ol>
<p>Other initial character sequences are reserved for future amendments of the present document. In case "VAT" legal person identity type reference is used in combination with the "EU" transnational country code, the identifier value should comply with Council Directive 2006/112/EC [i.12], article 215.
</p>
</blockquote>
<p>That means that any eIDAS certificate issued by <a href="https://digital-strategy.ec.europa.eu/en/policies/eu-trusted-lists">TSPs</a> to legal persons compliant with the ETSI standards including an <code>organizationIdentifier</code> attribute can be used to derive a DID for a legal person from the ETSI standard identifier by applying the rule described above.
</p>
<p>Some examples of DIDs are:
</p>
<pre class='example' title="Example ELSI Method DIDs">Gaia-X: did:elsi:VATBE-0762747721
International Data Spaces Association: did:elsi:VATDE-325984196
Alastria: did:elsi:VATES-G87936159
IN2: did:elsi:VATES-B60645900
Digitel TS: did:elsi:VATES-B47447560
FIWARE Foundation: did:elsi:VATDE-309937516
TNO: did:elsi:LEIXG-724500AZSGBRY55MNS59</pre>
</section>
<section><h2>Proving control of the DID</h2>
<p>When sending and receiving Verifiable Credentials, a legal person may be required to prove that it controls a DID included in the Verifiable Credential.
</p>
<p>Proving the control of a `did:elsi`identifier can be done using the associated certificate: it is enough to include the certificate with a signature or seal, as it is required by the eIDAS regulation for advanced/qualified signatures and seals. By the way, this means that any existing eIDAS-compliant signature of any type of document (not only Verifiable Credentials) is already compliant with this DID method specification, just by making the corresponding translation.
</p>
</section>
</section>
<section><h2>DID method operations</h2>
<p>The following section describes the DID operations for the did:elsi method. This DID Method is purely derivative, based on the current eIDAS Trust Framework and so it does not require look ups in any additional registry.
</p>
<section><h2>Create</h2>
<p>If a legal person can digitally sign or seal a document using an advanced or qualified certificate in the EU, then it already has a valid `did:elsi`identifier, using the <code>organizationIdentifier</code> in the certificate used to sign or seal. No further actions are required.
</p>
<p>If the legal entity can not perform those electronic signatures, then it does not make sense that it wants an ELSI DID, because it is not really transacting digitally and most probably is performing most processes manually and with paper. Before entering the world of digital transactions with Verifiable Credentials, the legal entity has to become digital at least until it can digitally sign legally-binding documents.
</p>
</section>
<section><h2>Read (Resolve)</h2>
<p>This DID Method is purely derivative, based on the current Trust Framework of eIDAS and so it does not require look ups in any additional registry, and the DID document does not have to contain a <code>verificationMethod</code> property.
</p>
<p>Reading a `did:elsi` value consists on deterministically expanding the value to a minimalist DID Document, like the following:
</p>
<pre class='example' title="Minimum DID document">{
"@context": [
"https://www.w3.org/ns/did/v1"
],
"id": "did:elsi:exampleOrganizationIdentifier",
}</pre>
<p>It may be surprising to see a DID document without a <code>proof</code> section, but in the case of this DID it is not required (even though implementations may choose to return DID documents including it).
</p>
<p>One of the common situations where DID resolution is required is in the verification of Verifiable Credentials. This DID method is intended to be used in W3C Verifiable Credentials which, when signed using JAdES digital signatures, can be used to meet the requirements of electronic signatures, advanced electronic signatures, qualified electronic signatures, electronic seals, advanced electronic seals, and qualified electronic seals as defined in Regulation (EU) No 910/2014 (eIDAS).
</p>
<p>Section <a href="#didresolution"></a> describes the verification of those credentials and why a <code>verificationMethod</code> property in the DID document is not required.
</p>
</section>
<section><h2>Update</h2>
<p>This DID method does not support updates. Management of the DID lifecycle and associated information (e.g., cryptographic material) is performed according to the eIDAS regulation and its implementation.
</p>
</section>
<section><h2>Deactivate (Revoke)</h2>
<p>This DID method does not support deactivation. Management of the DID lifecycle and associated information (e.g., cryptographic material) is performed according to the eIDAS regulation and its implementation.
</p>
</section>
</section>
<section id='didresolution' class='informative'><h2>DID resolution and the verification of Verifiable Credentials</h2>
<p>The main use case for this DID method is to use `did:elsi` identifiers in W3C Verifiable Credentials signed using JAdES digital signatures [[ETSI-JADES]], which is a specification for JSON Web Electronic Signatures or Seals fulfilling the requirements of the European Union eIDAS Regulation for advanced electronic signatures and seals and regulatory requirements for many different services.
</p>
<section><h2>JSON Advanced Electronic Signatures (JAdES)</h2>
<p>The JAdES digital signature specification is based on JSON Web Signature and contains the features already defined in the related ETSI standards for AdES (advanced electronic signature/seal) applied to other data formats including XML, PDF and binary.
</p>
<p>[[ETSI-JADES]] can be used for any transaction between an individual and a company, between two companies, between an individual and a governmental body, etc. applicable to any electronic communications. The technical features of the specification can therefore be applied to the use of PKI based digital signature technology and in both regulated and general commercial environments.
</p>
<p>Essentially, JAdES specifies a JSON [[RFC8259]] format for AdES signatures (JAdES signatures) built on JSON Web Signatures (JWS) as specified in [[RFC7515]]:
</p>
<ul>
<li id='list_245.1'>Extends the JSON Web Signatures specified in [[RFC7515]] by defining an additional set of JSON header parameters that can be incorporated in the JOSE Header. </li>
<li id='list_245.2'>Specifies the mechanisms for incorporating the above JSON components in JSON Web Signatures to build JAdES signatures, offering the same features as CAdES and XAdES in JSON syntax, and therefore fulfilling the same requirements. </li>
</ul>
</section>
<section><h2>Validation of the signature of Verifiable Credentials</h2>
<p>The process of validation of verifiable credentials or verifiable presentations is composed of different individual validations, depending on several factors like type of credential and use case requirements.
</p>
<p>One of those validations which is normally critical is the verification of signatures in the credential, for example the signature of the issuer. In the case of credentials signed with eIDAS certificates/seals using the JAdES format, the verification process can be based in the guidelines described in the implementation of the algorithm of the Digital Europe eSignature Building Block for the validation of qualified and advanced electronic signatures (e-signatures) and electronic seals (e-seals).
</p>
<p>The algorithm [[DEP-DSS]] focuses on determining 3 sub-conclusions:
</p>
<ol>
<li id='list_258.1'>Whether the certificate is qualified </li>
<li id='list_258.2'>What is the type of this certificate </li>
<li id='list_258.3'>Whether the corresponding private key is protected by a QSCD. </li>
</ol>
<p>To achieve a high level of trust in the validation, this can be delegated to Qualified Trust Service Providers (QTSPs) that offer services specifically for this purpose.
</p>
<p>By using a QTSP, users can be confident that the validation service meets the requirements set out in eIDAS regulations, which in turn provides a higher level of legal certainty. This is because QTSPs are legally obligated to be listed in the national Trusted List, which is easily accessible to users via the Trusted List Browser.
</p>
<p>Alternatively, an electronic signature or seal can also be verified by implementing the Digital Signature Software (DSS) library, which is open-source and provided by the EU.
</p>
</section>
</section>
<section class='informative'><h2>Security and privacy considerations</h2>
<section><h2>Security considerations</h2>
<p>When using this DID method and signing Verifiable Credentials with eIDAS certificates/seals using the JAdES format, the credential is essentially a signed document with the same security profile as any other document with an advanced signature in the eIDAS framework.
</p>
<p>This security profile is very well understood and described in many places, for example in the <a href="https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/eSignature">eSignature building block of the Digital Europe Program</a>.
</p>
</section>
<section><h2>Privacy considerations</h2>
<p>This DID method is only for legal persons. Natural persons MUST not use it, due to privacy considerations.
</p>
<p>For legal persons, this DID method does not add any privacy consideration to the ones managed in the eIDAS framework.
</p>
<p>Actually, the EU regulatory environment requires that identities (and identifiers) of any legal person be completely public and subject to public scrutiny, whether from regulators, consumer organisations, industry watchdogs or any other interested party. Some examples:
</p>
<ul>
<li id='list_285.1'>Any of the 30 million businesses in the EU is required by law to register with the appropriate national or international body before being able to engage in any relevant activity. During the process, an identifier is assigned to the business. The registration process and the way to obtain the identifier varies depending on the industry regulation (e.g., banking, telco, health, ...) and other factors. </li>
<li id='list_285.2'>The identities of businesses are public and anybody can access all related information from the relevant registries. Even if in some EU countries access is not free, it is public. Information includes many details about the business, including identifier, ownership and place of establishment. </li>
<li id='list_285.3'>Businesses are required to include those identifiers in any relevant transaction, whether they are electronic or offline. When citizens buy any product or service, they have the right to obtain documentation about the purchase including the identifier of the company. </li>
<li id='list_285.4'>Any relevant process in the real economy (agrifood, health, manufacturing, transportation, ...) imposes requirements on traceability of the supply chain, related among others with safety, health and consumer protection and the ability to react properly to emergencies. Information recorded and on custody by all businesses participating in the chain has to use the legally valid identifiers of each business. </li>
</ul>
</section>
</section>
<section class='informative'><h2>Example: `did:elsi` and onboarding with Verifiable Credentials</h2>
<p>To illustrate the usefulness of the `did:elsi` method, this section describes the relationship of the `did:elsi` method with a special type of Verifiable Credential that we call <b>LEARCredential</b> and which can be very useful to perform, among others, the onboarding process in ecosystems like Data Spaces with compliance to the eIDAS regulation.
</p>
<p>The objective of the onboarding process in an ecosystem is to identify and register a legal entity as a new participant. However, in most cases the process is initiated and driven by a natural person.
</p>
<p>To provide appropriate levels of legal certainty and security, the onboarding process requires that the natural person driving the process demonstrates that she is either:
</p>
<ul>
<li id='list_303.1'>a legal representative of the new participant or </li>
<li id='list_303.2'>a natural person that has been delegated by a legal representative at least the powers required to perform the onboarding process on behalf of the legal entity. </li>
</ul>
<p>The onboarding process described here is based on a special type of Verifiable Credential that we will call LEARCredential (from <b>L</b>egal <b>E</b>ntity <b>A</b>ppointed <b>R</b>epresentative), given its purpose. We require that the user driving the process uses a LEARCredential and that the user proves control of the `did:elsi` identifier which is the subject of the credential (the details of how this is done using eIDAS certificates are described below).
</p>
<section><h2>A little bit about onboarding</h2>
<p>The word <i>onboarding</i> refers to a process which precedes entering into a business relationship with a new participant, which in our case has to be a legal person (because `did:elsi` is only for legal persons).
</p>
<p>In general, the onboarding process is one of the less digitised and more diverse, with different implementations depending on the sector of activity and local regulation. Even within the same sector the actual implementation of onboarding processes for different companies can vary considerably. Onboarding of participants in an ecosystem may also present differences depending on the specific ecosystem.
</p>
<p>This chapter presents an approach based on eIDAS certificates that can facilitate in the EU area a fully digital and automated cross-border onboarding process and compliance with KYC (Know Your Customer) requirements.
</p>
<p>Onboarding of a new participant in the ecosystem is a critical activity, and proper identification of the new participant at this stage affects very much to the level of trust of the whole onboarding process and so the level of trust that all the other participants in the ecosystem can place on the identity of the new participant. The objective here is to provide a reasonable balance between convenience and level of legal certainty and security of the electronic transactions involved in the onboarding process.
</p>
<p>To facilitate the descriptions later in this document, we reproduce here some relevant definitions taken from the eIDAS Regulation:
</p>
<p><b>Electronic identification</b> means the process of using person identification data in electronic form uniquely representing either a natural or legal person, or a natural person representing a legal person.
</p>
<p><b>Person identification data</b> means a set of data enabling the identity of a natural or legal person, or a natural person representing a legal person to be established.
</p>
<p><b>Authentication</b> means an electronic process that enables the electronic identification of a natural or legal person, or the origin and integrity of data in electronic form to be confirmed.
</p>
<p><b>Relying party</b> means a natural or legal person that relies upon an electronic identification or a trust service;
The onboarding process presented in this chapter is just one of the possible options that can be implemented, but it should be the main one supported in the EU region given its advantages.
</p>
</section>
<section id='typesofcertificates'><h2>Types of certificates for onboarding</h2>
<p>`did:elsi` uses eIDAS certificates. The types of certificates which are relevant for the onboarding process are the ones issued to natural persons, to legal persons and to natural persons representing a legal person (as described in article 3(1) of eIDAS for the case of representation).
</p>
<p>Based on the eIDAS regulation, some TSPs (Trust Service Providers) in the EU provide several types of certificates for electronic signatures and seals:
</p>
<ul>
<li id='list_337.1'><b>Natural Person</b> certificate for electronic signatures </li>
<li id='list_337.2'><b>Legal Person</b> certificate for electronic seals </li>
<li id='list_337.3'><b>Natural Person as Legal Entity Representative</b> certificate for electronic signatures </li>
</ul>
<aside class='note' title="electronic signature vs. electronic seals">
<p><b>Electronic signature</b>: An electronic signature is a data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign, <b>where the signatory is a natural person</b>.
</p>
<p>Like its handwritten counterpart in the offline world, an electronic signature can be used, for instance, to electronically indicate that the signatory has written the document, agreed with the content of the document, or that the signatory was present as a witness.
</p>
<p><b>Electronic seal</b>: An electronic seal is a data in electronic form, which is attached to or logically associated with other data in electronic form to ensure the latter’s origin and integrity, <b>where the creator of a seal is a legal person</b> (unlike the electronic signature that is issued by a natural person).
</p>
<p>In this purpose, electronic seals might serve as evidence that an electronic document was issued by a legal person, ensuring certainty of the document’s origin and integrity. Nevertheless, across the European Union, <b>when a transaction requires a qualified electronic seal from a legal person, a qualified electronic signature from the authorized representative of the legal person is equally acceptable</b>.
</p>
</aside>
</section>
<section><h2>Some terminology</h2>
<p>Not all Member States implement at this moment the certificate for a Natural Person as Legal Entity Representative, but the onboarding process described below takes advantage of it when it is available for a participant initiating the onboarding.
</p>
<p>In this way, the onboarding process is prepared for the future, because given that there are different cases of representation, the eIDAS Technical subgroup has been requested by the eIDAS Cooperation Network to amend the technical specifications to include all the cases of representation (see section "2.8. NATURAL AND LEGAL PERSON REPRESENTATIVE from eIDAS SAML Attribute Profile V1.2., 31 August 2019"). It is expected that in the near future most TSPs will start issuing those certificates that simplify and streamline enormously the onboarding processes, not just for this specific use case but for any type of use case in the economy.
</p>
<p>To facilitate the explanation below, we will use the following terminology:
</p>
<ul>
<li id='list_361.1'><b>NP</b>: Natural Person holding a certificate for electronic signature. </li>
<li id='list_361.2'><b>LE</b>: the Legal Entity that is being onboarded, holding a certificate for electronic seal. </li>
<li id='list_361.3'><b>LER</b>: the Natural Person as Legal Entity Representative, holding a certificate for electronic signature when acting as legal representative of a legal entity. </li>
</ul>
<p>The above concepts have a one-to-one relationship with the legal entities in eIDAS. However, we need a little bit more flexibility with respect to the person/employee that can initiate and drive the onboarding process of the legal person in the ecosystem. Even in a big company there are not many employees that have the power of legal representation. We define here an additional concept that is being used already in many other contexts:
</p>
<ul>
<li id='list_368.1'><b>LEAR</b>: Legal Entity Appointed Representative, a natural person that has been nominated (appointed) by a legal representative to act on behalf of the organisation to perform a limited set of processes, in our case the onboarding process (and maybe some additional tasks). </li>
</ul>
<p>Instead of using traditional X.509 certificates, we require that the LEAR receives a special type of Verifiable Credential called <b>LEARCredential</b> with proof that the person has the power to represent the legal person in some limited capacity. This credential is described later in this document.
</p>
<p>This concept of LEAR is very similar to the equivalent one for how organisations interact with the European Commission to perform certain tasks on behalf of their organisation, as part of its participation in EU funded grants, procurements and prizes that are managed via the EU Funding & Tenders Portal. To illustrate further, see below the description of LEAR from the Commission.
</p>
<aside class='note' title="LEAR appointment and validation">
<p>Parallel to the validation of your organisation, you will be requested by the Central Validation Service to appoint your Legal Entity Appointed Representative (LEAR).
</p>
<p>This must be done by a <b>legal representative of your organisation with the necessary legal authority to commit the organisation</b> for this type of decisions (e.g. typically CEOs, rectors, Director-Generals, etc. always in accordance with the statutes of your organisation).
</p>
<p>The LEAR role, which <b>can be performed by any member of the organisation</b> (typically from the central administration), is key. They are formally nominated to manage your organisation's use of the Portal and thus bear the final responsibility for all your actions in the Portal. Once validated, they will be responsible for:
</p>
<ul>
<li id='list_383.1'>keeping an overview of all the proposals/projects/contracts your organisation is involved in </li>
<li id='list_383.2'>managing all the legal and financial information about your organisation </li>
<li id='list_383.3'>managing the access rights at organisation-level (and read-only access at project-level) </li>
<li id='list_383.4'>appointing the persons which will be able to electronically sign grants/contracts (Legal Signatories — LSIGNs) and cost claims/invoices (Financial Signatories — FSIGNs). </li>
</ul>
</aside>
</section>
<section><h2>The LEARCredential</h2>
<p>The LEARCredential can be generated in different ways, using the different eIDAS certificates described in section <a href="#typesofcertificates"></a> and the Trust Service Providers:
</p>
<ul>
<li id='list_394.1'><b>Using the LE certificate</b>. The person controlling the LE certificate issues a Verifiable Credential to a natural person which typically is an employee of a department in charge of managing the onboarding processes and the relationship with a given ecosystem. The Verifiable Credential includes a description of the actual powers that are being delegated (the required ones have to be defined by the ecosystem). The Verifiable Credential is sealed with the certificate of the LE. This VC is then called a LEARCredential and the person controlling it can use it to authenticate in the onboarding process and act as LEAR. </li>
<li id='list_394.2'><b>Using the LER certificate</b>. The main difference with the above is that in this case the Verifiable Credential is signed with a LER certificate. This tends to be easier, especially in big companies because there are normally more than one LER depending on the company structure. As a special case, the LER can issue a LEARCredential to herself and then become a LEAR. This can be used when the LER wants to be the one performing the onboarding process. </li>
<li id='list_394.3'><b>Using a trusted entity before onboarding</b>. When neither LE nor LER certificates are already available in the company, a TSP or other trusted entity accepted by the ecosystem could generate and sign the Verifiable Credential directly, instead of generating a LER certificate. <div>
<p>The main difference with the previous scenarios is that the LEARCredential is signed by a trusted entity and that it has to be involved before the onboarding process starts, making the process somewhat more cumbersome and less self-service.
</p>
</div>
</li>
</ul>
<p>The LEARCredential replaces its analog counterpart with a more efficient, machine-interpretable version. To illustrate, we continue using here the example of the LEAR for the Funding & tender portal of the EC, with the natural language letter that has to be signed: <a href="https://ec.europa.eu/info/funding-tenders/opportunities/docs/2021-2027/common/temp-form/lev/lear-appointment-letter-and-lear-roles-and-duties_en.pdf">LEAR APPOINTMENT LETTER</a>.
</p>
<section><h2>Claims about the subject</h2>
<p>The LEARCredential should include claims identifying the subject of the credential, the person who will act as LEAR. Each Data Space can define their own depending on their specific requirements. For the example for the EC portal, they should replace their analog counterparts in the first page of the letter, displayed here for illustration.
</p>
<figure id='lear-appointment-letter-1'>
<p><img src="images/lear-appointment-letter-1.png" alt="" />
</p>
<figcaption>LEAR subject identification data.
</figcaption>
</figure>
</section>
<section><h2>Roles and duties</h2>
<p>The LEARCredential should specify the roles and duties of the LEAR. This can be done either embedding a machine-interpretable definition of the roles and duties in the credential, or with just a pointer to an external definition of the roles and duties in natural language, hosted somewhere else. 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.
</p>
<p>For illustration, the following figure shows some of the roles and duties in our LEAR example.
</p>
<figure id='lear-appointment-letter-2'>
<p><img src="images/lear-appointment-letter-2.png" alt="" />
</p>
<figcaption>LEAR roles and duties.
</figcaption>
</figure>
<p>The major problem here is to what level the natural language description of the roles and duties of the LEAR and delegation of those will be described in a formal language, versus simply embedding a secure pointer to somewhere where the actual natural language description is stored. This is an important subject for automating completely access control.
</p>
</section>
<section><h2>Further delegation of powers</h2>
<p>The LEAR has delegated powers from the legal representative of the legal person. Using a similar mechanism, the LEAR can further delegate a subset of those powers to one or more persons who will act as account administrators. This can be seen in section 4 of the letter for our example LEAR:
</p>
<figure id='lear-appointment-letter-3'>
<p><img src="images/lear-appointment-letter-3.png" alt="" />
</p>
<figcaption>Further delegation of LEAR roles and duties.
</figcaption>
</figure>
</section>
<section><h2>Proving control of the LEAR Credential</h2>
<p>The person being appointed as a LEAR is identified as the subject of the credential. In order to later prove control of the credential, the issuer should embed as one of the claims a public key that corresponds to a private key only known by the LEAR and that will be used to sign challenges in the identification and access management systems of the Relying Party that wants to verify the LEAR Credential.
</p>
<p>If the LEAR has an eIDAS certificate, then the contents of that claim should be the certificate itself. Alternatively, the keypair can be generated in a secure and private way during the issuance process (which uses the OIDC4VCI standard).
</p>
<p>The DID identifier for the LEAR in the credential should use the `did:elsi` method (if the LEARCredential embeds an eIDAS certificate) or `did:key` if it does not.
</p>
</section>
<section><h2>Signing of the LEARCredential</h2>
<p>The LEARCredential must be signed by the issuer using either a LE certificate or a LER certificate, following the JAdES format specified in [[ETSI-JADES]].
</p>
<p>The issuer should be identified in the credential using the `did:elsi` method.
</p>
</section>
</section>
<section><h2>The identification and verification phase</h2>
<p>The onboarding service of a Data Space can act as a Relying Party and use the LEARCredential for authentication to identify the legal person involved and the natural person performing the onboarding and additionally verify the binding between both identities and that the natural person has the powers of representation.
</p>
<p>This can be done fully automated and without requiring a previous relationship among the new participant and the onboarding service, enabling self-onboarding.
</p>
<p>Once this step is performed, the LEAR can provide additional documents (ideally as Verifiable Credentials) to complete the onboarding process or perform other required validations. For a Gaia-X compatible Data Space, the LEAR can provide credentials received from the <a href="https://compliance.gaia-x.eu/">Gaia-X Compliance Service</a>.
</p>
</section>
</section>
<section class='informative'><h2>Relationship with some other DID methods</h2>
<p>It is difficult (if not impossible) to have a complex ecosystem like Data Spaces with only one DID method, especially if different types of entities coexist in the ecosystem. The "one-size-fits-all" rule does not apply in this case, as is also true in general.
</p>
<p>For example, if there are natural persons, legal persons and machines in the same ecosystem, there is not any DID method that supports all of them while achieving high levels of regulatory compliance, privacy, scalability and decentralisation.
</p>
<p>This is also true of `did:elsi`, which is designed only for legal persons. Two other DID methods that may be appropriate for the other types of entities are:
</p>
<ul>
<li id='list_469.1'>`did:key` for natural persons </li>
<li id='list_469.2'>`did:web` for machines (servers, sensors, ...) </li>
</ul>
<p>The next section provides some reasoning on why `did:web` is not adequate for the same use cases as `did:elsi`.
</p>
<section><h2>Comparison with `did:web`</h2>
<p>In the `did:web` method, the identifier is essentially a domain name that matches the common name used in the SSL/TLS certificate used in the web server hosting the associated DID document. For example, in the case of `https://gaia-x.eu/` the common name (CN) in the certificate is `CN = gaia-x.eu` so the corresponding did would be `did:web:gaia-x.eu` (assuming that no directories or subdirectories are used).
</p>
<p>This is very convenient, but in most SSL/TLS certificates there is not any relationship between that identifier and the identifier issued by an official registrar that identifies the entity as a legal person or its legal representative, which is required in most types of electronic transactions in the internal market (for example in contract signing or eInvoices). This makes `did:web` not adequate for processes where you want to achieve legal certainty of substantial or high (according to eIDAS).
</p>
<p>One possibility could be to put an eIDAS certificate as one of the elements of the `"verificationMethod"` object in the DID document. But this has several problems:
</p>
<ul>
<li id='list_483.1'>The verifiable credentials should use the `did:web` identifier, with still no relationship to the legal person or its legal representative, unless a level of indirection is performed, accessing the web server when a verification of the credential is needed. </li>
<li id='list_483.2'>Once this access to the web server is done, the same verification process as in `did:elsi` has to be performed, making the mechanism more complex without adding any real value. In essence, the entity has to prove control of the web server and also of the eIDAS certificate. </li>
</ul>
<p>Furthermore, the need to access the web server to get the DID document and the embedded eIDAS certificate presents additional problems:
</p>
<ul>
<li id='list_489.1'>Less resiliency, as verification of a credential with a `did:web` identifier may fail if the web server is not available at that moment. This may be a big problem if the ecosystem includes many entities with low guarantees of availability of their web servers. Please note that signing the credential with the eIDAS certificate and including it in the credential but using `did:web` is just a convoluted implementation of the simpler `did:elsi`: in `did:elsi` you just sign the credential using the standard format (JAdES) and use the same identifier inside the certificate for the did identifier. No additional web server access is required. </li>
<li id='list_489.2'>Less privacy, as the web server of the issuer of a credential has to be accessed every time that a credential is verified (a sensible caching could be used, but there is a risk that the DID document has been changed by the web server in the meantime). This privacy risk does not happen with `did:elsi` because no access to the web server is required. Given that root anchors for eIDAS certificates would be stored in the Trust Framework, privacy is very high with `did:elsi`. </li>
</ul>
</section>
</section>
<section id="references">
</body>
</html>