index.rite

---
title: DID ETSI Legal person Semantic Identifier Method Specification (did:elsi)

editors:
    - name: "Jesus Ruiz"
      email: "hesusruiz@gmail.com"
      company: "JesusRuiz"
      companyURL: "https://hesusruiz.github.io/hesusruiz"

authors:
    - name: "Jesus Ruiz"
      email: "hesusruiz@gmail.com"
      company: "JesusRuiz"
      companyURL: "https://hesusruiz.github.io/hesusruiz"
    - name: "Alejandro Nieto"
      email: "alejandro.nieto@madisonmk.com"
      company: "DigitelTS"
      companyURL: "https://digitelts.es/"
    - name: "Alejandro Alfonso"
      email: "alejandro.alfonso@madisonmk.com"
      company: "DigitelTS"
      companyURL: "https://digitelts.es/"
    - name: "Oriol Canades"
      email: "oriol.canades@in2.es"
      company: "IN2"
      companyURL: "https://www.in2.es/"
    - name: "Jörg Langkau "
      email: "jlangkau@nicos-ag.com"
      company: "nicos AG"
      companyURL: "https://www.nicos-ag.com/"
    - name: "and DOME project participants"

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>

latestVersion: "https://alastria.github.io/did-method-elsi/"
github: "https://github.com/alastria/did-method-elsi"
og_description: >
    A DID method for legal persons, maximising at the same time regulatory compliance, decentralisation and privacy for W3C Verifiable Credentials in the European Union.
og_site_name: DID:ELSI Method
rite:
    codeStyle: github

localBiblioFile: "localbiblio.yaml"
---

<section #abstract>
    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.

    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 `did:elsi` can be used when 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, contract signing processes, or in general when presumption of non-repudiation is required).
    
    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).

    <x-warning>
        <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.

        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. 

    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.

    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).

    With those other did methods, creating the supporting trust framework is complex and cumbersome and requires additional trusted third parties if a high level of legal certainty is required. `did:elsi` leverages the existing eIDAS trust framework, so nothing additional is required and credentials and transactions using them have the same status as any other types of documents using the eIDAS framework.

    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.

