STORK in epSOS
STORK aims to develop, test and validate common specifications and its reference implementations to identify and authenticate citizens from EU member states, using electronic identity (eID) methods already available in the individual countries.
These methods inter alia include
• Smart cards
• Username / password combinations
• “Mobile TAN” (one-time access code sent to user’s mobile phone via SMS)
Two interoperability models and their combinations are investigated and piloted: Pan-European Proxy Services (PEPS) are central eID proxies, provided by Member States for their citizens. The second model is the middleware model, where a middleware couples the eID with the service
provider. It is a Member State’s decision, which model to implement. The concept of “Pan European Proxy Services” (PEPS) maps to the epSOS LSP concept of National Contact Point.
In the individual MS where eID methods are already available, STORK can be used to authenticate users for the use of cases involving / giving / revoking consent and defining / deleting / modifying privacy policies. In these cases, epSOS LSP can probably use identifiers linked to health insurance (e.g. those defined by EHIC), because this data management is an administrative process and is not health-related.
Concerning the remaining use case requires to authenticate the patient (access to the patient’s own patient summary), nevertheless the restriction that in some countries it is forbidden to use insurance-related identifiers to access health-related data (like the patient summary) needs to be
taken into account.
If an insurance number is used for identification, it has to be considered that more than one single person can have the same numbers in some countries (e.g.: children have the insurance number of their parents). In such situations another database has to be used for univocal identification.
STORK defines “quality assurance levels” that are defined depending on the eID token and issuance processes. E.g. a smart card will yield a higher level compared to username-passwords.
The service provider defines a minimum security level that is needed for a particular service. For "harmless" services lower levels might be sufficient, whereas eID with low levels may be denied access for sensitive services. These security levels could be used to give better protection to sensitive parts in epSOS LSP. E.g. updating data could require a different security level than reading them.
General positioning of STORK and epSOS LSP
| STORK | epSOS LSP |
|---|---|
The basic use case in STORK is to authenticate a citizen in his country of | epSOS LSP use cases do not require the relying party in country A to know the identity of an HCP/HCPO in country B, but to rely on the assertion of a particular role. (Obviously the identity is recorded for audit purposes). Identification and authentication is an issue of the national infrastructure. epSOS LSP relying parties acquire roles needed for the authorization from the IdP. |
Although not limited to, the pilot use cases imply a focus on Browser-based clients as described with the SAML Web-Browser SSO use case. | epSOS LSP use cases are from the class of messaging/document exchange, like described in the OASIS Webservice Security profile. There is no direct interaction between clients and service providers, but NCPs act as reverse proxies, opposed to the Web-SSO-model. |
Depending on the model, the circle of trust (CoT) is either hierarchical (PEPS on MS-level and national) or flat with the middleware approach. | The CoT is strictly hierarchical, with the NCPs forming the epSOS LSP-level CoT and MS with the HCP on the national level. |
Defined by the application’s requirements, there are 4 different assurance levels for the authentication quality, based on the factors registration and authentication phase. | Trust levels can be taken over from STORK, but will be tuned to the capabilities of the epSOS LSP of actors of the MS participating in the LSP. |
The only process where synergies could be identified, is when a patient has to be identified and
authenticated abroad and uses an eID (see chapter 7.3.2.2 Identification and authentication of a
patient with a unique identifier).
Excerpt of a document of STORK
Patient Country A – PoC (eID)
The eID cross-border identification case fits the STORK process models well. As STORK distinguishes two models “middleware” (used by Austria and Germany) and a “Pan-European Proxy Service (PEPS)” (used by other member states), synergies with both models are discussed:
• PEPS: The epSOS LSP process flows are basically the same as the STORK PEPS authentication flows. A difference that is given is that the STORK PEPS model assumed that actual authentication of the citizen (patient) is carried out by the Identity Provider in Country A.
• Middleware: The STORK Middleware model assumes a so-called “virtual IDP” installation at the “Country B” PEPS. The IDP carried out the authentication of the citizen. Assuming such a V-IDP at NCP B, the process flow is the same.
Further collaboration between STORK and epSOS LSP has to be investigated in the piloting phases of epSOS LSP