Copyright © 2023 the document editors/authors. Text is available under the Creative Commons Attribution 4.0 International Public License

This is a DID method for legal persons, 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 legal certainty, scalability, privacy and eIDAS compliance. 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 JAdES digital signatures with Verifiable Credentials, and so it 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).

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.

Introduction

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

Examples

Some example DIDs are the following:

The corresponding DID Documents are described later in this document.

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: 

did-key-format := did:elsi:<organizationIdentifier>

About the organizationIdentifier

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

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

  • countryName
  • organizationName
  • organizationIdentifier
  • commonName

And regarding the organizationIdentifier attribute it says:

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:

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:

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

  1. VAT for identification based on a national value added tax identification number.
  2. NTR for identification based on an identifier from a national trade register.
  3. 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.
  4. 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'.
  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).

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

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

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

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.

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:elsiidentifier, 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.

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: 

{
  "@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 describes the verification of those credentials and why a verificationMethod property in the DID document is not required.

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.

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.

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.

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

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:

  1. Whether the certificate is qualified
  2. What is the type of this certificate
  3. 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.

Security and privacy considerations

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 eSignature building block of the Digital Europe Program.

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:

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 LEARCredential 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 Legal Entity Appointed Representative).

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

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

A little bit about onboarding

The word onboarding 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:

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

Person identification data 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.

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

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

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:

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:

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:

Instead of using traditional X.509 certificates, we require that the LEAR receives a special type of Verifiable Credential called LEARCredential 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.

The LEARCredential

The LEARCredential can be generated in different ways, using the different eIDAS certificates described in section and the Trust Service Providers:

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: LEAR APPOINTMENT LETTER.

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.

LEAR subject identification data.

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.

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.

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:

Further delegation of LEAR roles and duties.

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.

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.

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 Gaia-X Compliance Service.

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:

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

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:

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