This glossary is intended to help you understand some of the technical terms used by the Pensions Dashboards Programme.
| Terms | Definition |
|---|---|
| acceptance testing | The final stage in the testing lifecycle conducted by end users with the purpose of accepting or rejecting the system before release. |
| integration testing | Formal testing against the central digital architecture platform to demonstrate that a data provider or dashboard supplier has successfully implemented API messaging standards including error and retry behaviour. |
| operational testing | Tests carried out when the system has been installed in the operational environment (or simulated operational environment) and is otherwise ready to go live. Intended to test operational aspects of the system eg recoverability, co-existence with other systems and resource consumption. |
| protection API token (PAT) | A long-lived authorisation token, representing a user’s consent at the consent and authorisation service. It is part of the UMA authorisation process and identifies the correct authorisation server to pension providers’ resource server. |
| persisted claims token (PCT) | This is part of the UMA authorisation process. A persisted claims token holds on to permissions collected during one authorisation process, so that users can access the system easily in future, without having to provide the same permissions again. |
| public key infrastructure (PKI) | A public key infrastructure allows the secure exchange of online data. It uses public and private cryptographic key pairs to unlock the information to authorised individuals |
| permission ticket/token (PMT) | Issuing permission tokens is an important part of the UMA authorisation process. Within the PDP ecosystem, the consent and authorisation service will issue a permission token to the data provider to release the pension information to the user’s dashboard, provided the user has given their consent to do so. |
| pension provider find interface (PPFI) | This is the means by which pension providers interact with the ecosystem, when they are receiving find data ie the instruction to look for a particular individual’s pensions. |
| pension identifier (PeI) | Term used to cover all separately identifiable pensions, in which some individuals may have an interest. It is the identifier of a pension, not in itself a statement of ownership. Its format is a text string in the form of a uniform resource name (URN) and provides a pointer to the pension asset. It is capable of being dereferenced by a pension dashboard and resolved into a URL, which provides the view endpoint which can serve the pension details associated with the PeI. |
| pension providers’ view interface (PPVI) | The means by which pension providers receive view requests from users at dashboards, check their authorisation at the consent and authorisation service, and if authorised return view data to dashboards. |
| regression testing | A test activity generally conducted in conjunction with each new release of the system, in order to detect defects that were introduced (or discovered) when prior defects were fixed. |
| requesting party token (RPT) | These are short-lived authorisation tokens or required access tokens. Within the PDP ecosystem, an RPT is a token that the pension finder service (the requesting party in this instance) will send to data providers, when an individual is trying to find their pensions via a pensions dashboard. RPTs are also used to request view data from providers and represent consent permissions for a specific PeI. |
| scalability testing | A component of non-functional testing, used to measure the capability of software to scale up or down in terms of its non-functional characteristics. |
| stress testing | Testing meant to assess how the system reacts to workloads (network, processing, data volume) that exceed the system’s specified requirements. Stress testing shows which system resource (eg memory or bandwidth) is first to fail. |
| system integration testing | A test level designed to evaluate whether a system can be successfully integrated with other systems (eg that the tested system works well with the HR system). May be included as part of system-level testing, or be conducted as its own test level in between system testing and acceptance testing. |
| system testing | The internal testing phase a dashboard or data provider supplier performs, connected to the reference environments and ensuring they can evidence conformance to the API standards and are fit to proceed to formal testing. |
| user-managed access resource server (UMA RS) | Within the UMA protocol, the resource servers hold the data that needs to be unlocked via the appropriate permissions. So within the PDP ecosystem, these are the pension providers servers, which hold the information about individuals’ pensions. |