1

EBSI, explained – first edition

What are the different chapters of this first edition?

Verifiable Verifiable Decentralised Digital Identity Issuers Trust Open ID Connect Digital Wallets
Credentials Credentials in Identifiers Model for Verifiable
Explained action (DID) Methods Credentials
03. EBSI DID methods explained – Index
What are you going to learn in this Chapter?

What is a DID and why How does the DID How does the DID
two DID methods in method v1 work? method v2 work?
EBSI? (Legal persons) (Natural persons)

What is the approach to

pilot Verifiable
Credentials Use Cases?
What is a DID and why two
DID methods in EBSI?

4
What is a W3C Decentralised Identifier (DID)?
A DID is just a long string that does not provide any meaningful information about a natural or legal entity. DIDs and DID Documents are
generated by their owners with their wallet or back-office systems.

2 3

According to the W3C standard, a DID is always made of three parts:

1. the first part is always the three letters “did”.

2. the second part defines the identifier for the DID method, .
3. the third field is a completely unique random number that follows method-specific generation rules.
Why it is important?
DIDs are used to ensure the authenticity of issuers and holders in machine verifiable documents known as Verifiable Credentials (VCs).

Wallet Example of an Verifiable Credential – W3C Specification

{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://essif.europa.eu/schemas/vc/2020/v1"
],
"id": "https://essif.europa.eu/tsr/53",
"type": [
"VerifiableCredential",
"VerifiableAttestation",
"VerifiableAccreditation",
Verifiable "DiplomaVerifiableAccreditation" DID of the Issuer
Credentials in a ],
Digital Wallet "issuer": "did:ebsi:zsSgDXeYPhZ3AuKhTFneDf1",
"issuanceDate": "2020-06-22T14:11:44Z",
"credentialSubject": {
DID of the Holder
"id": "did:ebsi:zDnaeSGrMFB9kCxnPYWaeMrRyun2HLVHjDNUf76ccy4ZfHU24",

(….)
EBSI has two DID methods
What are the different DID methods supported by EBSI and why?

Designed for frequent Designed for full privacy

key rotation, DID preservation, DID documents
documents stored on EBSI only stored on the wallet
ledger
EBSI DID method EBSI DID method specification
specification v1 oriented for v2 oriented for Natural
Legal Persons Persons

7
What are the differences between the DID methods
One method is oriented for legal persons (Issuers) and the other for natural persons (Holders)

EBSI DID method specification v1 EBSI DID method specification v2

oriented for Legal Persons oriented for Natural Persons

By whom it is used? • To be used for Legal Persons (Issuers). • To be used for Natural Persons because no
information is kept in EBSI’s ledger.

How is it generated? • DID and DID document are generated by a back- • DID and DID document are generated and stored on
office application or a wallet-like application. the wallet.

Where is it recorded? • DID document is recorded on EBSI’s • DID document not recorded on EBSI’s ledger as DID
ledger. No coupling between DID and ownership can be cryptographically verifiable because it
Public Key, enabling frequent key rotation contains a JWK thumbprint of the Public Key – hence if
by Issuers. holder proves ownership of the private key, it proves
ownership of the DID.

How does it work? • Verifiers retrieve the DID document from EBSI to • The wallet includes the DID and DID document when
confirm ownership of DIDs and to verify the signature of presenting information to Verifiers or when asked to
Verifiable Credentials using the Issuer’s public key for confirm the DID ownership by Verifiers or by Issuers.
assertion.

8
 Overview of EBSI DID methods
Overview of EBSI DID methods

Issuer Verifier
a• DID Documents of Natural Persons are
provided by the wallet Verifiable Presentation
Verifiable Credential (*)

• DID documents or DIDs of Natural a

Persons are not recorded on EBSI. Private key DID document Holder

{ DID document
"@ context": "https :/ / w3id.org/ did/ v1",
"id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1",

b•
" verificationMethod": [

DID documents of Legal Entities are b DID document

{
"id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1",
"type": "Ecds aSecp256k1VerificationKey2019",
"controller": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", a
recorded on EBSI. See EBSI DID "publicKeyJwk": {
" kty" : " EC" ,
"crv" : " s ecp256k1",

method specification v1 }
"x": "n03trG -1s W idluyYQ2gcKrgYE94rMkLIArZCH jv2G pI",
"y": "6__x_vqe0nBG Yf7azbQ1_VvvuCafG 5MhhU PN vYp-Mak"

}
],
" authentication": [

c•
"did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1"

Verifiers retrieve DID Documents of

{
],
"@ context": "https :/ / w3id.org/ did/ v1",
"id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", " as s ertionMethod": [
"verificationMethod": [ "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1"

Issuers/ Legal Persons from EBSI using {

"id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1",
"type" : "Ecds aSecp256k1VerificationKey2019",
}
]

"controller": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1",

a link such as: "publicKeyJwk": {

"kty": "EC",
"crv": "s ecp256k1",
Holder public key
https://api.test.intebsi.xyz/did- }
"x": "n03trG -1s W idluyYQ2gcKrgYE94rMkLIArZCH jv2G pI",
"y": "6__x_vqe0nBG Yf7azbQ1_VvvuCafG 5MhhU PN vYp-Mak"

}
registry/v2/identifiers/did:ebsi:zsSgDX ],
"authentication": [
"did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1"

eYPhZ3AuKhTFneDf1 ],
"as s ertionMethod": [
"did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1"

}
] c DID document
Issuer public key

DID document
b
(*) Is suers must also be able to receive DID documents
from us er/holder wallets, a t the time of issuing
Veri fiable Credentials, to confirm DID ownership.
Let’s look back at EBSI’s DIDs
The structure is made of three parts in both methods but the DID method v2 will use a standardised way to compute
hash of a public key

1 2 3

DID method v1

DID method v2

JWK thumbprint - standardised way to

2 compute hash of a public key
The EBSI DID methods applied
The DID methods applied to the basic information exchange scenario

Issuer Holder Verifier

DID DID
Issuance of Presentation of

Verifiable Credentials Verifiable Presentation

Digital wallet

DID document including Public key

DID method v2
Set up of Issuer according to Verify Issuer’s authenticity and
EBSI onboarding accreditation status
DID method v1

Public Keys of Issuers

Register of Issuers

CRL (*)
* List of revoked keys of Issuers 11
How does it work?
Step 0. Issuers are onboarded, wallets are setup and verifiers apps created

Issuer Holder Verifier

DID DID

Verifiable Credential Verifiable Presentation

DID method v1 DID method v2

• Registration of self-issued Public

• Selects an EBSI conformant
Keys and DID (as part of a DID
wallet • No specific onboarding or set-up
document) on EBSI
• Wallet generates a DID, a Public apart from the creation of a
• Accreditation of issuers of VCs
and a Private key. All of them Verifier App that can exploit
by Trusted Accreditation
part of a DID document stored EBSI’s APIs and interact with
Authorities (TAOs)
on the wallet EBSI conformant wallets
• Registration of Issuers in EBSI’s
• Request VCs from issuers
issuer register

12
How does it work?
Step 1. Issuance of a Verifiable Credential which is then stored on an EBSI conformant wallet

Issuer 1 Holder 2 Verifier

DID DID
Issuance of Presentation of

Verifiable Credential Verifiable Presentation

What does it contain?

> The DID of the entity that issues the credential
Credential Metadata > The status of the credential (Issuance Date, Expiry date)

> The DID of the Holder of the credential

Claim(s) > The claims about the subject (What the issuer asserts about the subject)

> Digital proof to make the credential tamper-evident (One or more

Proof (signature of Issuer) cryptographic proofs that can be used to detect tampering and verify
the authorship of a credential).

13
How does it work?
Step 2. Presentation of a Verifiable Credential for verification

Issuer 1 Holder 2 Verifier

DID DID
Issuance of Presentation of

Verifiable Credentials Verifiable Presentation

What is checked?
Checks that the holder of the
DID of the Holder VC is the one presenting it

Check time of issuance, if

Credential Metadata Credential Metadata expired

Check the claims about the

Claim(s) Claim(s) subject

Check the signature of the

Proof (signature of Issuer) Proof (signature of Issuer) Issuer

Check the signature of the

Proof (signature of Holder) Holder

Check the accreditation of

14
Check Issuer’s accreditation
the Issuer
How does the DID
method v1 work?

15
EBSI DID method specification v1 for legal persons > ISSUERS
Simplified conceptual flow

Issuer Holder Verifier

Issuance of Presentation of

Verifiable Credentials Verifiable Presentation

Register DID document Get DID document from EBSI

• The Issuer creates DIDs according to EBSI’s DID scheme profile (did:ebsi:zsSgDXeYPhZ3AuKhTFneDf1).
• The Issuer also creates the cryptographic keys associated to a given DID.
• The Issuer records this information on EBSI in the form of a DID document.
• The DID document can be retrieved from EBSI by Issuers and Verifiers using a simple URL). 16
 DID method v1 enables Issuers to flexibly manage their keys and their
real-time access by Verifiers

Issuer
The use of DIDs and DID documents registered on EBSI, as defined in DID method v1. enables Issuers to rotate their keys, i.e., to update their cryptographic keys regularly
(e.g. every other month) without impacting the Verifiers as they can easily retrieve the right version of the DID document from EBSI. This enables a much smoother and
secure management of keys in large ecosystems. Furthermore, issuers can have multiple active keys bound to their DID.

January February March April May June July August September October November December

{ { { { { {
Version 1
"@context": "https :/ / w3id.org/ did/ v1", Version 2
"@context": "https :/ / w3id.org/ did/ v1", Version 3
"@context": "https :/ / w3id.org/ did/ v1", Version 4
"@ context": "https :/ / w3id.org/ did/ v1", Version 5
"@context": "https :/ / w3id.org/ did/ v1", Version 6
"@context": "https :/ / w3id.org/ did/ v1",
"id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", "id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", "id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", "id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", "id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", "id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1",
"verificationMethod": [ " verificationMethod" : [ "verificationMethod": [ "verificationMethod": [ "verificationMethod": [ "verificationMethod": [
{ { { { { {
"id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1", "id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1", "id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1", "id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1", "id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1", "id": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1",
"type": "Ecds aSecp256k1VerificationKey2019", "type": "Ecds aSecp256k1VerificationKey2019", "type": "Ecds aSecp256k1VerificationKey2019", "type": "Ecds aSecp256k1VerificationKey2019", "type": "Ecds aSecp256k1VerificationKey2019", "type": "Ecds aSecp256k1VerificationKey2019",
"controller": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", "controller": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", "controller": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", "controller": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", "controller": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1", "controller": "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1",
"publicKeyJwk" : { "publicKeyJwk": { "publicKeyJwk": { "publicKeyJwk": { "publicKeyJwk": { "publicKeyJwk": {
"kty": "EC", " kty": "EC", "kty": "EC", "kty": "EC", "kty": "EC", "kty": "EC",
"crv": "s ecp256k1", " crv": "s ecp256k1", "crv": "s ecp256k1", "crv": "s ecp256k1", "crv": "s ecp256k1", "crv": "s ecp256k1",
"x": "n03trG -1s W idluyYQ2gcKrgYE94rMkLIArZCH jv2G pI" , "x": "n03trG -1s W idluyYQ2gcKrgYE94rMkLIArZCH jv2G pI", "x": "n03trG -1s W idluyYQ2gcKrgYE94rMkLIArZCH jv2G pI", "x": "n03trG -1s W idluyYQ2gcKrgYE94rMkLIArZCH jv2G pI", "x": "n03trG -1s W idluyYQ2gcKrgYE94rMkLIArZCH jv2G pI", "x": "n03trG -1s W idluyYQ2gcKrgYE94rMkLIArZCH jv2G pI",
"y": "6__x_vqe0nBG Yf7azbQ1_VvvuCafG 5MhhU PN vYp- "y": "6__x_vqe0nBG Yf7azbQ1_VvvuCafG 5MhhU PN vYp- "y": "6__x_vqe0nBG Yf7azbQ1_VvvuCafG 5MhhU PN vYp- "y": "6__x_vqe0nBG Yf7azbQ1_VvvuCafG 5MhhU PN vYp- "y": "6__x_vqe0nBG Yf7azbQ1_VvvuCafG 5MhhU PN vYp- "y": "6__x_vqe0nBG Yf7azbQ1_VvvuCafG 5MhhU PN vYp-
Mak" Mak" Mak" Mak" Mak" Mak"
} } } } } }
} } } } } }
], ], ], ], ], ],
"authentication": [ " authentication": [ "authentication": [ "authentication": [ "authentication": [ "authentication": [
"did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1" "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1" "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1" " did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys-1" "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1" "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1"
], ], ], ], ], ],
"as s ertionMethod" : [ " as s ertionMethod": [ "as s ertionMethod": [ "as s ertionMethod": [ "as s ertionMethod": [ "as s ertionMethod": [
"did:ebs i:zs SgDXeYPhZ3AuKhTFneDf1#keys -1" "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1" "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1" " did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys-1" "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1" "did:ebs i:z s SgDXeYPhZ3AuKhTFneDf1#keys -1"
] ] ] ] ] ]
} } } } } }

Important Note! Rotation of keys minimises the number of Verifiable Credentials revoked
because of the revocation of the Issuer’s signing keys. 17
Revocation of Issuer’s keys
Assuming that an issuer issues 20 credentials every month, 240 credentials per year, and changes its key pair every other month.
Should a key pair be comprised, the one of March/ April, the issuer would be required to re-issue about 40 credentials when
revoking the key pair instead of the 240 credentials if the Issuer would have used the same keys during the whole year.

Issuer Holder Verifier

Issuance of Presentation of

Verifiable Credentials Verifiable Presentation

Register public key revocation Check revocation list

CRL (*)

* List of revoked keys of Issuers

 DID lifecycle of legal persons
DID lifecycle of legal persons

Creation. In the background, Registration of hash of Update of DID Registration of Update DID document Registration
by a back-office application DID document document updated DID to deactivate DID of updated
or a wallet-like application: document DID document

• Creates DID and Wallet registers hash of DID DID document is Updated DID Creation of DID DID Document
document on EBSI. To do so: updated with new document is document without any without public keys is
• Private and public key of public keys back- registered on EBSI keys in it using a back- registered on EBSI
the DID control key • DID document is shared office application following similar office application or a following similar
with EBSI so that EBSI can or a wallet-like controls at creation wallet-like application. controls at creation
• Creates an EBSI ledger check that the issuer has all application. step. step.
address derived from the private keys associated to
public key of DID control the public keys shown in the
key DID document (DID
document is not persisted).
• Creates the additional
keys and the • If all controls are passed,
the DID document is
• DID document (including registered on EBSI.
public key of DID control
key).

19
How does the DID
method v2 work?

20
EBSI DID method specification v2 for natural persons
Simplified conceptual flow

Issuer Holder Verifier

Issuance of Presentation of

Verifiable Credentials Verifiable Presentation

DID document and cryptographic

DID document and cryptographic
verification of DID possession
verification of DID possession

Verify the DID key possession

proof

• The wallet creates the cryptographic keys and derives the DID according to EBSI’s DID scheme profile V2 by encoding the Public Key
(did:ebsi:zDnaeSGrMFB9kCxnPYWaeMrRyun2HLVHjDNUf76ccy4ZfHU24) - JWK thumbprint - standardised way to compute hash of a public key.
• In the Verifiable Credential issuance process, the Holder shares the DID document (public key) and proves the possession of the DID by confirming possession of the
corresponding private key to the Verifier
• In the Verifiable Presentation exchange process, the holder shares her DID document (public key) and proves the possession of the DID by confirming possession of
the corresponding private key to the Verifier

21
Want to know more?
Key ressources

Explore the EBSI Check the EBSI Watch the EBSI

website Playbook Demo Day
https://ec.europa.eu/digital-building- https://ec.europa.eu/digital-building- https://ec.europa.eu/digital-building-
blocks/wikis/display/EBSI/Home blocks/wikis/display/EBSIDOC/EBSI+Ve blocks/wikis/display/EBSI/EBSI+Demo+
rifiable+Credentials+Playbook Day
Annex

23
Key acronyms and terms used in this document
Key acronyms and terms used in this document

• Decentralised identifier (DID): A portable URL-based identifier, also known as a DID, associated with an entity. These identifiers are most
often used in a verifiable credential and are associated with subjects such that a verifiable credential itself can be easily ported from one
repository to another without the need to reissue the credential.
• Decentralised identifier document (DID document): Also referred to as a DID document, this is a document that contains information
related to a specific decentralized identifier, such as the associated repository and public key information.
• Issuer: A role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims,
and transmitting the verifiable credential to a holder.
• Verifiable Credential (VC): A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has
authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be
cryptographically verified.
• Verifiable Presentation (VP): Data derived from one or more verifiable credentials, issued by one or more issuers, that is shared with a
specific verifier. A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be
trusted after a process of cryptographic verification.
• Verifiable data registry: A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant
data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable
credentials.
• Verifier: A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation for
processing. Other specifications might refer to this concept as a relying party.

Source: W3C 24
Technically speaking, what is a DID document?
Every DID is matched to a single and unique DID document which can be versioned.

• Every Decentralised Identifier (DID) is associated to Example of an EBSI DID document

the Public Keys used by Verifiers for verification of {

electronic Signatures in a DID document. "@context": "https://w3id.org/did/v1",
"id": "did:ebsi:zsSgDXeYPhZ3AuKhTFneDf1",
"verificationMethod": [
• A DID document contains the cryptographic public {
"id": "did:ebsi:zsSgDXeYPhZ3AuKhTFneDf1#keys-1",
keys used to verify Verifiable Credentials. "type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:ebsi:zsSgDXeYPhZ3AuKhTFneDf1",
"publicKeyJwk": {
• According to DID method v1, Issuers must have a "kty": "EC",
Public key
DID document stored on EBSI that they can "crv": "secp256k1",
"x": "n03trG-1sWidluyYQ2gcKrgYE94rMkLIArZCHjv2GpI",
manage. "y": "6__x_vqe0nBGYf7azbQ1_VvvuCafG5MhhUPNvYp-Mak"
}
}
• According to DID method v2, Holders do not have a ], Reference to Public key
DID document on EBSI. Their DID document is "assertionMethod": [
"did:ebsi:zsSgDXeYPhZ3AuKhTFneDf1#keys-1"
stored and shared by the wallet. ]
}

25
What is a public / private key?
What is a public / private key and when it is used?

What is a public / private key? When is it used?

Public / private key cryptography uses a pair of Electronic signatures use public and private keys to
keys: enable trust between Issuers and Verifiers also
between Holders and Verifiers:
• a public key and a private key that are
mathematically related to each other (but • When created, Verifiable Credentials are signed
not associated with the DID). by Issuers (using their private key) and checked
by Verifiers (using the public key in the DID
• the private key must remain secret and document of a given Issuer) to ensure their
cannot be shared (e.g., it must stay in the integrity and authenticity.
wallet of the Holder).
• When sharing information, Verifiable
• the public key(s) used by Issuers and Presentations are signed by Holders (using their
Holders are made public in the DID private key) and checked by Verifiers (using the
document without reducing the security public key in the DID document of the Holder)
of the process. to ensure their integrity and authenticity.

26
What is a DID registrar / verifiable DID registry?
The use of DID requires an underlying registrar system which may be a distributed ledger, decentralised file system, database,
or any other form of trusted data storage. EBSI is the registrar of all EBSI DIDs.

The DID registrar is only used in DID method v1 for DID documents of Issuers.

DID Scheme and DID Method What does this ensure?

EBSI defines the DID scheme and the DID method • The uniqueness of DIDs of Issuers.
specification including how :
• Non-repudiation and immutability of the DIDs
1. Verifiers can resolve DIDs and obtain DID and DID Documents of Issuers.
Document(s) of Issuers from EBSI so that:
• Verifiers can obtain the latest version. • That the same controlling key is NOT
registering two different DIDs.
• Verifiers can obtain any previous revision
of the DID Document. • That only the controlling key of a specific
2. Verify that DIDs comply with EBSI’s DID Issuer can manage the DID.
schema.
3. Registration of DID Documents (including any
subsequent updates).
4. Deactivate DIDs.

27
What is a DID control key?
What is a DID control key, by whom it is used and why?

The DID control key is only used in DID method v1 for managing DID documents of Issuers.

DID control key is a key pair Why the DID control key is
that is used by used?
• Issuers to register, update or deactivate
The private keys of DID control keys are used to
their DID Documents (which include the
sign transactions that register, update and
public key of the DID control key).
deactivate DIDs on EBSI’s ledger. The hash of the
public key of DID control keys will always be
stored on EBSI’s ledger as part of EBSI’s ledger’s
• Natural persons do not have one because transaction. It is important to note that:
their DID document is not registered on
EBSI. • One DID control key can only manage only
one single DID.
• A DID can be managed by multiple DID control
keys.
• DID control keys MUST be used ONLY for
managing DIDs.

28
https://ec.europa.eu/ebsi