In this section, we go through the basic terminology used in this developer documentation to avoid confusion.
Access Token
A token which is generated for the user after successful OAuth2 flow. The access token is used by the API to authenticate users. The access token does not contain any information that the client(TPP application) can use.
Access Code
The access code is a code given during OAuth2 flow; this code is used to get the access token.
API Call
API call is a request towards the API which receives a response. The API is by design stateless, and therefore it does not "remember" anything about previous requests, i.e., there is no session. Therefore every request made towards the API must contain certain headers so that the API can authenticate and authorize the user.
API Console
API Console is a tool on the API portal which lets users try out API calls in their web browser quickly.
Authentication
Authentication is a process which provides the correct identity of the user. Authentication is the key component in enforcing that users are only able to access only the resources that they are allowed to.
Authorization
Authorization is a process which allows or disallows user to access resources and authorization is done based on the user identity. This means that to be able to be authorized user must first be authenticated, i.e., authorization uses users identity provided by the authentication process.
Client
The client refers to the client of the API which is commonly the TPP application.
Consent
Consent is an agreement given by the user to the bank for sharing data and services for use through a third party provider (TPP). The consent gives TPP access to use data or services which are held at the bank. The given consent can be changed by the user any given time if necessary in the real version of the API.
Maturity level
Maturity level tells in which part of the lifecycle the given operation, parameter, model or property is.
OAuth2
OAuth 2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service.
OAuth2 Flow
OAuth2 flow in the context of the developer documentation refers to Nordea's OAuth2 implementation, and it has a lightweight UI for granting the consent for single TPP. The flow is initiated upon request from the TPP. Nordea stores the consent given by the user as a part of this flow, and the user can change it at any given time.
Permission
Permissions are part of the consent given by the user for the TPP. Permissions dictate what the TPP can do with the user data.
Production Version of the API
The production version of the API refers to the actual release version of the API which this sandbox mimics. It will be richer and more mature compared to this sandbox version. Also, it will allow TPPs to access the real banking data, i.e., the user can get real account information and initiate real payments.
Sandbox
Sandbox in the context of the current APIs mean that the data returned by the APIs consist of static examples. Its purpose is to mimic the real version of the APIs. Moreover, when the production APIs are available the sandbox APIs will always have the latest version of the API, i.e., all new versions appear there before they are introduced into the production.
Third Party Provider
Third-Party Provider(TPP) is the provider of an application which the user uses. TPP is the client/consumer of the API.
Before the PSD2 deadline, for a bank customer to access their data via a TPP, following conditions must be met:
- TPP must have a valid agreement with Nordea.
- TPP must have the related licence(s) given by the local FSA or by passporting from another country.
- The TPP must be enrolled on Nordea's Open Banking platform and register the third party application before they can use the API.
User
The user refers to the bank customer who uses the TPP application.
QSEALC
Qualified certificates for electronic seals. Qualified electronic seals can be considered as digital equivalent to seals of legal entities on paper. According to the eIDAS regulation, a qualified electronic seal must be created by a qualified electronic device and based on a qualified certificate for electronic seal.
QTSP
Qualified Trust Service Provider. An entity permitted by Member State Supervisory Body to issue Qualified Digital Certificates that are recognized across the EU.