ESSIF Ecosystem – Trust Framework – EBSI
|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).
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:
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.
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):
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:
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:
The SSI Paradigm and SSI Business Case
|Chapter Goal||The 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.
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 / 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.
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:
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:
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
|Concept||Short Description||ESSIF 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:|
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:
|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 IDcard, drivers-license, social security card, member-card…)
|In ESSIF the following Verifiable IDs will be supported:|
|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:|
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:|
|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 Description||Part 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.|
To support "privacy by design" ESSIF will:
|Short Description||ESSIF 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 Properties||To ensure the "legal certainty" ESSIF will:|
|Short Description||Fundamental 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.|
To ensure "user control" ESSIF will:
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 Description||No information can last forever, certainly not a verifiable credential. Hence any issued verifiable credential must be “constrainable”.|
|Key Properties||To ensure "revocability" and "timeliness" ESSIf will ensure that:|
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.
|Short Description||When 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.|
To support this a “purpose limitation”, ESSIF should:
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 Description||A 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.|
To ensure extensibility, ESSIF will:
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 Description||To 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.|
To ensure easy of integration ESSIF should:
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 Description||All 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 Properties||DID 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)|
One should not the LoA depends on:
|Short Description||The 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.|
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)
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
|Short Description||When 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.|
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.
Relationship between these QWACs and DID (linked to issuers or relying parties) is subject to detailed design.
|Identification & Strong Authentication|
|Short Description||Users 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 Properties||Different 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.|
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 Description||One should consider using (Qualified) eSeals to ensure legal certainty wrt VC’s issued by Trusted / authorised Issuers where needed by respective business cases.|
|Key Properties||eSeals (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.|
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).
|Short Description||Users 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.|
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.
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).
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|
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:
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.
An ESSIF wallet / agent cannot function without a registry where it can find authorised issuers
An ESSIF wallet / agent must be modular and allow plugins (to support interfacing with multiple ledgers).
Plugins should allow a Wallet / Agent to interact with:
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.
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
Identified / required ledgers for ESSIF to support include (draft / not limitative list)
* DID registrars (for registration of user(-communities))
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 Description||It 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.|
Trusted Issuer referentials should publish:
Ideally for each VC and stated LoA also the following should be available:
|Attention Points||This registry must be machine-readable / -processable as to be able to automate usage by the parties.|
|ESSIF Schema Referential|
|Short Description||As 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.|
ESSIF schema referentials should:
|Attention Points||ESSIF schema referentials could be considered per domain/sector|
Main High-level Interactions
|2. Registration of an ESSIF-user|
|3. Requesting a(n additional) Verifiable Credential|
|4. User requesting a service from a RP|
|5. Relying Party Requesting additional info|
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:
At the subject/user-side the following specific components are identified:
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::
Required Supporting services
As mentioned above ESSIF will also need following supporting services from EBSI:
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 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)|
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 Properties||To achieve this it is required that "interoperability / common ground exists on multiple levels:|
|Standards||cfr also the European interoperability framework|
|Attention Points||within 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)|
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)
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
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)|
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.
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
|ESSIF Technical Standards|
In light of interoperability (semantic and technical) ESSIF will have to state its approved standards
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)
|Standards||W3C Verifiable Credential Standard|
OIDDC, OAuth2, ....
|Attention Points||ESSIF standards will evolve over time. So standards / change management will be an important point of attention.|
|ESSIF General Usage Conditions|
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.
Explain ESSIF to Relying Parties
Explain trust levels
Explain roles of issuers and owners/subjects/holders
Explain obligations of Relying Parties
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:
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.
Within the governance framework of ESSIF, ESSIF-TSPs will be required to have a risk management framework which:
|Standards||e.g. ISO27001 risk mngt framework|
|Attention Points||The rigidity at which risk management has to happen will depend on the targeted LoAs of the TSP|
|Information Security Mngt|
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 Properties||A 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 Points||The rigidity at which Information Security management has to happen will depend on the targeted LoAs of the TSP|
|Data & Systems Security|
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 Properties||The 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 Points||The rigidity at which Data & Systems Security t has to happen will depend on the targeted LoAs of the TSP|
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.
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.
|Standards||ISO27002 - Access Control Mngt|
|Attention Points||The rigidity at which access management has to happen will depend on the targeted LoAs of the TSP|
|Monitoring & Incident Mngt|
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.
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 Points||The rigidity at which Monitoring & Incident management has to happen will depend on the targeted LoAs of the TSP|
|Business Continuity Mngt|
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.
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.
|Standards||ISO27002 - business continuity management|
|Attention Points||The rigidity at which Business Continuity management has to happen will depend on the targeted LoAs of the TSP|
|Physical Security Management|
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..
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
|Standards||ISO27002 - Physical and environmental security|
|Attention Points||The rigidity at which Physical management has to happen will depend on the targeted LoAs of the TSP|
|Problem & Change Mngt|
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.
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 Points||The rigidity at which Problem & Change management has to happen will depend on the targeted LoAs of the TSP|
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.
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 relationshipsISO27002 - System acquisition, development and maintenance
|Attention Points||The rigidity at which Outsourcing (Risk) management has to happen will depend on the targeted LoAs of the TSP|
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.
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 Points||The rigidity at which Stakeholder management has to happen will depend on the targeted LoAs of the TSP|