Page tree

CEF DIGITAL home page

This is a conceptual document and it is agnostic from the version of EBSI. References to EBSI are in the document to frame the conceptual vision on a specific version of EBSI due the ESSIF use case will evolve in future versions. 

ESSIF Ecosystem – Trust Framework – EBSI

Chapter Goal

The goal of this chapter is to raise awareness about the fact that ESSIF will not be a centralised platform, but an ecosystem, and to "focus" readers towards EBSI. In addition, to ensure "trust" in this ecosystem will have to be governed by a "trust framework" to which all participating parties have to adhere.

Table of Contents
 Click here to expand...

Ecosystem vs. Trust Framework

The following "vision" is key to understand how architecture/infra will support the ESSIF framework and the ESSIF ecosystem. In short, ESSIF does not have the long term target of being a monolithic SSI system, but rather a "framework" under which different complaint SSI solutions and services can be "recognised". The goal of this approach is to ensure a European cross-border, trustworthy, privacy-by-design, eco-system. This will allow Relying Parties to enter and decide which ESSIF features (i.e. ESSIF flows, ESSIF Verifiable Credential, etc.) they want to trust and rely upon for their business services (e.g. high assurance verifiable credentials if their business and applicable regulation requires, or simple, low assurance verifiable credentials when implementing a simple use case like a membership card). Allowing Trusted Issuers to come into the system and issue e.g. high assurance verifiable diplomas/qualifications or low assurance verifiable membership/discount cards. Basically allowing any digital nomad in Europe to "collect" verifiable credentials using the ESSIF Trusted ecosystem and decide himself/herself/itself when and with whom he/she/it wants to share its verifiable credentials. Note that in such an eco-system one might perfectly have different flavours of verifiable credentials (and supporting technical flows/standards) - e.g. verifiable credentials issued by member states, by sector, etc (as long as these parties stick to the Policies/Principals/Guidelines of ESSIF).

ESSIF Ecosystem

All the actors and systems within the context of ESSIF (which interact according to the rules and standards of the ESSIF Ecosystem).

see full definition in the terminology section: ESSIF Ecosystem

ESSIF Trust Framework

All policies, principals, guidelines, standards, processes, … which form the “terms and conditions” of membership and/or usage of ESSIF-services and as such ensure for all parties involved the trust levels parties can count on in the context of ESSIF.

see definition in the terminology section: ESSIF Trust Framework


The proverb “Rome was not built in a day.” is fitting for ESSIF, as SSI is an evolving technology with many opportunities to explore, and challenges to overcome. The table below describes some boundary conditions that apply. These may change as the project continues.

As such it need to be understood that in all following chapters these boundary conditions will be reckoned with, and very novel ideas using e.g. PEER DIDs are avoiding e-sealing/e-signing may not always be applied if it endangers delivery of EBSI.

Scope of EBSI

For EBSI, it was decided to use as point-of-departure the "Eva user journey" which departs from an adult European citizen that can act on its own behalf, has an identity in one country, wants to obtain a degree in another country and wants to interact with different agencies/organisations following graduation. As a result and though it is fully understood SSI can support many more use cases (incl. devices processes acting), EBSI will focus on a use case where an identity (human)  registers, obtains verifiable credentials and exchanges them with organisations he/she wants to interact with.

Note: EBSI will focus on demonstrating the described functionality. It should be clearly be understood that will the architecture/specifications will target as much as possible "production", EBSI will in no way represent a production-grade-system (with all the necessary security controls, legal certainty, etc)

Classic DIDs / Use of Ledgers

Rome was not built in one day and as such one could dream about a lot of special use cases. However it is fundamental to understand that ESSIF MVP1 will depart from classic DIDs and will be using ledgers in support. As such:

  • DIDs – or more precisely DID-documents – will be registered on a ledger. This because EBSI wishes to be able to support suspension/revocation, and in future possibly even recovery of DIDs. In this way relying parties can obtain the public keys of a DID, and also verify that a DID has not been suspended or revoked. As an example, this is seen as a way in which DIDs of official issuers like a government agency or a university could be made "resolvable".
  • The "meta-data" of Verifiable Credentials of any form (see concepts/terminology) will also be registered on a ledger. This is due to the fact that EBSI wants to be able to support suspension/revocation of issued verifiable credentials. This will allow issuers to suspend or revoke any issued verifiable credentials (e.g. detection of fraud after issuing of a diploma). This will allow relying parties to verify whether a Verifiable Credential has been suspended or revoked. 

Note: ESSIF does not intend to "register" any transactions on the ledgers. Only the elements stated above will be registered "on ledger".

Note: At the time of this writing and wrt the supporting building blocks (see below), it is yet to be decided which ones could be in itself be based on ledgers (e.g. the  trusted issuers list) and which will for the sake of speedy deliver by based on e.g. standard / non-distributed repositories.

Secure Communications

When parties interact, the first action is the setup of a secure communication channel. To avoid inventing something new, EBSI will use a classic and well-established certificate-technology. Issuers / Relying Parties will have to identify/authenticated themselves using TLS-certificates. Following identification/authentication, this will allow the parties to establish of a secure (mutual) TLS-connection.

Note: While, for example, the use of QWACs might be envisaged in the longer term (and will therefore be foreseen in the architecture / data model), EBSI will allow for the use of simple EBSI test-certificates.

Identification / Authentication

It is assumed that in EBSI, and therefore ESSIF, all parties (users, issuers, relying parties) will register one or more DIDs, and corresponding DID-keys. However, the DIDs and DID-keys in themselves will not give any guarantee as to the identity of a party in any of the flows. When requesting a verifiable credential, the "identity" will have to be divulge therefore (some of) its identity. This is for the party to decided upon if it wants to divulge its real identity (or part of it) at that moment in time. Several methods for identification will be foreseen in EBSI (physical onboarding, eIDAS-type of identification/authentication, usage if a verifiable ID). 

In the above, the element of authentication is also mentioned. Indeed, a party might pass a thoroughly verified identity but might be using a very weak authentication method. It is therefore vital that ESSIF also includes different levels of physical/logical authentication. An example of this is a strong verification that would require and a high LoA identity of the party and the ability to authenticate the party using a strong authentication (or signing) method.

Note: In the world of SSI (classic DIDs) identification/authentication will also require that the DID-keys are the same "strength". If this is not the case, verifiable credentials linked to a DID will be "weakened".

Trust / Legal Certainty

Trust and legal certainty in ESSIF will depend on whether the verifiable credential(s) can be relied upon. This requires well-understood levels of assurance and trusted issuers.

Wrt level of assurance:

The level of assurance of a verifiable credential will depends on the identification/authentication of the requester, on the checks that the trusted issuer will make, and on the trust-levels of the issuer itself.

In short, ESSIF will "by design" have to foresee LoAs of different levels (low, substantial, high).

