EBSI Issuers Trust Model

July 2022
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
05. EBSI Trust Models explained – Index
What are you going to learn in this chapter?

What are the How does EBSI’s Issuers What are the benefits of
most common Trust Trust Model work? EBSI’s Issuers Trust
Models of Issuers? Model?

What is the approach to

pilot Verifiable
Credentials Use Cases?
What are the most common Trust
Models of Issuers?

4
The classical trust model for Issuers
Classic solutions often require Verifiers to contact Issuers in order to ensure that the information they receive from Holders can
be trusted. This pattern is called “phoning home”.

Issuer Holder Verifier

Issuance of Presentation of

Credential Credential

Phoning Home
5
The “Phoning Home” problem
The need to “phone home” creates several challenges.

Technical burdens Operational burdens Privacy challenges

It places a technical burden on the It requires the Verifier to create and maintain It causes privacy challenges
credential Issuer, who needs to create calls to all those APIs from every credential because it provides a way for
and maintain APIs available to Issuer. In an open credential ecosystem, this issuers and Verifiers to correlate
Verifiers and ensure that connectivity could involve hundreds or thousands of an identity holder’s usage of a
is available 24x7. integrations for every relying party. credential across domains.

6
A new trust model for Issuers
According to EBSI’s Verifiable Credentials model, EBSI enables Verifiers to trust Issuers without “Phoning home”. Instead,
Verifiers can retrieve the information required to trust Issuers from EBSI’s ledger. This chapter provides detailed information
about how this is achieved.

Issuer Holder Verifier

DID
Issuance of Presentation of

Credential Credential

Ledger

7
Conceptual Trust Models of Issuers that avoid “phoning home”
There are three basic Trust Models of Issuers of Verifiable Credentials, these models can be combined.

Scalability, flexibility and interoperability

Centralised Trust Model Federated Trust Model Distributed Trust Model

For example: For example: For example:

Certificates e.g. managed PKI Trusted Lists (*) Ledger

Public Keys of Issuers

Registry of Issuers

Trusted Schemas Registry

The eIDAS Regulation introduced the concept

of Trusted List and the Commission
Implementing Decision (EU) 2015/1505
specifies its technical specifications:
https://europa.eu/!GRyHFF

8
How does EBSI’s distributed Trust Model compare to others?
Trust models relevant in a C2G or C2B setting.

Centralised and Federated EBSI’s distributed trust

trust models usually rely on model leverages
X.509 Certificates blockchain and DIDs
This is hierarchical and not that flexible, as The use of DIDs alongside blockchain enables
it requires many roles: decentralisation and greater flexibility. Only two
roles are required:
• Certificate Authority (CA) which stores, issues
and signs the digital certificates. • Trusted Accreditation Organisation (TAO)
verifies, accredits and manages the entities,
• Registration Authority (RA) which verifies the i.e. Trusted Issuers, that issue electronic
identity of entities requesting their digital documents.
certificates to be stored at the CA.
• Trusted Issuer (TI) is responsible to issue
• Validation Authority (VA) which can provide certain types of electronic documents and
information for validation on behalf of the CA. to manage their signing keys with the support
of blockchain. In technical terms, it manages a
• Distribution Authority (DA) which is responsible DID document.
for the distribution of certificates.

9
How does EBSI’s Issuers Trust
Model work?

10
Key actors of EBSI’s Issuers Trust Model
What are the key actors of EBSI’s Issuers Trust Model?

Accredits Issuers

DID DID
Registers schemas of Verifiable Registers Verifiable Accreditations
Credentials

Trusted Accreditation EBSI Ledger Trusted Issuers (TI)

Organisation (TAO)
EBSI a cts as a public registry of Issuers, containing the list of The legal entities authorised to issue
TAOs a re the organisations responsible for accrediting certain types of credentials, e.g. A
Trusted Issuers, of a s pecific s ector/ domain in a trusted Legal Entities that are accredited by TAOs to issue
certain types of credentials. In other words, accredited uni versity is trusted to i ssue diplomas
s pecific geography, to i ssue certain types of Verifiable a ccording to a specific Trusted Schema.
Credentials (VCs). entities become Trusted Issuers via a simple accreditation
process.
For exa mple, i n the education domain, the Ministry of
Education of a Country i s responsible for accrediting For exa mple, i n the education sector, i n a ddition to the DID
the Universities of that country. TAOs a lso register the documents of registered Universities, EBSI makes available
Trusted Schemas associated to the Verifiable to Veri fiers the accreditation given by a TAO, i tself a
Credential, e.g. Di ploma. Veri fiable Credential, a nd the l ink to the associated Trusted
Schema.

