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