Wrt trusted issuers:

Whether an Issuer is Trustworthy depends on multiple elements (not limitative): 

  1. Is the issuer itself trustworthy/recognised?
  2. Is the issuer allowed to issue this type of verifiable credential?
  3. Is the issued verifiable credential legally valid?
  4. Can the relying party verify (e.g. by checking an e-seal) what level of legal assurance the presented verifiable credentials  constitute?

Note: EBSI will consider all of these elements for its setup/architectural specifications, but – not being a production system – will in no way ensure already high assurance verifiable credentials.

Privacy / Continuity

Clearly, ESSIF will incorporate "data protection" into its core. For this reason, only required information will be stored "on ledger" as part of the SSI-functionality (see "Classic DIDs / Use of Ledgers" above.)

By design, ESSIF will also ensure that it will be able to support "rekeying of DIDs" and "recovery of DIDs".

Functional and User Experience

EBSI will support generic SSI-flows (as supported by classic DIDs) and more specifically, focus on the "Eva journey". In this context it will also cater to:

  • the ability to "enrich" a digital identity with true identity data and link with, for example, the e-seal-certificate being used by the party (see verifiable IDs and technical specifications/foundation);
  • the ability to interact between different DID-methods and DID-domains, and the ability to interact between different VC-schemas and VC-domains.

Note: EBSI will allow identities to register multiple DIDs. It is out of the scope of the architecture track to define guidelines for users on best practices for generating new DIDs versus reusing their existing DIDs. (e.g. using one DID relating to a user´s official identity for interactions with government agencies, banks, and insurers. For example, using a different identity to accessing social media platforms or showing one's membership to a sport-club.)

Technical / Complexity

EBSI will support generic SSI-flows (as supported by classic DIDs) and more specifically, focus on the "Eva journey". In this context it will also (not) cater to:

  • EBSI will ensure the user can use a personal data-store which can be hosted locally or remotely
  • EBSI will avoid complex cryptography and unverified and tested advancements in SSI (like peer DIDs)
  • EBSI will try to apply existing available open source libraries as much as possible

The SSI Paradigm and SSI Business Case

Chapter GoalThe goal of this chapter is to derive and define the core/fundamental functions that have to be foreseen at the level of the ESSIF Framework and ESSIF architecture/infrastructure. This, as to ensure it will deliver targeted added value moving forward. In this context this chapter will also clarify what ESSIF will (not) provide.

From Centralised to De-centralised

One could argue that SSI will help to “break” the power of the identity providers, but is this really the case?  Or is it just another way of doing things (worse moving control from the identity providers to wallet providers)?

How SSI will be different

SSI will only function and become the standard if it demonstrates significant added value for both relying parties and service providers. This, as PKI already solved identification/authentication (whereby the "subject" could already decide where (not) to use his credentials(s)) and as federation already solved (controlled) attribute sharing (with the downside that these identity providers became in certain cases almost the controllers of a user's identity).

ESSIF Features and Properties

SSI in general, and ESSIF specifically, will provide added value moving forward, whereby it in certain situations will clearly co-exist with above-mentioned PKIs and identity-providers / federated eco-systems.

This as, in general terms, ESSIF will provide following added value:

  • Support self-sovereignty (aka user-control of what is shared with whom) and therefore “privacy by design” (aka pseudonimity/anonymity where required)
  • Allow the subject to connect  with multiple Issuers (and related ledgers)) and not being obliged to share everything with a (few) identity providers
  • Allow to be more distributed (avoiding the need for "heavy" federations between relying parties and identity/attribute providers)
  • Enable the sharing of more the "basic" identity information but also claims/attestations like diplomas, bank account-info, insurance attestations and other potentially privacy-sensitive information.

Whereby ESSIF should / will :

  • co-exist with PKIs where needed (cfr usage of QWACs, QeSeals, potentially QeSigs) 
  • integrate with existing federating setups at the side of relying parties (who then could accept verifiable credentials from multiple issuers instead of only from some "centralistic" identity providers)

Note that in addition and as an "advanced feature":

  • ESSIF will also enable a party more easily to demonstrate he/she/it can “act on behalf of” another natural person or a legal entity

Resulting Target View

ESSIF is to allow an EU entity (often a citizen but not limited to citizens) to interact with relying parties and to “present” those his/her/its Verifiable Credential(s). Note that these Verifiable Credentials come in different types (see concept/terminology): en EU entity might provide a Verifiable ID (proving his/her/its eIdentity), potentially his/her/its Verifiable Mandates/Consents (as to proof he/she/it can act “on behalf of”) and any required additional  Verifiable Attestation (e.g. a diploma, a permit, …)

In EBSI, ESSIF will concentrate on the following flows/features:

  1. Registration of one's digital identity  (aka DID-registration)
  2. Issuance of Verifiable IDs (to proof one's eIdentity (or part of))
  3. Issuance of Verifiable Attestations (aka some type of diploma by universityX)
  4. Passing Verifiable IDs and Attestations to a Relying Party.
  5. Verification by Replying parties of mentioned verifiable credentials

In / Out of scope

Mind that ESSIF will NOT intervene in the business flow between the EU citizens/entities and relying parties. Requesting of services and obtaining of those services are out-of-scope of ESSIF.  Note that requesting of the issuance of a verifiable credential is also "requesting a service".  ESSIF will not describe how / using which systems an Issuer should do all necessary checks to issue a verifiable credential as this are context specific. ESSIF will however need to specific a trust framework what types of checks need to be done as to be able to claim a certain LoA for the issued credential.

ESSIF will therefore "limit" itself to specifying how an EU entity can “obtain” Verifiable Credentials which then can be use to identify/authenticate towards relying parties and provide those relying parties with requested claims/attestations. In addition ESSIF will specify which services it relies on from the EBSI infrastructure (like ledgers, like supporting referentials)

In EBSI, ESSIF will concentrate on:

  1. issuance / Exchange / Verification of Verifiable IDs
  2. Issuance / Exchange / Verification of Verifiable Attestations
  3. Supporting DID-flows  and Ledger registrations
  4. Supporting service-interactions (including referentials and authentication services)

Resulting “Relying Party” Functional Use Cases

Though parties can have different "roles" at the same time, EBSI will have the following basic user stories (which will be elaborated in the detailed ESSIF technical specifications) from a relying party perspective:


  • Verify / Authenticate Relying Party
    (to establish secure communication path)

  • Identify / Authenticate towards Relying Party
    (physical representation, classic authentication, using verifiable ID)
  • Create / Forward Verifiable Presentation
    (in support of authentication flow or submission of forms)

Relying Party:

  • Identify/Authenticate User
    (physical representation, classic authentication, using verifiable ID)
  • Verify Verifiable Presentation
    • Verify Verifiable ID and/or Verifiable Attestation
    • Verify corresponding eSeals (where applicable)

Note:  cfr 2.5 - EBSI will of course also require the listed supporting flows / interactions (including whether DIDs or VCs have been suspended/revoked/replaced).

Note2: in EBSI the reliability of the secure communications will heavily depend on the security of the set-up TLS-communications and the reliability/trustworthiness of the presented verifiable credentials will heavily depend of the LoA under which the VCs (forwarded inside a VP) have been issued and possibly the presence of an eSeal where required for the business use case.

Resulting “Issuer” Functional Use Cases

Though parties can have different "roles", EBSI will have the following basic user stories (which will be elaborated in the detailed ESSIF technical specifications) from a relying party interaction use case:


  • Verify / Authenticate Issuer
    (to establish secure communication path)

  • Identify / Authenticate towards Issuer
    (physical representation, classic authentication, using verifiable ID)
  • Request Verifiable Credentials:
    • Request Verifiable ID
    • Request Verifiable Attestation


  • Identify/Authenticate User
    (physical representation, classic authentication, using verifiable ID)
  • Issue Verifiable Credential
    • Issue Verifiable ID and/or Verifiable Attestation
    • Attach (if needed) eSeal onto VC

Note:  cfr 2.5 - EBSI will of course also require the listed supporting flows/interactions (including whether DIDs or VCs have been suspended/revoked/replaced).

Note2: in EBSI the reliability of the secure communications will heavily depend on the security of the set-up TLS-communications and the reliability/trustworthiness of the issued verifiable credentials will heavily depend of the LoA under which the VCs have been issued and possibly the presence of an eSeal on those VCs where required for the business use case.

Key Required Concepts for ESSIF

Goal of this chapter

Goal of this chapter is to define the core / fundamental concepts and principals that have to be “in the DNA” of the ESSIF Framework and present in the ESSIF architecture/infrastructure. Indeed an eco-system can not exist if there is no interoperability at different levels, not at the least at the level of concepts/semantics.

ESSIF Concepts and relationships

For ESSIF to work and be able to support multiple use-cases the following concepts will have to be supported (Mind that the main items are being listed here - but we refer to 2.4 Terminology for more details).

The following diagrams are an intro to the business/functional concepts and architecturally/technically concepts which are key for ESSIF.

The first diagram as shows the business/functional concepts ESSIF will need to support, as well as the architecturally/technically concepts that ESSIF will rely upon moving forward, as well as the relationships between them (more info on each of these concepts below). In short:

  • every entity needs one or more Digital Identities. Each Digital Identity it can assume must have a unique Digital Identifier. In the world of ESSIF each digital identity a party can assume will have a unique DID.
  • an issued claim about a digital identity will --in the world of ESSIF-- be expressed by means of a Verifiable  Credential. We need to mind however that for functional/legal reasons such a verifiable Credential can express: a) a Verifiable ID (if one wants to provide certain attributes of the entity allowing to identify/authenticate the entity beyond the DID), b) a verifiable consent/mandate (if one needs to prove that an actor can act "on behalf of" a(nother) party, c) a verifiable attestation (if one wants e.g. to be able to express some information "beyond" digital identity info of an entity - e.g. diploma information).


