ESSIF Conceptual Reference for Architecture Definition

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)

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.

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.

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

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

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

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

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
  
  

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

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)

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:

User/Subject:

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

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:

User:

• 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

Issuer:

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

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

• 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

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

• e.g. StudentID
• verifiable IDs for issuing universities

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

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.

• Verifiable diplomas

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

• to pass a verifiable studentID to a relying party
  
• to pass a diploma to a relying party

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

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.

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)

• Need for the establishment of a trust framework
• Need for the establishment of LoAs

• 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

• Need for the establishment of a trust framework
• Need for the establishment of LoAs

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”

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.

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

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.

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

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

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.

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
  

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.

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”
  

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.

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

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

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

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.

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

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

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.

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

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.

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)
  

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))
* Sector ledgers (for registration of Issuers and possibly RPs)
* VC ledgers (to store (meta)data related to issued VCs)
* …

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.

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

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

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

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

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

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

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

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.

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

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

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

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)

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

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:

• 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
  
  

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.

GDPR

ISO27002

NIST Cyber Security Framework

ETSI guidelines for Qualified Trust Service Providers

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.

NIST Cyber Security Framework

NIST.SP.800-53

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.

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

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.

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

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.

ITIL v3

ISO27002 - System acquisition, development and maintenance

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 relationships

Regulated outsourcing

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.