TRIDENT Verified Data Gateway - Sandbox Integration Guide

1. Introduction

This guide provides an introductory overview of how relying party applications can access verified data through the TRIDENT Verified Data Gateway (VDG) in the Sandbox.

The VDG provides a controlled access layer between authorized applications and trusted data sources. Depending on the use case, it can:

• support user-mediated access to verified data;
• protect an existing data-provider API; or
• provide minimized data and derived results through a dedicated Facade API.

This guide presents three Sandbox integration cases:

1. User-mediated access through the TRIDENT IdP and VDG
2. Access to an EBC API protected by the TRIDENT VDG
3. Minimized data and derived attributes through a TRIDENT VDG Facade API

2. Concepts Used in This Guide

Main Participants

User
The person whose identity or verified data is involved in the request.

Relying Party
The authorized Government or third-party application requesting access to a service or data.

TRIDENT Identity Provider and Authorization Server
Authenticates the user, evaluates the requested access, and issues the applicable tokens.

TRIDENT Verified Data Gateway
Validates access, applies policies, records relevant activity, and routes requests to the appropriate service.

Data Provider
The authority responsible for the source information, such as EBC.

Access Tokens and ID Tokens

An Access Token represents the permissions granted to the relying party and is used to call protected APIs.

An ID Token provides information about the authenticated user to the relying party. It should not be used to call VDG APIs.

Scopes and User Authorization

Scopes define which services and data the relying party is allowed to access.

Applications should request only the scopes required for their approved purpose. Depending on the use case and applicable policy, the user may be asked to review and authorize the requested access.

Illustrative scopes may include:

• openid
• profile
• ebc.age.over.18
• ebc.address
• ebc.parish
• ebc.age.over.60
• ebc.masked-name

The final scope catalogue and the information associated with each scope remain subject to Government approval and definition by the competent data authority.

Secure Authorization

Public applications should use the Authorization Code Flow with PKCE.

Access Tokens are presented to protected APIs as Bearer tokens. The VDG validates the token, relying party, scopes, expiration, and applicable access policies before processing the request.

Sessions and Step-Up Authentication

The relying party manages its own application session independently from the TRIDENT IdP session.

An existing TRIDENT session may support Single Sign-On. However, stronger authentication may be required when accessing sensitive information or when the operation requires a higher level of assurance.

3. Integration Preparation

Before beginning an integration, the relying party should identify:

• the business use case;
• the data or verification result required;
• the appropriate VDG integration case;
• the required scopes and permissions;
• whether user authentication and authorization are required;
• the required authentication assurance level;
• the application type and redirect URIs; and
• the applicable data-protection, retention, and audit requirements.

The application must be registered and enabled in TRIDENT before it can obtain tokens and access protected services.

4. Integration Cases

Case 1 — User-Mediated Access through the TRIDENT IdP and VDG

Purpose

This case demonstrates how a relying party can retrieve verified data with the user’s participation.

The user authenticates through the TRIDENT IdP and, where required, authorizes the requested access. The relying party then uses the issued Access Token to retrieve approved information.

This pattern may be used with:

• Sandbox VDG-owned APIs;
• user-related data services exposed through the VDG; and
• EBC data made available through a user-mediated flow.

High-Level Flow

1. The user starts a service in the relying party application.
2. The relying party redirects the user to the TRIDENT IdP.
3. The user authenticates.
4. TRIDENT evaluates the requested scopes and assurance requirements.
5. The user authorizes access, where applicable.
6. TRIDENT returns an Authorization Code.
7. The relying party exchanges the code for an Access Token.
8. The application calls the VDG using the Access Token.
9. The VDG validates the request and returns the authorized data.

Expected Result

The relying party receives only the data permitted by the approved scopes and access policies.

Case 2 — Access to an EBC API Protected by the TRIDENT VDG

Purpose

This case demonstrates how an existing EBC API can be secured and accessed through the TRIDENT VDG.

The relying party does not connect directly to the EBC service. It sends the request through the VDG, which acts as the common access-control and security layer.

User participation may be required depending on the service, requested data, and applicable authorization policy.

High-Level Flow

1. The relying party obtains the required Access Token.
2. The application calls the VDG endpoint protecting the EBC API.
3. The VDG validates the token, client, scopes, and policies.
4. The VDG forwards the authorized request to EBC.
5. EBC processes the request using its authoritative data.
6. The response is returned through the VDG to the relying party.
7. The relevant activity is recorded for audit and traceability.

Expected Result

The relying party accesses an existing EBC service through a consistent TRIDENT security, authorization, and governance layer.

Case 3 — Minimized Data and Derived Attributes through a VDG Facade API

Purpose

This case demonstrates how a relying party can receive only the information required for a specific purpose, instead of accessing the complete underlying record.

The TRIDENT VDG Facade API obtains the required source data and returns an approved result.

Depending on the use case, this may include:

• a reduced set of attributes;
• a verification result;
• a derived attribute; or
• anonymized information, where applicable.

Illustrative Results

• Is the person over 18? → true
• Is the address verified? → true
• Parish of residence → Saint Michael
• Identity status → valid

High-Level Flow

1. The relying party requests a specific attribute or verification result.
2. The VDG validates the client, token, scopes, and applicable policy.
3. The VDG retrieves the required source information from EBC.
4. The Facade API applies the approved transformation or business rule.
5. Only the authorized result is returned to the relying party.

Expected Result

The relying party receives the minimum information required for its approved purpose, without obtaining the complete EBC source record.

5. Comparison of the Integration Cases

6. Security and Data Protection

VDG integrations should follow these principles:

• Least privilege: request only the scopes required for the service.
• Purpose limitation: use the information only for the approved purpose.
• Data minimization: retrieve only the data or result that is necessary.
• Secure token handling: protect Access Tokens and client credentials.
• User transparency: clearly explain the information being requested and its purpose.
• Appropriate assurance: apply step-up authentication for sensitive operations.
• Auditability: maintain records of relevant access and service activity.
• Configurable integration: do not depend on fixed Sandbox data or attribute values.

7. Sandbox Considerations

The endpoints, scopes, attributes, test data, policies, names, and responses shown in the Sandbox are illustrative and may differ from the final production environment.

Approved integrations will later progress through the applicable project environments under the required testing, validation, and release controls.