The second diagram shows the relationship between the key concepts in ESSIF  as to help the reader to understand their relationships:

  • any entity has one or more Digital Identities (with corresponding DIDs) under ESSIF
  • every Digital Identity can have different kinds of verifiable credentials attached to it  (aka verifiable IDs, verifiable mandates/consents, verifiable attestations).

Note: the above drawn "DID-card" is introduced in the context of the need to be potentially able to recover a DID for a party which lost its DID or ability to proof its ownership.
Needless to say it is vital that such a recovery process must be very rigid, under control of a trustworthy DID-custodian and should protect the DID(-keys) against compromise or impersonation.

ESSIF Concepts explained

The below is an excerpt of the main concepts as listed under 2.4 Terminology. The full description and definition of these concepts can be found at the

EBSI Terminology page

ConceptShort DescriptionESSIF EBSI *
ESSIF Digital ID

A “digital identity” (and corresponding identifier) allowing to uniquely identify an entity within the ESSIF eco-system

In ESSIF EBSI the DID-scheme will allow to uniquely register:
  • relying parties who would like to receive VCs
  • recognised issuing educational institutions
  • students who are still studying (ref Student card)
  • citizens to which a diploma was or has to be issued

A DID-card is a way to "register" a DID officially and link it in a secured/protected way (depending on the LoA) to an entity

In ESSIF EBSI the DID-recovery process will:

  • to be supported
Verifiable (Digital) ID

A verifiable ID is a special form of a "verifiable credential"  an entity can put forward as evidence of whom he/she/it is (comparable with a passport, physical IDcarddrivers-license, social security card, member-card…)

In ESSIF the following Verifiable IDs will be supported:
  • e.g. StudentID
  • verifiable IDs for issuing universities
Verifiable Consents and Mandates

A verifiable consent or mandate is a special form of a "verifiable credential" that allows the “holder” to present itself to a third party with a credential and a mandate (and claims regarding a corresponding subject).

In ESSIF no flows using mandates or consents will be foreseen.

A verifiable attestation is a special form of a "verifiable credential" that an entity can put forward as evidence of certain attributes / properties or as evidence of an permit / attestation / authorisation he/she/it received.

In ESSIF the following verifiable claims will be foreseen:
  • Verifiable diplomas
Verifiable Presentations

A verifiable presentation represents the data which is passed from an entity to a relying party (often also the verifier).

In ESSIF it must be possible:
  • to pass a verifiable studentID to a relying party
  • to pass a diploma to a relying party
Verifiable Supporting Documents

Verifiable supporting documents are any type of "annexes" to which verifiable credentials refer.

In ESSIF this feature will not yet be supported

*Proposal from within ESSIF conceptual architecture, to be discussed and aligned with EBSI architecture and Member state review.

Key Properties and Trust/Security Requirements

Goal of this chapter

Goal of this chapter is to define the trust and resilience (enabling) capabilities that have to be foreseen at the level of the ESSIF Framework and be “in” the ESSIF architecture/infrastructure. Indeed, an eco-system cannot function / thrive if parties do not understand by what principals it adheres and have a feeling / understanding of what the trust-levels are they can rely upon.

Key Architectural Principals

For ESSIF to be able to be usable / trustworthy by all parties involved, it will need to support the following principals.

Privacy by Design
Short DescriptionPart of ESSIF is the promise to ensure the privacy of the parties/users using the system to exchange their identity information and their attestations with relying parties in a self-sovereign way.
Key Properties

