The solution is based on Azure cloud services.
The solution is build using the following technologies:
All communication with API is based on Transporting Layer Security (TLS 1.2) (https ). Communicating over TLS preserves user privacy by protecting information between the user and the IDLink API as it travels across the public Internet.
The back-end solution, is built as a REST API, with Asp.Net Core 2 as backing technology. Responses will be in JSON.
Secured by JWT tokens which is both API key secured and user specific. Should key be leaked, the owner of the system can go to a UI and generate a new API key which instantly invalidates the previous key. Most calls will also require a specific user login and password to login. For automation purposes, a refresh token will be provided.
All this is done via IdentityServer4. This API is documented with Swagger, and will have examples of usage.
Below is an example of the documentation. It is a post-request:
When ready, the API key can be collected from the IDLink website, in the developer section, along with how-to and the link to the current API documentation.
The API is online and there will be no need to install any additional software.Any technology can be used to consume the API as long as it can make https requests against an online service and interpret JSON.
Further along the line, JSON schemas will be available for pre-validation of data before interchange.
Even further, NuGet packages in c# will be available for download.
The application will include multi-factor authentication, that enhances security in a multi-device and cloud-centric world. We will provide a multifactor authentication that is builds on the same premise as the verification methods described in PSD2:
We will also support third-party multi-factor authentication solutions.
Data is stored as relational data in azure DB with “always encrypt “-enabled, which ensures data encryption both at rest and in flight. Azure key vault keeps one of the keys safe, whereas the other one is installed on the environment hosting the APIs.
Files are stored in a blob with one container per customer and also encrypted in flight and at rest with a store certificate.
Only the Requester (the Consumer) has access to the data send from the company.
IDLink is using encryption during transit with an asymmetric certificate encryption on both the transport layer (https) and the database connection (different certificate). Encryption in transit is mandatory for IDLink traffic, requires authentication and is not publicly accessible.
IDLink uses ‘always encrypt protocol’ for the data. IDLink provides a granular encryption of all data and centralized key management from an Azure key vault. IDLink encryption algorithms operate on block lengths of 4096 bits.
The certificates for encryption are distributed to the web server (API) and to a key vault (Azure). This ensures that the certificates are not stored on the same machine, nor in the same environment. Both certificates are of 4096 bits length. In case of breach or suspicion hereof, the keys can be rotated easily and new certificates can be generated. Furthermore, the user data vault is encrypted with a key that the user has chosen himself, that will NOT be stored anywhere. Should the user lose the key, data can never be decrypted.
All backup data is encrypted with 2 certificates (4096 bits). Data that has been supplied by a company will only be accessible for 32 days. Within this time the requester can forward the data or download the data
The architecture is fully respecting and designed based on the principles behind "Privacy by Design" and "Privacy by Default".
Data in IDLink belongs to the User. The user retains the rights, title, and interest in the data stored in IDLink.
It is with this clarity of principle that it is ensured that the users privacy is maintained. Our online services are operated with certain key principles:
We only use the users personal data only to provide the user with the online services that the user have requested, including purposes compatible with providing those services.
We do not mine the users personal data for any purposes.
If the user ever choose to leave the service, the users can take their data with them with full fidelity
Only the user has access to the data.
Access to the personal data is strictly limited.
Beyond this, we have privacy controls to allow the organizations to configure exactly who has access to what within the organization. Strict access controls and design elements that ensure secure access.
In addition to service-level capabilities, IDLink enables the user to collaborate through the use of transparent policies and strong tools while providing the distinct ability to control information sharing.
Data will be encrypted with a 4092 bit encryption key and is only accessible to authenticated users.
Rights Management in IDLink, allows individuals and administrators to specify access permissions to requests, ongoing work and audit logs. This helps the organizations to prevent sensitive information from being printed, forwarded, or copied by unauthorized people by applying intelligent policies.
Privacy controls for four-eye principle, provides verification functionality that has a number of privacy controls.
Privacy controls for new system users are always set to highest privacy setting by default. This setting can only be edited by the system admin for security purposes. One example is that a system user has no access to a request by default and can see no data. Another is that a system user cannot see the data of a requester that another system user is working on, nor is there any sharing functionality build in to IDLink.