ALIAS Local Framework Set Up
Setting Up Local Matching Tables
As the ALIAS doesn’t store any Personal Data related to a natural person, a matching table needs to be set up on the client side to associate ALIAS identifiers with Personal Data stored in your systems.
Below is the expected structure of the mapping tables that will be required on your local system in order to work with ALIAS.
You will need three tables.
Alias (Identity to User) Table
As depicted in the illustration below with the entity labeled alias, you will need a matching table that contains columns for match the Alias Identity (identity_id) and your own user identifier (id_user) that allows a look up in your own user repository.
Selector Type Table
You will need a `selector_type table that defines the different selector types to provide metadata about the selectors you are creating. The Selector Type will give context to the value of your Selector Table.
Selectors Table
You will also need to define a selectors table that maps an ALIAS identifier (id_alias) to a Selector Type (id_selector_type referring to the selector_type table) and a value containing the information necessary to locate or "look up" the Personal Data to which the Selector "points."
Required matching tables for ALIAS integreation.
Obtaining Future Identities (Alias Identity Generation) 🔧
After other set up items are complete, the API client should request a range of identifiers from API that will correspond to the identities of individuals that are going to be subject to having their Personal Data processed by the client in the future.
A pool of usable identity-reference is provided by ALIAS when you as a client subscribe to the solution. When you need to create a new identity-reference entry with the Events API, the physical person needs to be associated with the identity-reference on the client side.
The client can check all Alias identity-references quota already allocated (pool) and the ones already used with a request.
Clients may also delete identities that are no longer in use.
Defining SelectorTypes and Selectors 🔧
The purpose of a Selector is to specify the exact location of each instance of Personal Data for an Identity registered through the Events API. Selectors provide the necessary data to automatically apply the instructions given by the Events API.
A Selector is associated with each Identity related DataType. As a Selector may include personal data, an Alias Selector reference must be matched with a client maintained data source that contains Selector specific location information.
Updated about 3 years ago