To support "privacy by design" ESSIF will:

  • use in principal anonymous DIDs (in principal as parties like issuers will often have to disclose their identity else e.g. diplomas would not be verifiable as coming for e.g. institution X and users can per case decide whether or not to disclose their identity).
  • only put DID-documents and VC-metadata on the ledger (allowing verification and status-validation) which do not disclose the party's real identity (unless explicitly targeted like e.g. the building up of a ledger that constitutes a list of trusted issuers)
Attention Points
  • Need for the establishment of a trust framework
  • Need for the establishment of LoAs
Legal Certainty
Short DescriptionESSIF will fail if users and relying parties do not understand the trustworthiness and legal certainty of the environment and the verifiable credentials supported by it. As such it is important to approach ESSIF as a “trust framework”
Key PropertiesTo ensure the "legal certainty" ESSIF will:
  • have to build a referential (possibly ledger) of trusted Issuers (including clearly listing which VC the respective Issuers are authorised to issue under ESSIF)
  • set rules for the identifiability / authenticability of Relying Parties
  • set rules for the LoA (levels of assurance) of issued verifiable credentials
Attention Points
  • Need for the establishment of a trust framework
  • Need for the establishment of LoAs
Short DescriptionFundamental in ESSIF is that the user can control which issuers issue verifiable credentials, mandates/consents and/or claims/attestations on his/her behalf AND that the user fully controls which relying parties can receive these.
Key Properties

