Architecture

Overview

This section provides an overview of the Verification SDK's architecture, including its components and interactions.

Architecture Diagram

Explanation

  • Provider App & Beneficiary App: These applications interact with the Verification SDK to verify documents.

  • Verification SDK: Acts as the core component, exposing a REST API for verification.

  • Verification Service: Processes the verification requests and returns results.

  • Fastify Framework: Provides the underlying infrastructure for the REST API.

Sequence Diagram

Explanation

  • Request Verification: Both apps send verification requests to the SDK.

  • Process Verification: The SDK processes these requests through the Verification Service.

  • Return Result: Results are returned to the apps, with error handling and logging.

Data Flow Diagram

Explanation

  • Input: Credential JSON and configuration data are input into the Verification Service.

  • Processing: Data undergoes verification logic and validation.

  • Output: The final output is the verification result.

API Reference

The Verification SDK exposes the /verification API endpoint for credential verification. Below are the request and response details.

Request Body

  • credential (object, required): The credential JSON to verify.

  • config (object, required): Configuration object for verification.

  • method (string, required): The verification method to use:

    • "online": Verifies using a named online verifier (requires issuerName).

    • "offline": Planned feature (to be implemented).

  • issuerName (string, required if method is "online"): Name of the verifier to use. Currently supports "dhiway".

Example Request

PayLoad Example

Example Response (Success)

Example Response (Failure)

Error Response (Bad Request)

Core Components

The SDK uses a modular, extensible architecture for credential verification, centered around the src/services directory:

How to Add a New Verifier

  1. Create a New Verifier Class:

    • Implement the verify(credential) method with your logic.

    • Place your file in the appropriate folder (online-verifiers or offline-verifier).

  2. Naming Convention:

    • Name your class as <ProviderName>Verifier (e.g., AcmeVerifier).

    • The filename should match the class name (e.g., AcmeVerifier.js).

  3. Update Configuration:

    • To use your verifier, set method and issuerName in the request config:

    • The factory will automatically load your verifier if the naming matches.

  4. (Optional) Add Error Translation:

    • For online verifiers, you can add custom error translation logic as shown in DhiwayVerifier.js.

Example: Adding a New Online Verifier

  1. Create src/services/verifiers/online-verifiers/AcmeVerifier.js:

  2. Use it in your API request:


Tip: No changes to the factory or service are needed if you follow the naming and folder conventions.

For more details, see the code in src/services.

Note: This SDK is designed to enable interoperable, extensible, and standards-based credential verification. To support new providers or offline verification, simply add a new class implementing the required logic and register it with the verification service.

Last updated