Furthermore, EBSI also makes a vailable the schemas of the

Verifiable Credentials. A s chema supports the verification
process and ensures that Issuers respect the agreed data
models defined by each domain.

11
How to establish trust between Issuers and Verifiers?
Understanding trust establishment in EBSI where numbers explain the sequence of events

TAO Issuer Holder Verifier

DID DID
Issuance of Presentation of

Verifiable Credentials Verifiable Presentation

3
Storage in
Accredi ts
5
Digital wallet

Upon receivi ng a Verifiable

Credential from a Holder, Verifiers
Regi sters have real-time access to – the
4 Regi sters DID
Veri fiable Accredi tation gi ven to the Issuer
document
Accredi tation - the DID document of the Issuer
(conta ining its public keys)
2
- Information a bout the schema of
Regi sters Schema of the Veri fiable Credential
Veri fiable 1 Ledger
Credential

Public Keys of Issuers

Registry of Issuers

Trusted Schemas Registry

12
 Issuers can then manage their keys independently of the TAO
Once accredited, EBSI enables Issuers to manage their keys, according to EBSI’s DID method, independently of the TAO

DID
By rota ti ng/updating keys frequently, Issuers minimise the impact of an eventual compromise of their (private) key as less Verifiable Credentials will be signed with the
same key. Techni cally s peaking, the use of DIDs and DID documents enables Issuers to rotate their keys, i .e., to update their cryptographic keys regularly (e.g. every other
month) without i mpacting the Verifiers as they ca n easily retrieve the right version of the DID document from EBSI. This enables a much smoother and secure
management of keys in large ecosystems. Is s uers 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"
] ] ] ] ] ]
} } } } } }

1 Public Key 2 Public Keys 3 Public Keys 4 Public Keys 5 Public Keys 6 Public Keys

In this case, the Issuer decides to update its keys every other month. This is done by registering a new version of the (Issu er’s) DID document on EBSI. Each version will therefore
contain an additional public key. The Verifier knows the DID of the Issuer and therefore it can resolve the latest DID Document from EBSI with the updated keyp air.
13
What is registered on the EBSI ledger?
What is registered on the EBSI ledger?

Registry of Issuers Trusted Schemas Registry

Trusted • DID and DID Document of TAO • Accreditation Credential schema –

• TAO’s Verifiable Authorisation describes data model for:
Accreditation
• TAO’s Verifiable Accreditation • Organisations they are allowed to
Organisations (including reference to DID, applicable accredit;
(TAO) jurisdiction & organisations they are allowed • Applicable jurisdiction;
to accredit for which VC(s), and corresponding • type of Verifiable Credential.
schema(s)).

Trusted Issuers (TI) • DID and Document of Trusted Issuer • Verifiable Credential schema – describes data
• Issuer’s Verifiable Accreditation model for:
(including reference to DID, VCs they are Verifiable Credentials they are allowed to
allowed to issue and applicable jurisdiction, issue.
and corresponding schema). Note: the VC schema is determined at Use
case/policy level.
How to setup EBSI’s (multilevel) Issuers Trust Model?
Example: Education domain in Member State X

Level 1
Set-up of root TAO
Member State
EBSI Service Desk
Organisation

Request TAO to be authorised to issue accreditations in Authorises TAO to issue accreditations in the
the Education domain in a given country Education domain in the given country

Ministry of Education
(root TAO)

Level 2
Set-up of sub-TAOs
Accredits a (sub-)TAO to Accreditation Body
issue accreditations to for HEI* Accredits to Accredits to
Universities (sub-TAO) issue issue
Diplomas Diplomas
Level 3
Set-up of Issuers
Accredits Issuers to issue HEI A University A University B
Verifiable Credentials
e.g. Education Credential
and student ID
Issues a Issues a Issues a Issues a
diploma student ID diploma diploma
to a student to a student

Verifiable Student Verifiable Verifiable

ID Diploma Diploma

* Higher Education Institution 15

Workflow associated to Level 1 - Set-up of root TAO
Onboarding of root TAO

Step 1 Step 2 Step 3 Step 4

Request registration Crea te DID Is sue Verifiable Authorisation Regi ster Verifiable Authorisation

Member State
Organisation

Requests Ministry of
1
Education to be registered
as a root TAO

EBSI Service Desk EBSI Service Desk

Requests Verifiable 3a Issues Verifiable

Accreditation
3c Authorisation
Confirmation of DID 3b associated to the DID
ownership
Ministry of Education Ministry of Education Ministry of Education
(root TAO) (root TAO) (root TAO)

4 Registers Verifiable
2 Generates and registers DID
Authorisation received
and DID document
from EBSI Service Desk