To ensure "user control" ESSIF will:

  • though possible in design, not foresee issuance of credentials, mandates/consents NOR claims/attestation without the request of the user.
  • not foresee that information can be retrieved without the user “initiating” this.
  • in EBSI “by design” only allow access after authentication of the subject (using “classic credentials” or “verifiable IDs”
Attention Points

Note that a user could issue a consent to a relying party which can then retrieve information on the user's behalf (for the period the consent has been granted).

Note that ESSIF does not foresee functions like digital rights management blocking “rogue” or “compromised” relying parties to “leak” provided information to other parties.

Revocable / Timeliness
Short DescriptionNo information can last forever, certainly not a verifiable credential. Hence any issued verifiable credential must be “constrainable”.
Key PropertiesTo ensure "revocability" and "timeliness" ESSIf will ensure that:
  • A unique identifier
  • A starting and end-date
  • Additional meta-data allowing to suspension/revocation
  • As well as meta-data allowing to “replace” the “item”
Attention Points

Depending on the use case, one can potentially suffice by putting validity dates into the registered DID-documents / issued VC and the building of a “black-lists” of revoked DID-documents / VCs.

One might foresee (beyond EBSI 1) the possibility for a relying party to identify the latest available "version" of a DID-document or VC on respective ledgers.

Purpose Limitation
Short DescriptionWhen a claim (hence information) is given to a relying party, the user expects the information to be used only within the given context and not beyond.
Key Properties

To support this a “purpose limitation”, ESSIF should:

  • require adding this info to all VCs and/or VPs which are passed to relying parties. 
Attention Points

The integration of purpose limitations (beyond mere mentioning it in a verifiable presentation) requires this additional element to be modelled across relying parties and could also lead to a “relying party referential” which controls which claims relying parties are allowed to receive (which is probably to restrictive). Another option would be to introduce encryption of digital rights management which ESSIF for the time being does not foresee.

Short DescriptionA user should be able to interact with whatever relying party that he/she/it wishes to interact with and to exchange verifiable presentations of different kinds with these parties based on verifiable credentials/claims/… of different issuers.
Key Properties

To ensure extensibility, ESSIF will:

  •  require that users wallets  be able to understand DIDs and verifiable credentials from different types (supported potentially by different ledgers)
  • and/or require a "hub" that is able to "act" on behalf of a user "remotely" as to avoiding too heavy client-side code
Attention Points

Based on W3C DIDs and W3C VC’s, ESSIF should establish a catalogue of “recognised” schemes.

Legal certainty (linked to LoA’s) should at no time be lost from sight.

VC’s and DIDs need to be able to point to multiple “trusted” ledgers.

Easy to integrate
Short DescriptionTo foster adoption it is recommendable to keep the integration-cost at the side of the relying parties as low as possible. As such ESSIF should propose setup whereby relying parties can use their existing infrastructure but at the same time can consume VC’s.
Key Properties

To ensure easy of integration ESSIF should:

  • provide ways to integrate in widely used setups (like OIDC relying parties) e.g. by modelling how  “Verifiable IDs” can be passed as “ID tokens”
Attention Points

ESSIF would (at an infrastructure layer) probably have to foreseen in a “plugin-architecture” allowing wallets to "load" all plugins/policies they need for the DID- and VC-formats they require.

In addition, the Trusted Issuer List should publish which DID- and/or VC-formats authorised Issuers are using.

Key Security Requirements

For ESSIF to be considered trustworthy by all parties involved, it will need to support the following security principals.

Trusted DID (-ledgers)
Short DescriptionAll identities taking part in ESSIF will be known by their DIDs (which relate strongly with the supporting ledgers and DPKI’s). Hence the “DID registrars” and their “ledgers” are the anchors of the whole ESSIF ecosystem and must therefore be of the necessary LoA (as a too low LoA will lead to weak trust in the corresponding DID).
Key PropertiesDID registrars can be of different Levels of Assurance: low / substantial / high assurance. This LoA will be depending on the “amount of trust” the relying party can have in the DID (see attention points)
Attention Points

One should not the LoA depends on:

  • Trust-level of the DID registrar (legally, technically, etc.)
  • Identification/Authentication of performed on the DID
  • Security Posture of the DID registrar
  • Security Posture of the supporting ledger/DPKI
Trusted Issuers
Short DescriptionThe trust of the systems stands/falls with the reliance parties can have on the trustworthiness of the issuers as well as that of the relying parties. 
Key Properties

Any issuer / relying party joining the European SSI Framework should be subject to vetting. For issuers one should determine which VC’s they are allowed to issue.

In addition: for every VC it should be stated which check should be done by the issuer (taking into account the resulting/possible LoA's)

Attention Points

Issuers / Relying Parties might e.g. be registered on “Sector Ledgers” (e.g. education, health, banks, retail, …)!

One should mind the special case of Issuers of Verifiable IDs (and in future of Verifiable Consents/Mandates) as these will be fundamental for any identification/authentication.

The relationship between DID(-document)s and Verifiable IDs is subject to detailed design

Secure Communication
Short DescriptionWhen Ledgers, Issuers or Relying Parties authenticate themselves, ESSIF could consider reusing QWACs to ensure users are sure they are interfacing with trustworthy parties – especially in cases where strong identification/authentication of the issuer / relying party is needed for the “trust” of the connecting user. 
Key Properties

QWACs ensure strong identification/authentication of the parties/services the user will be interfacing with.

QWACS are well defined under eIDAS. It would be advisable however under ESSIF to add unique registration numbers + to strengthen suspension/revocation-obligations for issuing QTSPs.

Attention Points

Relationship between these QWACs and DID (linked to issuers or relying parties) is subject to detailed design.
Cfr Trusted Issuers: In some cases hiding e.g. the issuers identity or relying parties identity makes no sense (or would even be counterproductive for the overall trust in the system).

Identification & Strong Authentication
Short DescriptionUsers will have to identify/authenticate “at the required level” when accessing a service (e.g. to obtain a VC).  For this low, medium, strong authentication could be required.
Key PropertiesDifferent standards exist. Issuers can decide to use direct integration of authentication means (like e.g. in Belgium the eID-card or ITMSE) or rely on a trust-worthy federated system (e.g. CEF eID platform) or even on the use of verifiable credentials issued under ESSIF.
Attention Points

Note that in the end it will be the legal responsibility of the Issuer to “attest” the "resulting" level of assurance of an issued VC.

If a user uses a verifiable credential to authenticate, the the LoA has a direct link with the trust-level of the DID-registrar / -ledger.

Legally valid VC’s
Short DescriptionOne should consider using (Qualified) eSeals to ensure legal certainty wrt VC’s issued by Trusted / authorised Issuers where needed by respective business cases.
Key PropertieseSeals (especially QeSeals) are well described under eIDAS and can provide some legal certainty as it guarantees authenticity / integrity / non-repudiation as issued by the issuer.
Attention Points

Relationship eSeal <> DID of issuer to be investigated.

eSeals can / should be adapted to the LoA needed for the respective VC.

eSeals should not be mistaking with the signature the user would put on the VP’s (if/when needed) when it forward these to a relying party.

In cases where legal certainty is needed,  hiding the issuers identity makes no sense (or would even be counterproductive for the overall trust in / legal certainty of the system).

VC signing
Short DescriptionUsers might in some case have to proof the VP they forwarded to a relying party belongs to them (beyond standard technical signing means using DID-keys). Possibly usage of a eIDAS eSignature might come to the rescue.
Key Properties

eSignatures (especially QeSeals) are well described under eIDAS and can provide some legal certainty as it guarantees authenticity / integrity / non-repudiation as from the signer.

Attention Points

The LoA of a VP will depend on the security / trustworthiness of the DPKI (and hence the Trustworthiness of the DID-registrar / -DID-ledger)! 

The above means that the security posture of the DID-registrar / -ledger will depend on the required LoA of the forwarded VPs.

If a user uses eSignatures (on top of DID-ey based signatures) it is to be expected that the DID(-keys) should be of a same "quality".

Enterprise Architecture View - Conceptual

Goal of this chapter

Goal of this chapter is to define --based on the identified functions, concepts, principles and trust and resilience requirements-- in headlines the resulting / required ESSIF Framework and ESSIF architecture/infrastructure. For those that are eager to get more details, we refer to the materials that indeed to elaborate the technical specifications in more detail (cfr related wiki-pages).

Conceptual Overview

Below visual describes in conceptually the environment that will be required to be able to realise ESSIF EBSI as described in the previous chapters. Following chapters will then briefly describe each of the identified / required building blocks.

High-level Building Blocks

ESSIF Wallet / Agent
Short Description

An ESSIF wallet / agent will be used by a party (Relying Party, Issuer, User) to interact with the ESSIF-eco-system and via which the party can:

  • register one or multiple DIDs (using DID-registrars (and respective ledgers) it chooses),
  • interact with multiple issuers (and respective ledgers) to obtain VCs
  • interact with multiple relying parties.
Key Properties

An ESSIF wallet will have to be able to work with multiple ESSIF-complaint DID-/VC-schemes!

As such a DID-wallet will have to be able to support "plugins" (see below) that are installed locally or that can be called remotely to interact with the different schemes it needs to interact with depending on its (business) context.

Attention Points

An ESSIF wallet / agent cannot function without a registry where it can find authorised issuers
as well as their locator-information (
and their service endpoint definitions)
as well as  VCs these are authorised to issue
as well as the
corresponding DID-schemas / VC-schemas it is using

ESSIF Plugin
Short Description

An ESSIF wallet / agent must be modular and allow plugins (to support interfacing with multiple ledgers).
In addition and to support relying parties, plugins should be made 
available to allow e.g. integration in standard OIDC-setups.

Key Properties

Plugins should allow a Wallet / Agent to interact with:

  • DID-resolvers, Trusted Issuer referentials and VC-schema-referentials
  • Different issuers and relying parties using potentially different DID- / VC-schemes
  • Issuers / Relying Parties using specific protocols (like e.g. OIDC)
Attention Points

A plugin-architecture is theoretically flexible but requires quite some mapping/processing logic on the client-side.

For e.g. mobile clients one might chose to run the wallet/agent "remote" as to "offload" the mobile client.

ESSIF Ledgers
Short Description

For the European SSI Framework to work,  all parties (especially relying parties and users) must be able to interact with different ledgers as by nature ESSIF intends to support any compliant DID- or VC-scheme

Key Properties

Identified / required ledgers for ESSIF to support include (draft / not limitative list)

* DID registrars (for registration of user(-communities))
* Sector ledgers (for registration of Issuers and possibly RPs)
* VC ledgers (to store (meta)data related to issued VCs)
* …

Attention Points

Ledgers have a direct relationship to the trustworthiness / legal certainty / targeted LoA of the “linked” DID-documents/keys, verifiable credentials, verifiable mandates/consents, verifiable claims.

LoA's require that the corresponding ledgers and all building blocks supporting it (as well as the operating model) are up to the levels required by that LoA.

ESSIF Issuer Referential
Short DescriptionIt must be clear for legal certainty reasons which issuers are allowed to issue which VCs Otherwise (especially when legally required) VC’s will be null and void as to their real usability.
Key Properties

Trusted Issuer referentials should publish:

  • Which Trusted Issuer can issue which VCs
  • For each VC refer to the used schema(s)
  • For each VC clarify which is the corresponding LoA

Ideally for each VC and stated LoA also the following should be available:

  • the checks that are committed to have been done in case a VC is issued.
  • The rules wrt suspension / revocation
Attention PointsThis registry must be machine-readable / -processable as to be able to automate usage by the parties.
ESSIF Schema Referential
Short DescriptionAs to ensure parties relying on the European SSI Framework can interpret multiple schemas, ESSIF must run a referential holding all approved / trusted VC-schemas so that parties can ensure correct processing.
Key Properties

ESSIF schema referentials should:

  • apply clear schemas / attribute definitions
  • apply ESSIF guidelines wrt VC-definitions (cfr LoA-info, revocation-info, ...)
  • provide a structured catalogue with unique identifiers per VC-type/-template
Attention PointsESSIF schema referentials could be considered per domain/sector

Main High-level Interactions

  1. Registration of an ESSIF-issuer
  • Issuer prepares for operation
    • choice of issuer-ledger
    • choice of DID-ledger it wants to register on
    • choice of VC-ledgers it wants to publish VC-info to
    • prepare “authorisation request”

  • Issuer submits "authorisation request” to ESSIF (or ESSIF-delegated RA)

  • IF approved, then ESSIF registers Issuer in the ESSIF Trusted Issuer registry
    (including all required meta-data like VC authorised to issue)

  • Issuer can now register a DID and its DID-keys
    (note that this should be in line with the LoA of the VCs it will be issuing)
  • Issuer should request a Verifiable ID as to link its real identity (and possible sector/domain-specific attributes like institution-no or VAT-no with the DID)

  • Issuer can in addition request a QWAC and QeSeal from a QTSP and bind this to its Verifiable ID

  • Issuer is ready for operations.

2. Registration of an ESSIF-user
  • User installs (signed) ESSIF wallet and needed (signed) plugins

  • User decides where to register and request a DID (by choosing a party listed as authorised “DID registrar” in the ESSIF trusted issuer list.

  • Wallet connects to DID registrar.
  • DID registrar checks ownership of user’s DID and proposed DID keys.
  • DID registrar generates and registers an ESSIF-compliant  DID-document on chain.

  • The user can now also request a verifiable ID for the corresponding DID
  • He/she connects to the Trusted Issuer of his/her choice and authenticates at the required LoA (e.g. national eID in case of need for high-assurance)
  • The Trusted Issuer verifies the DID and the authenticated identity and executes whatever additional check is required for the requested Verifiable ID and does the necessary "linking".

  • The Trusted Issuer issues a Verifiable ID with the corresponding LoA (which is depending on the LoA of the Issuer, the LoA corresponding to the identity of the user, the strength/type of authentication, the check that have been done and the LoA of the user's DIDs).
  • If needed the Verifiable ID can be given an additional eIDAS-eSeal.
  • The user now has a registered DID (and optional linked Verifiable ID).

3. Requesting a(n additional) Verifiable Credential
  • User decides to request a(n additional) Verifiable Credential for an already registered DID.

  • Wallet connects to the ESSIF trusted issuer list to check if Issuer is still “white listed”.

  • The wallets sets up a secure communication with the corresponding Issuer.

  • The Issuer authenticates the user at the required LoA (in this case e.g. using a "Verifiable ID")
  • The issuer does whatever checks are required before the requested “subordinate" verifiable credential can be issued and if all is successful, issues a Verifiable Credential to the DID of the User.
  • If needed the Verifiable credential can be given an additional eIDAS-eSeal.
  • VC-metadata is registered on the corresponding ledger (to allow suspension/revocation)
  • Note that instead of requesting a VC one might "register" a mandate and request that that would be issued as VC.

4. User requesting a service from a RP
  • User decides to request access a service provider / relying party

  • The user “browses” to the relying party and checks its identity (using e.g. QWAC).

  • The relying party authenticates the user at the required LoA (e.g. relying on an accepted verifiable credential) – OPTIONALLY: When the user’s “ESSIF-wallet” pops-up to provide the VP, the wallet could checks in the ESSIF RP registry which VPs this party is “entitled to”

  • The party receives the Verifiable Credential (part of the VP) and check the DID-signature (whether it belongs to the DID that corresponds with the VP that is being forwarded). Optionally (and if required by policy) it will also check the eSeals on the VCs that were "presented".
  • The Party also check on the ledger if the VCs (part of the VP) have not been suspended / revoked.
  • If all turns out well the relying party has identified and authenticated the user in accordance to its policy and can as of now provide requested service.
  • Note: that during the identification/authentication phase the user could also present a verifiable consent/mandate showing the he/she is allowed to act on behalf of another party.

5. Relying Party Requesting additional info
  • When a party needs additional info (a claim/attestation) from an identified/authenticated user to be able to process the request, it will send a  request to provide those verifiable attestations.

  • The user's wallet will pop-up and allow the user to chose which VCs it could provide in response (helped by VC-identifiers passed by the relying party in order to help the user to pass "compliant" VCs)  -  OPTIONALLY: the user’s “ESSIF-wallet” could check in the ESSIF RP registry which verifiable claims / presentations this party is “entitled to” (not EBSI 1)
  • The party receives the Verifiable Attestion(s) as part of a VP and check the DID-signature (whether it belongs to the DID that corresponds with the VP that is being forwarded) - Mind that in certain cases this will not be needed as the Replying Party does not always need to verify the relationship with the user that is submitting the VCs. In some cases only the correctness of the VCs need to be verified.
  • The Party also check on the ledger if the VCs (part of the VP) have not been suspended / revoked.
  • Note: that (not part of EBSI 1) in case where there needs to be a relationship between the submitted VCs and the user - this relationship might not be "direct" but rather "expressed" by a verifiable consent/mandate showing that he/she is allowed to act on behalf of the "subject" for which the VCs are being submitted.

The Required supporting EBSI Infrastructure

Goal of this chapter

Goal of this chapter is to define --based on above described requirements/principals/architecture/infrastructure-- which supporting EBSI building blocks/services must be in place for ESSIF to be able to function. For those that are eager to get more details, we refer to the technical specifications which elaborate all this in more detail (cfr related wiki-pages).

The “local” environments

First and foremost it should be understood that many of the ESSIF functions happen fully outside of the domain of "ledgers" and blockchain. As explained above the choice has been made to base EBSI on "classic DIDs" whereby the ledger is user to register DID-documents and VC-meta-data allowing checking of Verifiable Credentials and Verifiable Presentations as well as validation if the corresponding DID(-key)s and/or VC have not been suspended or revoked.
Though not part of the EBSI core infrastructure or "supporting services" the different environment (Relying Party, Issuer, Holder) should not be underestimated. Functions that will need to be present will include generically:
  • A transaction agent able to "orchestrate" all interactions
  • A protocol-engine that is able to exchange VCs with the other parties
  • A Secure Communications Layer allowing to set up a TLS-communication
  • Plugins supporting the protocol engine to "speak" different "languages"

At the Relying Party and Issuer side the following specific components are identified:

  • Services to allow users to Identify/Authenticate themselves (e.g. "classic eID-based authentication)
  • A policy engine allowing to configure which DID-methods and VCs will (not) be accepted inbound
  • A Verifiable credential generator- supporting issuance policies
  • DID-signing- and optional eSealing-services

At the subject/user-side the following specific components are identified:

  • An as user-friendly as possible user interface (possibly guiding a user to which VCs could "match" the ongoing request.
  • A Verifiable Presentation Generator (based on user decisions made)
  • DID-signing- and optionally eSigning-services

Required Supporting Ledgers and Smart Contracts

As in ESSIF EBSI "classic DIDs" are chosen and as checking of suspension/revocation is needed, ledgers will need to be available to be able to support the SSI-flows and corresponding verifications/validations. At least the following ledgers have been identified::
  • One or more ledgers to allow for DID-registration (note that different parties might choose in future to "live" in different DID-domains / chose to use different DID-schemas)
  • One or more ledgers to support information wrt Verifiable IDs (also here, different parties might choose in future to "live" in different domains / chose to use different VC-schemas) 
  • One or more ledgers to put information wrt Verifiable Attestations on (also here, different parties might choose in future to "live" in different domains / chose to use different VC-schemas)

Note that above ledgers do not only require to "register" mentioned SSI-supporting info,
but that these (or mirror -ledgers) will also be required to to post suspension/rvocation-information
and that of course above-mentioned ledgers will need to expose smartcontracts allowing verification of DID(-keys)
and allowing the  validation of suspension/verification-status.

Required Supporting services

As mentioned above ESSIF will also need following supporting services from EBSI:
  • A DID-registrar allowing authorised DID-schemes to be published (as well as all information needed to interact with those schemes) in a controlled way.
  • A trusted Issuer list allowing authorised Issuer to be published (as well as the VCs they are allowed to issue and following which scheme and LoA this will be done, as well as info needed to interact with this issuer).
  • A VC-scheme referential which will list the scheme of all VCs that will be supported by ESSIF (note that there are at least two levels: one giving the general formats, second giving the exact format of used high LoA VCs).

Note that wrt the Trusted List registrar it is to be decided whether this will be implemented as a classic DB or immediately as ESSIF-ledger.

eSealing and eIdentification

As described, ESSIF-flows might require that next to the DID-flows, the user is identified/authenticated.  For identification/authentication ESSIF EBSI considers reusing the CEF eID building block which support eIDAS notified eID schemas and different level of authentication.
As described, it might be that during the issuance of some VCs the application of an eSeal is warranted. (Remote) eSealing is therefore a feature that will also be considered.

Resulting Overall Picture

All of the above boils down to the following consolidated picture showing ESSIF-building blocks and EBSI-infrastructure / EBSI-supporting building blocks in one overview.

Governance & Operational Requirements

Goal of the chapter

Goal of this chapter is to investigate the provisions that need to be foreseen wrt governance at the level of the ESSIF Framework and wrt operations at the level of the ESSIF architecture/infrastructure in order to ensure to security and trustworthiness of the ESSIF ecosystem.

Governance Perspective

Governance for ESSIF will play at two fronts:

  • on the one hand ESSIF --to be trustworthy-- will have to state clearly what the "practices / obligations of parties involved in ESSIF will need to be (which can differ depending on the use case and related level of assurances that need to be achieved.
  • on the other hand  "within" that context, use case can of course further elaborate their own domain whereby they can extend the ESSIF-model to their needs as long as they adhere to the ESSIF policies/guidelines/standards and are clear on what LoA(s) is/are applicable  to their use case(s),


ESSIF Governance (Structure)
Short Description

The goal of an ESSIF Governance structure is to ensure that ESSIF remains a stable / secure / trustworthy environment aka ecosystem for all parties involved.

Key PropertiesTo achieve this it is required that "interoperability / common ground exists on multiple levels:
  • legal interoperability  >> can be covered directly by e.g. an eIDAS V2 or by application of existing regulations(-principles)
  • organisational interoperability >> this can be achieved by requiring parties that t participate to follow the established policies
  • semantic interoperability >> this will be achieved by establishing an ESSIF frame for verifiable ID cards, mandates/consents and claims
  • technical interoperability >> this will be achieved by defining standardised patterns for the exchange of VCs
  • common security policies/standards >> this will be achieved by clear security requirements (especially for participating ESSIF-TSPs)-
Standardscfr also the European interoperability framework
Attention Pointswithin this framework, members (like member states) / domains (like e.g. higher education) can "extend" the model to their needs.
ESSIF TSP Policies (for Issuers and Ledger-operators)
Short Description

Issuers (and ledger they rely on to function) will in the end determine the trustworthiness of ESSIF as the usability of ESSIF will stand or fall with the trustworthiness of the VCs they issue (or support)

Key Properties

A TSP policy will clearly define under which rules Issuers can become member of ESSIF (see also operational perspective).

It will clarify to relying parties and subject clearly what LoA / Trust can  given to VCs that are issued by these issuers (and supporting ledgers)


e.g. RFC 3647

e.g. eIDAS certification schemes

Attention Points

Note that e.g. for low levels of assurance this can be quire light and based on "self declaration of conformance"

Note that the LoA of a VC is linked to the LoA of a Issuers (which translates back-to-back to the LoA of the nodes/ledgers used in support)

ESSIF Guidelines (for Owners/Subjects/Holders)
Short Description

ESSIF has to gain the trust of its users - aka whether  owners/subjects/holders are willing to use ESSIF. To "gain" this trust it is highly recommendable to put forward guidelines to these parties on ESSIF and its correct usage.

Key Properties

Explain to owners/subjects/holders ESSIF

Explain trust levels

Explain roles of issuers and relying parties

Explain their obligations


e.g.  RFC 3647

e.g. subscriber obligations under eIDAS

Attention Points

ESSIF Technical Standards
Short Description

In light of interoperability (semantic and technical) ESSIF will have to state its approved standards

Key Properties

Semantic standards to express verifiable IDcards, Mandates/Consents, Claims generically

Rules on how e.g. domains can extent this model (e.g. diplomas)

Technical standards expressing approved patterns to identify / authentication using VCs (e.g. in combination with POIDC)

Technical standards expressing approved patterns to prove a mandate or consent (e.g. in combination with OAuth2)

Technical standards expressing approved patterns to submit a verifiable claim (e.g. upload through API)

StandardsW3C Verifiable Credential Standard
OIDDC, OAuth2, ....
Attention PointsESSIF standards will evolve over time. So standards / change management will be an important point of attention.

ESSIF General Usage Conditions
Short Description

ESSIF has to gain the trust of potential relying parties - aka whether  e.g. governments, banks, retailers, etc  are willing to use ESSIF. To "gain" this trust it is highly recommendable to put forward guidelines to these parties on ESSIF and its correct usage.

Key Properties

Explain ESSIF to Relying Parties

Explain trust levels

Explain roles of issuers and owners/subjects/holders

Explain obligations of Relying Parties

Attention Points

  1. Operational Perspective

Trust Service providers in context of ESSIF (being the Issuers and those that run ledgers which Issuers can use as the trust in ESSIF will stand or fall depending on the reliability / trustworthiness of the before-mentioned parties) will have to adhere to the trust framework and more specifically rules related to operational security / trust management as to ensure the security /trustworthiness of all issued verifiable credentials.  In addition "wallet-providers" will of course also need to ensure that the client environment parties are working with are sufficiently security so that parties can trust the environment/systems they are working with. Operational (Security) aspects Trust Service providers will have to work with will include all of the elements visualised and elaborated below:

Risk Management
Short Description

ESSIF needs to evolve, but at the same time risks/threats will evolve. As such it is required that new threats and existing/potential risks are identified and evaluated as ESSIF evolves moving forward.   This applies to all levels of ESSIF and all parties, but most importantly to the Trust Service Providers as the overall Trust in ESSIF will stand or fall what the trust in those trust service providers.

Key Properties

Within the governance framework of ESSIF, ESSIF-TSPs will be required to have a risk management framework which:

  • pre-emptively identify threats / risks
  • keep track of identified risks, status of their mitigation and residual risks
  • periodically each (at minimum each year) draft an action plan to improve its risk posture

Standardse.g. ISO27001 risk mngt framework
Attention PointsThe rigidity at which risk management has to happen will depend on the targeted LoAs of the TSP
Information Security Mngt
Short Description

Every TSP should have a clear Security Policy Framework as to demonstrate how they keep their environment safe and ensure they are a worthy partner of the ESSIF-eco-system.

Key PropertiesA TSP should have clear policies and corresponding guidelines/standards/procedures in line with the best practices. We refer at minimum at all chapters as mentioned under the ISO27002 - Code of practice for information security controls.



NIST Cyber Security Framework

ETSI guidelines for Qualified Trust Service Providers

Attention PointsThe rigidity at which Information Security management has to happen will depend on the targeted LoAs of the TSP
Data & Systems Security
Short Description

Next to policies it is required that TSPs have a concrete view of the effective security controls in place to protect data that is under their control or that they are processing and all systems that are key to maintaining turst into the ESSIF-service they are rendering.

Key PropertiesThe controls should state all organisational and technical controls which are needed to Identify threats/risks/vulnerabilities/..., to Protect data & systems, to Detect incidents or worse compromises as fast as possible ,  to  Respond swiftly in case of incidents,  to     Recover when incidents happened.

NIST Cyber Security Framework


Attention PointsThe rigidity at which Data & Systems Security t has to happen will depend on the targeted LoAs of the TSP
Access Management
Short Description

In any secured environment it is key to have a rigid control of whom has access and to keep evidence of whom had access under which conditions. This is another vital element to ensure trust in TSPs.

Key Properties

TSPs will ensure that the necessary Privileged Access Management is in place .

TSPs will provide authentication of the connecting parties at a LoA that is consistent with the LoA of the service those parties are requesting.

TPSs will audit trail all relevant accesses (and corresponding mngt activities) for a period of time which is consistent with legal requirements linked to the LoA of the service they are providing.

TSPs will archive any accesses (and where needed responses) in line with legal requirements linked to the LoA of the service they are providing.

StandardsISO27002 - Access Control Mngt
Attention PointsThe rigidity at which access management has to happen will depend on the targeted LoAs of the TSP
Monitoring & Incident Mngt
Short Description

Incidents will happen. Therefore it is vital that TSPS have the necessary operational and security monitoring in place to detect asap what is happening and have the necessary incident mngt procedures in place to act swiftly.

Key Properties

Monitoring capabilities of all key  activities both on an operational level as well as on a security level.

Procedures to report incidents; employees, relying parties, subjects should be able to report incidents.

Incident (and crisis) management procedures: ability of the TSP to handle swiftly and contain any issues. TSPS will repo

TSPs will report incidents to the ESSIF governance authority on a yearly basis

TSPs will immediately inform the ESSIF governance authority and impacted parties at the time of a serious  incident.


ISO27002 - incident mngt

Legal Obligations for TSPs under eIDAS (and PSD2)

ITIL v3 - incident mngt process

ISO/IEC 27035 - Information security incident management

Attention PointsThe rigidity at which Monitoring & Incident management has to happen will depend on the targeted LoAs of the TSP
Business Continuity Mngt
Short Description

Especially for TSPs running ledgers, continuity is of the essence. Relying merely on the distributed nature of ledgers would be a dangerous thing as compromises of several involved nodes would be a possible event.

Key Properties

TSPs will have a clear and up-to-date asset inventory

TSPs will have an up-to-date  Business impact analysis

TSPs will have a business continuity plan

TSPs will have necessary Disaster Recovery plans

TSPs will ensure that any incident will not endanger their issued VCs over a period longer then 3 months.

StandardsISO27002 - business continuity management
Attention PointsThe rigidity at which Business Continuity  management has to happen will depend on the targeted LoAs of the TSP
Physical Security Management
Short Description

TSPs can only be TSPs as access to their key components are sufficiently secured As such TSPS will need to ensure that no unauthorised parties can have access to any component / service that can an impact on the LoA of the VCs they will be issuing..

Key Properties

TPS will ensure that physical access to key components is highly controlled

All access will be on a need to have basis only

All accesses to critical systems will be audit trailed

StandardsISO27002 - Physical and environmental security
Attention PointsThe rigidity at which Physical management has to happen will depend on the targeted LoAs of the TSP
Problem & Change Mngt
Short Description

Change at TSPs should only happen in a controlled way. On the one hand to ensure no issues can occur / security problems can be injected. On the other hand to allow involved parties to adapt themselves in time and test any "move" in time.

Key Properties

TSPs will announce/publish any change at least three months before going life

TSPs will have testing facilities available at least three months before activation of any change.

TSPs will have facilities with which ESSIF-parties can interact to report issues / problems.



ISO27002 - System acquisition, development and maintenance

Attention PointsThe rigidity at which Problem & Change management has to happen will depend on the targeted LoAs of the TSP
Outsourcing Mngt
Short Description

Security issues often occur these days due to issued at supporting suppliers. As such it is important that TSPs mind that they keep at all time responsible for their service and services rendered and cannot transfer this any related liabilities.

Key Properties

TSPs will for all outsourcing asses if the supplier cannot impact the LoA of its services.

If a supplier can have impact on the TSPs LoA, then the TSP must verify (from the beginning and periodically) that the supplier meets the security-/operational requirements of the TSP.


ISO27002 - Supplier relationships

ISO27002 - System acquisition, development and maintenance

Regulated outsourcing

Attention PointsThe rigidity at which Outsourcing (Risk) management has to happen will depend on the targeted LoAs of the TSP
Stakeholder Mngt
Short Description

It is important for TPSs to ensure a good relationship with the parties that use their services  so that the services can be used / relied upon correctly and any issues/incidents can be reported rapidly.

Key Properties

TSPs will publish a service catalogue clearly stating their services and related LoA's

TSPSs will publish a practice statement  stating their practices as well as the correct usage/ allowed usages of their services

TSPS will ensure they have a portal via which parties can report issues/incidents to them.

Attention PointsThe rigidity at which Stakeholder management has to happen will depend on the targeted LoAs of the TSP