Strong Identification Explained

This page details the methodology behind Trivore ID's strong identification. Since "strong identification" isn't a single, globally uniform concept, it's important to describe Trivore ID's own behavior here — with an emphasis on the API.

In general, strong identification can be conducted using several methods, with varying degrees of strength. The organisation using Trivore ID decides which methods to require and under what policies, according to its own business needs — and since Trivore ID is a multi-tenant platform, these requirements can vary between namespaces. Which document types are accepted for identification is configured per namespace; see User identification.

The table below highlights the strong identification data available via the API. Resource is the REST endpoint; Method / Source is which identification methods that endpoint supports; Data describes what's available on that resource. The OpenAPI documentation (/apidoc on your instance) always has the full, up-to-date reference for developers.

Resource	Method / Source	Data
/user/{userId}	All methods: In Person, governmental identification, Management API.	A data segment in the user's JSON containing the latest executed strong identification, plus a few extra attributes such as when the first strong identification was executed and how many history entries exist.
/user/{userId}/strongidentification	All methods.	Independent endpoint with the full set of data for strong identification. Always returns the user's latest strong identification as JSON.
/user/{userId}/strongidentification/history	All methods.	History endpoint — all of the user's strong identifications, as JSON.
/user/{userId}/strongidentification/history/{id}	All methods.	History endpoint — a single strong identification for the user, as JSON.
/user/{userId}/legal	Governmental identification methods only.	Only the Personal Identity Code attribute and value, as JSON — no other related metadata.

LoA, Level of Assurance

LoA is a broad concept not described in detail here. In short, it describes the trustworthiness of an executed identification — strong or otherwise. Normal identification is considered LoA 1, and a strong one at least LoA 2. LoA also applies to authorisation (i.e. 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 such as customer care performs it, based on physical documentation (passport, identity card, driver's license, etc.), and the information is entered on the person's behalf via 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, using an external digital identification interface, subject to the legal and procedural requirements of the relevant governmental resources.

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, LoA 3 is a special use case only.
Finland	suomi-fi-valtuudet	Subordinate to (and always requires) suomi.fi-tunnistus, and equally reliable — considered a separate method because it's technically different and used for different purposes.
EU	eIDAS	Currently treated the same as suomi.fi-tunnistus, since it uses the same workflows and APIs.

Management API (automated, or via a separate Web UI)

Identification data can be provided directly over the Management API via HTTP requests. It's also possible to build a dedicated Web UI on top of the Management API for this — such a UI is still identified as the "Management API" identification method.

Available LoAs are 1 and 2; by default, these identifications are considered LoA 1.

See also

• Initiating interactive strong identification, for suomi.fi-tunnistus.
• Suomi.fi, for using suomi.fi as a user directory (sign-in) rather than for one-off identification.