16
 Workflow associated to Level 2 - Set-up of (sub-)TAO
Onboarding of (sub-)TAOs, this is optional

Step 1 Step 2 Step 3 Step 4

Defi ne Trusted Schema Regi ster Trusted Schema Crea te DID Is sue and register Verifiable Accreditation

d Use-Case Group

Defines the Trusted 1 Ministry of Education Ministry of Education

Schema(s) of the Verifiable (root TAO) (root TAO)
Credential(s)
Requests Verifiable 4a Issues Verifiable
Accreditation 4c Accreditation associated to
Confirmation of DID the DID
4b
ownership
Registers the Trusted
Schema(s) of the Verifiable 2 Accreditation Body for HEI* Accreditation Body for HEI*
Credential(s) (sub-TAO) (sub-TAO)

3 Generates and registers DID

and DID document 4d Registers the Verifiable
Accreditation received from TAO

* Higher Education Institution

17
Workflow associated to Level 3 - Set-up of Issuers
Onboarding of Issuers

Step 1 Step 2 Step 3

Crea te DID Is sue and register Verifiable Accreditation Is sue Verifiable Credential

Ministry of Education
(root TAO)

Requests Verifiable 2a Issues Verifiable Accreditation for the DID of

Accreditation

Confirmation of DID
2c University A (containing a reference to the
relevant Trusted Schema)
Holder
2b
ownership

University A (*) University A University A 3

Issues Verifiable
Generates and registers DID Registers the Verifiable Credential
1 2d
and DID document Accreditation received from
TAO

* The onboarding of HEI A and University B would follow a similar process 18

Summary of EBSI Issuers’ trust chain
Verifiable Accreditations tell us which Verifiable Credentials an issuer can issue and under which policies

B. Defines the Trus ted Schemas of

Member State A EBSI Service Desk Use Case Group B
the s pecific domain

A. Root-accreditation promotes a l egal entity i nto the first Trusted

Accredi tation Orga nisation (TAO). The registration of a Verifiable A
Authori sation starts a new trust chain. Only a uthorised Legal Entities can C. Accreditation to accredit promotes a l egal entity i nto a
a ccredit others (according to the rules a nd policies of the use case). Trus ted Accreditation Orga nisation (sub-TAO) who ca n accredit
other l egal entities, according to the use-case policies.
Trusted Accreditation
Organisations C
(root-TAO)

Trusted Accreditation
D. Accreditation to attest promotes a legal entity i nto a Trusted Issuer
D a ccredits Organisations (sub-
who ca n issue Verifiable Credentials according to the use-case policies.
TAO)

a ccredits
Trusted Issuers

i s sues Holder

Verifiable Credential

19
Technical note
On registration of Verifiable Authorisations and Verifiable Accreditations

TAO and Trusted Issuers register authorisations and accreditations on

Step I
Pres ent Verifiable
Trusted Accreditation Authori sation or
Accredi tation d Authorisation API
Organisation (TAO) or Trusted API: /authorisation/v2/siop-
sessions
Issuer (TI) Step II
link
Receive access
token

d Trusted Issuers Registry API

Step III API: trusted-issuers-
Si gn blockchain registry/v3/jsonrpc
tra nsaction Step IV
Submi t the signed Method: insertIssuer,
tra nsaction with a ccess updateIssuer
token link

20
What happens when the trust chain is set up?
Once the chain is set-up, EBSI enables Verifiers to easily verify whether the Issuer of a VC can be trusted

Trusted Issuers Register

Verifiable
Accreditation
Holder Verifiable Credential(s)
references

Verifiable Presentation Contains one or

more (Cryptographically)
creates
bound to the holder
references
Issued and signed by
the holder E-sealed or signed by
issuers Trusted Schemas Register
references

Schema

21
What are the benefits of
the EBSI Issuers Trust Model?

22
 A design that supports multiple trust-chains with use-case specific
structure and policies

EBSI has support for

Trusted Accreditation Issuer(s) Trusted Accreditation Issuer(s)
multiple trust-chains
Domain: Education Domain: Social Security

As explained in the example Accredits one or more TAOs

and Trusted Issuers, according
to the Social Security policies,
similar to the education
domain

23
Benefits of the EBSI’s distributed Trust Model
Easy to manage and to verify by design

Easy to manage Easy to verify Difficult to fake

Designed in a way that is easy to Designed in a way that is Designed in a way that
manage for the Trusted easy for many verifiers to prohibits their copying and
Accreditation Organisations easily check the authenticity duplication.
(TAOs) and the Issuers. of information.

24
Want to know more?
Key resources

Explore the Discover the Watch the

EBSI website EBSI Playbook EBSI 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
https://ec.europa.eu/ebsi