<section>Introduction

    <section>Preface

        The `elsi` 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]]

    <section #conformance>
        <!-- This section is filled automatically by ReSpec. -->

    <section>Examples

        Some example DIDs are the following:

        <ul>
            - 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`

        The corresponding DID Documents are described later in this document.

<section>The did:elsi format

    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 `organizationIdentifier` field which is used in the eIDAS certificates for legal persons as defined in [[ETSI-LEGALPERSON]].

    The ABNF for the key format is described below:

    <x-code .abnf>
        did-key-format := did:elsi:<organizationIdentifier>

    <section>About the <code>organizationIdentifier</code>

        The [[ETSI-LEGALPERSON]] standard states the following about the `organizationIdentifier` field in the digital certificates for legal persons:

        <blockquote>
            The subject field shall include at least the following attributes as specified
            in Recommendation ITU-T X.520:

            <ul>
                - countryName
                - organizationName
                - <strong>organizationIdentifier</strong>
                - commonName

        And regarding the `organizationIdentifier` attribute it says:

        <blockquote>
            The `organizationIdentifier` 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.

        And the document referenced, [[ETSI-CERTOVERVIEW]] states:

        <blockquote>
            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:

            <ul>
                - 3 character legal person identity type reference
                - 2 character ISO 3166 [2] country code
                - hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)) and
                - identifier (according to country and identity type reference)

            The three initial characters shall have one of the following defined values:

            <ol>
                - `VAT` for identification based on a national value added tax identification number.

                - `NTR` for identification based on an identifier from a national trade register.

                - `PSD` 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.

                - `LEI` 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'.

                - 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).

            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.

        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 `organizationIdentifier` attribute can be used to derive a DID for a legal person from the ETSI standard identifier by applying the rule described above.

        Some examples of DIDs are:

        <x-code .ini>
            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

    <section>Proving control of the DID

        When sending and receiving Verifiable Credentials, a legal person may be required to prove that it controls a DID included in the Verifiable Credential.

        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.


<section>DID method operations

    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.

    <section>Create

        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 `organizationIdentifier` in the certificate used to sign or seal. No further actions are required.

        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.

    <section>Read (Resolve)

        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 `verificationMethod` property.

        Reading a `did:elsi` value consists on deterministically expanding the value to a minimalist DID Document, like the following:

        <x-code .json>
            {
              "@context": [
                "https://www.w3.org/ns/did/v1"
              ],
              "id": "did:elsi:exampleOrganizationIdentifier",
            }

        It may be surprising to see a DID document without a `proof` section, but in the case of this DID it is not required (even though implementations may choose to return DID documents including it).

        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).

        Section <a href="#didresolution"></a> describes the verification of those credentials and why a `verificationMethod` property in the DID document is not required.

    <section>Update

        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.

    <section>Deactivate (Revoke)

        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.

<section .informative #didresolution>DID resolution and the verification of Verifiable Credentials

    The main use case for this DID method is to use `did:elsi` identifiers in W3C Verifiable Credentials signed using JAdES digital signatures [[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.

    <section>JSON Advanced Electronic Signatures (JAdES)

        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.

        [[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.

        Essentially, JAdES specifies a JSON [[RFC8259]] format for AdES signatures (JAdES signatures) built on JSON Web Signatures (JWS) as specified in [[RFC7515]]:

        <ul>
            - 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.

            - 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.

    <section>Validation of the signature of Verifiable Credentials

        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.

        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).

        The algorithm [[DEP-DSS]] focuses on determining 3 sub-conclusions:

        <ol>
            - Whether the certificate is qualified
            - What is the type of this certificate
            - Whether the corresponding private key is protected by a QSCD.

        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.

        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.

        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.

<section .informative>Security and privacy considerations

    <section>Security considerations

        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.

        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>.

    <section>Privacy considerations

        This DID method is only for legal persons. Natural persons MUST not use it, due to privacy considerations.

        For legal persons, this DID method does not add any privacy consideration to the ones managed in the eIDAS framework.

        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:

        <ul>
            - 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.

            - 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.

            - 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.

            - 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.


<section .informative>Example: `did:elsi` and onboarding with Verifiable Credentials

    A common problem in ecosystems like Data Spaces is how organisations can onboard the ecosystem in a trusted and automated way, avoiding manual paperwork.

    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.

    This section describes how the process of onboarding can be performed by an employee of an organisation, who has been appointed to do so by a legal representative of the organisation using eIDAS certificates and Verifiable Credentials.
    
    The appointed employee will perform the process by using a special type of Verifiable Credential called `LEARCredential` (from <b>L</b>egal <b>E</b>ntity <b>A</b>ppointed <b>R</b>epresentative).

    Any Verifier that trusts the eIDAS Trust Framework will be able to verify that:

    <ul>
        - <b>The person presenting the LEARCredential is the same as the one identified in the credential</b>
        - <b>A legal representative of the organisation has attested that the person has the powers described in the credential</b>

    This enables the person presenting the LEARCredential to start the onboarding process and also to provide any additional required documentation, preferably as additional Verifiable Credentials to enable automatic verification of compliance with the onboarding requirements (including Gaia-X credentials issued by the Compliance Service of Gaia-X). 

    <x-note>Detailed example of onboarding with the LEARCredential
        To see a much more `detailed` description of the LEARCredential, its issuance process and its usage for authenticating in an onboarding portal, see <b>[[[DID-ONBOARDING]]]</b>.

    <section>A little bit about onboarding

        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).

        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.
        
        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.

        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.

        To facilitate the descriptions later in this document, we reproduce here some relevant definitions taken from the eIDAS Regulation:

        <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.

        <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.

        <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.

        <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.


    <section #typesofcertificates>Types of certificates for onboarding

        `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).

        Based on the eIDAS regulation, some TSPs (Trust Service Providers) in the EU provide several types of certificates for electronic signatures and seals:

        <ul>
            - <b>Natural Person</b> certificate for electronic signatures
            - <b>Legal Person</b> certificate for electronic seals
            - <b>Natural Person as Legal Entity Representative</b> certificate for electronic signatures

        <aside .note title="electronic signature vs. electronic seals">

            <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>.

            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.

            <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).

            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>.


    <section>Some terminology

        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.

        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.

        To facilitate the explanation below, we will use the following terminology:

            <ul>
                - <b>NP</b>: Natural Person holding a certificate for electronic signature.
                - <b>LE</b>: the Legal Entity that is being onboarded, holding a certificate for electronic seal.
                - <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.

        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:

            <ul>
                - <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).

        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.

        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.

        <aside .note title="LEAR appointment and validation">

            Parallel to the validation of your organisation, you will be requested by the Central Validation Service to appoint your Legal Entity Appointed Representative (LEAR).

            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). 

            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:

            <ul>
                - keeping an overview of all the proposals/projects/contracts your organisation is involved in
                - managing all the legal and financial information about your organisation
                - managing the access rights at organisation-level (and read-only access at project-level)
                - appointing the persons which will be able to electronically sign grants/contracts (Legal Signatories — LSIGNs) and cost claims/invoices (Financial Signatories — FSIGNs).


    <section>The LEARCredential

        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:

        <ul>
            - <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.

            - <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.

            - <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.

                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.

        
        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>.


        <section>Claims about the subject

            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.

            <figure #lear-appointment-letter-1>
                <img src="images/lear-appointment-letter-1.png" alt="" />

                <figcaption>LEAR subject identification data.

        <section>Roles and duties

            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.

            For illustration, the following figure shows some of the roles and duties in our LEAR example.

            <figure #lear-appointment-letter-2>
                <img src="images/lear-appointment-letter-2.png" alt="" />

                <figcaption>LEAR roles and duties.

            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.

        <section>Further delegation of powers

            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:

            <figure #lear-appointment-letter-3>
                <img src="images/lear-appointment-letter-3.png" alt="" />

                <figcaption>Further delegation of LEAR roles and duties.

        <section>Proving control of the LEAR Credential

            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.

            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).

            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.

        <section>Signing of the LEARCredential

            The LEARCredential must be signed by the issuer using either a LE certificate or a LER certificate, following the JAdES format specified in [[JAdES]].

            The issuer should be identified in the credential using the `did:elsi` method.


    <section>The identification and verification phase

        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.

        This can be done fully automated and without requiring a previous relationship among the new participant and the onboarding service, enabling self-onboarding.

        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>.

<section .informative>Relationship with some other DID methods

    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.

    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.

    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:
    
    <ul>
        - `did:key` for natural persons
        - `did:web` for machines (servers, sensors, ...)

    The next section provides some reasoning on why `did:web` is not adequate for the same use cases as `did:elsi`.

    <section>Comparison with `did:web`

        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).

        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).

        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:

        <ul>
            - 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.
            - 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.

        Furthermore, the need to access the web server to get the DID document and the embedded eIDAS certificate presents additional problems:

        <ul>
            - 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.
            - 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`.



<section id="references">