Strong Identification Explained
This document details the methodology of Trivore Identity Service (TIS) strong identification. As the concept of Strong Identification is not globally exactly and uniformly defined, it is important to describe TIS behaviour. We emphasise the API in this document.
In general, Strong Identification can be conducted using several methods, with varying degrees of strength. The organization utilising TIS decides the policies and requirements pertaining to Strong Identification to implement these methods accordingly. These organisational requirements are constructed according to the business needs of the organisation. As TIS is multi-tenant platform, these requirements may vary between tenants.
The following table highlights the Strong Identification methods used by TIS. The Resource column contains the REST endpoint where data on Strong Identification is available. The Method / Source column details the Strong Identification methods supported by that endpoint. Column Data contains information on which kind of data is available on each Resource. Please note, the OpenAPI documentation contains updated and full information for developers.
| Resource | Method / Source | Data |
|---|---|---|
/user/{userId} | Supports multiple identification methods. This includes In Person, governmental identification methods, Management API. | Data-segment in JSON containing information on the latest executed Strong Identification plus few extra attributes like when first Strong Identification was executed and how many Strong Identification history entries there are. |
/user/{userId}/strongidentification | Supports multiple identification methods. This includes In Person, governmental identification methods, Management API. | Independent endpoint with full set of data available for Strong Identification. This endpoint always returns the latest strong identification for the user as JSON. |
/user/{userId}/strongidentification/history | Supports multiple identification methods. This includes In Person, governmental identification methods, Management API. | Strong Identification history endpoint, where all of the user's strong identifications can be retrieved as JSON. |
/user/{userId}/strongidentification/history/{id} | Supports multiple identification methods. This includes In Person, governmental identification methods, Management API. | Strong Identification history endpoint, where a single strong identification for the given user can be retrieved as JSON. |
/user/{userId}/legal | Supports only governmental identification methods. | Contains only the Personal Identity Code attribute and value in JSON, no other related metadata. |
LoA, Level of Assurance
LoA is a broad concept not described here in detail. It basically describes the trustworthiness of executed Strong Identification, or any identification for that matter. Normal identification is considered to be LoA 1, and a strong one at least LoA 2. LoA is also applicable for authorisation, a.k.a. sign-in.
Identification methods
In Person (directly on the Web UI)
In-Person identification is an external, strong method of identification. Typically an approved external source like customer care performs the identification. Identification is executed based on physical documentation (password, identity card, drivers license, etc.) and the information is entered forwarded by customer service to the API.
Available LoA is 2.
Governmental Identification Methods
Official government supported identification methods (in Finland the "suomi.fi-tunnistus" service) are a stronger method of identification. Depending on the legal and procedural requirements of the organization's governmental resources, this utilizes an external digital identification interface.
| Region | Method | Remarks |
|---|---|---|
| Finland | suomi.fi-tunnistus | The most authoritative method available in Finland. Available LoAs are 2 and 3. LoA 2 is the default and LoA 3 is a special use case only. |
| Finland | suomi-fi-valtuudet | Subordinate method to suomi.fi-tunnistus, and thus equally reliable. Always requires it. Considered to be separate method because it is technically different and the use cases are different. |
| EU | eIDAS | Currently considered to be the same as suomi.fi-tunnistus, as it uses the same work flows and APIs. |
Management API (either automated or separate Web UI)
TIS Management API methods involve direct HTTP requests to provide identification data according to TIS documentation.
It is possible to use similar Web UI to the one available in TIS directly. That Web UI shall be identified as Management API as identification method.
Available LoAs are 1 and 2. By default these identifications are considered to be LoA 1.