eSignet is designed with the architectural principles mentioned below. These architecture principles are core to developing the system's features and greatly influence how and why specific software design patterns are used.

Data Privacy

eSignet prioritizes user privacy by minimizing data exposure and ensuring secure interactions:

• No PII Data Storage by eSignet: eSignet does not store any personally identifiable information (PII); sensitive data is processed transiently for authentication and never retained.

• Privacy-Enabled Token (PSUT): Instead of sharing user IDs, eSignet issues a unique Partner Specific User Token (PSUT) for each user-relying party pair.

• Protection of Sensitive Data: Sensitive information is never stored or logged in clear text.

• User Controlled Consent: Users have full control over what data is shared with relying parties.

No Vendor Lock-in

eSignet is built to be vendor-neutral and open-source, promoting maximum flexibility, interoperability, and independence:

• Open Standards Across the Stack eSignet adheres to open standards across its entire architecture, enabling seamless integration with a wide range of identity systems and infrastructures.

• No Dependence on Proprietary Solutions Organizations are free to use their preferred biometric devices, software components, and infrastructure without being tied to a specific vendor or ecosystem.

• Open Source Foundation As an open-source product, eSignet provides full transparency and avoids proprietary lock-in, allowing adopters to customize, extend, and audit the solution based on their requirements.

Commodity Computing

eSignet is optimized for cost-efficiency and scalability:

• Containerized Backend: All eSignet backend services run as Docker containers, eliminating dependencies on specialized hardware or specific cloud providers.

• Multi-Platform Support: It can be deployed on any general-purpose virtual machine (VM) that supports Docker.

• Avoids Vendor Lock-in: Organizations are free to use their existing cloud or on-premise infrastructure.

Secure By Design

Security is a core principle of eSignet, ensuring end-to-end protection:

• Trusted Integrations: eSignet only integrates with verified and trusted applications.

• Fraud Prevention: Authentication is tied to specific transactions, reducing the risk of unauthorized access.

• Centralized Key Management: A robust key management system ensures secure cryptographic operations.

• API Security:

All state-changing APIs are protected with OAuth 2.0, enforcing authenticated and authorized access.

Please refer to the below sections to build, integrate, and enhance solutions with eSignet using comprehensive guides, tools, and resources:

• Technology Stack – Learn about the technologies used in eSignet, including services, storage solutions, deployment tools, and testing frameworks.

• Components – eSignet – Understand eSignet’s core components, functions, and integration methods.

• Components - Signup Portal – Seamlessly register and verify identities with the Signup Portal’s robust components and secure eKYC integration.

• – Refer here for all the APIs used by eSignet.

The documentation is licensed under a Creative Commons Attribution 4.0 International License.

🔗 eSignet's Core Repositories:

All eSignet's repositories are licensed under the terms of .

⚠️ Trademark Notice:

All trademarks are the property of their respective holders. Other products and company names mentioned may be trademarks and/or service marks of their respective owners.

eSignet is built on industry-leading security standards, ensuring robust privacy and data protection. It implements OpenID Connect Core 1.0 and OAuth 2.0, leveraging the most secure and trusted authentication flows to safeguard user identities.

1. Security

• Biometric Integration via SBI eSignet integrates with the Secure Biometric Interface (SBI) to support a wide range of biometric service providers. Please refer the links below for the SBI library to enable the biometric auth with eSignet

  • - View the list of compatible biometric devices.

• HSM Integration with PKCS #11 eSignet supports Hardware Security Module (HSM) integration using PKCS #11 for the secure storage and management of signing keys.

2. Interoperability

• Verifiable Credentials & Wallet Integration eSignet adopts OpenID standards to support verifiable credentials and wallet-based identity verification, enabling seamless cross-platform interoperability.

• Identity Assurance (Introduced in v1.5.0) From version v1.5.0, eSignet includes support for under OpenID Connect, allowing retrieval of verified user claims and associated metadata.

• well-knowns eSignet implements well-known to publish the URI for metadata discovery. Below are the supporting standardized .well-known endpoints for dynamic service configuration and discovery.

2. Supported Standards and RFCs

eSignet provides a limited implementation of the OpenID protocol, supporting the following RFCs and standards:

a. OAuth 2.0 Standards:

• - Authorization code flow support

• - Authorization Framework: Bearer Token Usage

• - JWT profile for client authentication

• - PKCE security extension

b. Token and Discovery Standards:

• - JSON Web Signature

• - JSON Web Keys

• - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

• - ID token and access token as JWT

c. Identity Proofing and security:

d. FAPI 2.0 Security Profile:

eSignet adopts key OpenID requirements. This combination mitigates authorization request tampering, authorization code interception, bearer token replay, and authorization server mix-up attacks, significantly strengthening OAuth 2.0 security.

• - Pushed Authorization Request (PAR)

• - Demonstrate Proof of Possession (Dpop)

• - Authorization Server issuer Metadata

3. Supported Authentication Flows

As eSignet incorporates OpenID Connect, a wide range of client libraries are available for seamless integration. Therefore, it is recommended to avoid creating custom code for the integration process.

eSignet implements and supports only the flows mentioned below:

Note: eSignet supports confidential clients only, adhering to the principle of security by design.

4. Security Enhancements

• Authorization Code Flow – Exchanges an authorization code for a token, requiring client authentication.

• Private-key-jwt - Our supported client authentication method is private-key-jwt only which ensures that the token is given to a legitimate client.

• PKCE - We also support the (Proof Key for Code Exchange) security extension for exchanging an authorization code for a token, which guarantees that the authorization code was obtained by the same client application performing the code exchange.

Note: eSignet currently supports the S256 challenge method in its PKCE implementation.

5. eSignet as OAuth 2.0 server

eSignet’s OAuth 2.0 implementation is a lightweight solution designed specifically for OIDC authentication flows. It does not function as a full-fledged authorization server but provides the essential capabilities required for identity verification and kyc. Additionally, eSignet:

• Does not support role-based access control - As it is designed for integration with national-level identity solutions, where predefined roles are not necessary for residents.

Overview

Digital identity is rapidly becoming the standard for citizen identificatio, Whether accessing services on government platforms or private service portals, user authentication is now a critical requirement. To ensure secure, private, and inclusive access, authentication mechanisms must adhere to established standards that guarantee data protection and build user trust.

Where does eSignet fit in?

eSignet plays a critical role by providing a secure, standards-compliant digital identity solution that empowers both users and service providers. It enables:

• Trusted identity verification across platforms.

• Flexible login and authentication methods tailored to various assurance levels.

• Inclusive access designed to serve diverse user groups and device capabilities.

• Consent-driven data and profile sharing, ensuring transparency and user control.

eSignet ensures that digital interactions are not only seamless but also secure, private, and user-centric. Built on trusted protocols and designed with a privacy-first approach, eSignet empowers both users and service providers with confidence and control.

eSignet comprises of 2 specific modules/parts:

What is eSignet Authentication?

is a powerful, open-source digital identity authentication module that enables secure and standardised access to online services. It is developed by MOSIP and built by implementing specific OpenID Connect (OIDC) RFCs to provide high assurance.

It is designed to be independent and be used as a standalone authentication module and can be easily integrated with any identity system or repository that supports authentication and attribute retrieval. While it includes reference integrations with MOSIP, its architecture is flexible and open enough to be adopted for a wide range of digital services ecosystems.

Whether you're building a citizen portal, a financial application, or any service that requires identity verification, eSignet can serve as your trusted, modular identity layer.

What is Signup?

The Module is a self-contained, independent component that enables individuals to create and manage their digital identity profiles designed for seamless integration with eSignet auth module.

Beyond profile creation, the module also offers support for identity verification capabilities, including support for , ensuring that user identities can be reliably validated during signup. With a focus on inclusivity, low-barrier entry, and progressive trust building, it can be used to extend digital identity to under-served or unregistered populations.

Key Features of eSignet

• Login with Trusted ID Enables users to authenticate using a secure identity issued by a government authority or a trusted provider.

• Inclusive Support for Multiple Authentication Factors Accommodates a including biometrics, one-time passwords (OTP), and wallet-based authentication.

• Frictionless Addition of New Authentication Factors Architected to seamlessly integrate emerging authentication technologies without requiring major system modifications.

What Differentiates eSignet

1. Enhancing Authentication Methods Through Secure Standards

• Standards-Based Architecture utilizes , allowing seamless integration via widely supported libraries.

• Scalable for Country-Wide Implementation Designed to deliver secure authentication and KYC verification at national scale, ensuring high reliability and performance.

• Secure Biometric Integration Incorporates the to enable secure biometric data collection for identity verification.

2. User-Centric Design

• Single Identity Credential Enables users to access integrated public and private sector services using a unified digital identity.

• Mandatory Consent Enforcement Ensures that all data access is governed by an explicit, user-centric consent flow.

• Support for Diverse Authentication Methods Accommodates various verification approaches to meet individual preferences and improve usability and liveness detection.

3. Accelerated Digital Transformation

• Fast and Secure Digital Verification Facilitates rapid user verification across multiple digital services.

• Assurance Parity with Registration Maintains consistent verification quality using the same methods employed during initial user onboarding (OTP, biometrics, cryptographic keys).

• Government Enablement for e-KYC Services Empowers governments to offer digital identity verification and e-KYC services, fostering broader access to financial and digital services.

Inclusivity at Its Core

eSignet is engineered to ensure inclusive access to digital identity verification, supporting multiple verification models and modalities to meet the varied needs of users and the devices they use.

Verification Models

• Assisted Verification and Data Collection Enables identity verification with the assistance of an operator or at a physical kiosk.

• Self-Identification for Online Services Allows users to independently verify their identity through remote digital channels.

• OTP-Based Authentication (Feature Phone Users) Offers SMS-based OTP login for users with basic mobile devices.

• Wallet-Based Facial Authentication (Smartphone Users) Enables face recognition authentication via digital wallets on smartphones.

• Biometric Authentication (Non-Phone Users) Supports biometric verification for users without mobile access, via assisted modes or kiosks.

Who is eSignet for?

• Government Agencies Offers a secure, standards-based identity verification layer for transforming existing IDs into interoperable digital identities.

• Service Providers Enables efficient service delivery through secure identity verification, eKYC, and consent-based data access across sectors such as banking, telecommunications, and insurance.

• Citizens and Residents Empowers individuals to prove their identity securely and conveniently while preserving privacy across a broad range of digital services.

Potential Use Cases

• Healthcare: Patients use OTP or biometrics to access health portals securely, ensuring inclusive access to medical services.

• Education: Universities leverage face authentication for secure access to exams or hostel services, enhancing accessibility.

• Social Welfare Programmes: Enables precise distribution of benefits to verified and eligible recipients.

• Taxation:

The use cases listed above are illustrative and not exhaustive, eSignet can be adapted to support a wide range of additional applications across both public and private sectors.

Refer below to know more about eSignet principles, standards and tech:

• .

• .

Experience eSignet in Action Through Our Demo Health Portal

Explore eSignet in action through a Health Services Portal designed to mimic the role of a relying party. This portal allows you to experience how eSignet seamlessly integrates into any service application that requires secure resident authentication.

Hosted on the MOSIP Collab Sandbox, this portal gives you an interactive space to try out eSignet as an actual user would. With just your National ID (UIN), you can explore:

The audit plugin interface provides two methods to audit any action in eSignet. An instance of this audit plugin is injected into all the services of eSignet, and almost all the events are audited using this plugin.

For eSignet Audit Interface refer to the

Experience the Signup Module in Action

Explore the power and flexibility of the Signup module through an interactive, hands-on environment.

Test the Signup Flow with the Demo Health Portal

eSignet is a product of the combined efforts of multiple stakeholders. Community contributions form the project's backbone, driving its growth and stability.

Ways the community contributes:

• Direct code contributions.

Please refer for Signup module API documentation.

Effortlessly deploy and configure eSignet with comprehensive guides, architecture insights, and mock environments.

The eSignet solution is designed to be:

Easily deployed and tested locally using a Docker Compose–based setup for each module, allowing services to be brought up seamlessly on your machine.

Deployed on-premise, with full flexibility to configure eSignet as per your organization’s use cases and requirements.

The latest stable codebase is available under the master branch of the eSignet repository. All feature development or bug fixes are typically carried out on dedicated feature or development branches.

What is ACR?

ACR, which stands for Authentication Context Class Reference, is a parameter used in authentication and identity systems to define the context or level of assurance associated with an authentication event.

Why ACR Matters

ACR values convey how a user was authenticated and the strength of that authentication, enabling relying parties to assess the trustworthiness of the authentication event.

Usage:

• ACR values are typically defined by identity providers and relying parties to communicate the level of trust and security associated with an authentication event.

• These values can vary between systems but are often used to indicate different levels of assurance.

• The assurance level is shared with the relying party as one of the claims in the ID token.

Supported ACRs

eSignet currently supports the below ACR values:

• mosip:idp:acr:generated-code For OTP authentication.

• mosip:idp:acr:biometrics For biometric authentication use a MOSIP SBI 2.0-compliant device.

• mosip:idp:acr:linked-wallet For wallet-based authentication, which requires the wallet to be bound to the server. Thereafter, the binding key could be used to sign the JWT with the server-signed certificate in the header as an authentication factor.

• mosip:idp:acr:password For password-based authentication.

• mosip:idp:acr:knowledge For Knowledge Based identification(KBI), demographic data based identity authentication.

This guide helps in setting up the mock OIDC-relying party portal. This portal uses the authorization code flow with private key JWT client authentication to fetch the user profile.

The mock relying party portal is built with reactJS. This consists of the below two components:

1. mock-relying-party-ui

2. mock-relying-party-service

Mock relying party UI

UI component consists of the login page and a user profile page.

The login webpage is built with the Log in with eSignet button. With the click of this button, the user is redirected to the authorization endpoint of the eSignet UI.

The user profile "/userprofile" webpage is crafted to which the eSignet server redirects after successful authentication with "auth-code".

On a load of the user profile webpage, the "/fetchUserInfo" endpoint of the mock-relying-party service is invoked with a valid auth code.

Mock relying party service

This service only hosts the "/fetchUserInfo" endpoint.

The "/fetchUserInfo" endpoint will invoke the "/token" endpoint of the eSignet server with client_private_jwt auth.

On receiving the id-token and access-token from the "/token" endpoint, the mock-relying-party-service invokes the "/userinfo" endpoint of the eSignet server to fetch user details. Decoded user info is returned as the response to the "/fetchUserInfo" endpoint.

How to build and run the mock relying party portal locally?

To build and run the mock relying party portal please refer to the below README.md file

MOSIP (Modular Open Source Identity Platform) is an open-source, API-first identity management solution enabling countries to develop national ID systems using open standards. It provides individuals with a foundational identity, ensuring secure, scalable, and inclusive identity management.

How eSignet Integrates with MOSIP

eSignet integrates with MOSIP through the ID Authentication module, enabling secure identity verification and credential management via key APIs:

• KYC Authentication API: Verifies user identities securely.

• KYC Exchange API: Shares encrypted KYC tokens.

Use Case

Patient Access to Health Services

A patient with a national ID can log in to an online health portal to check appointments and health records. The login process is handled by eSignet, which authenticates the patient’s identity against the MOSIP national ID system, ensuring secure access to personal health data. This integration provides seamless, secure, and scalable access to healthcare services while maintaining data privacy and authenticity.

👉 Learn more about integration with .

👉 To try it out yourself in our sandbox environment, click to access the eSignet Try It Out section.

In the context of eSignet, a Relying Party refers to any external service provider or application that integrates with the eSignet platform to leverage its secure identity authentication and verification capabilities. By relying on eSignet as a trusted Identity Provider (IdP), these service providers can streamline user onboarding and access management, while maintaining a high level of security, privacy, and regulatory compliance.

eSignet enables Relying Parties to authenticate users based on verified identity data, including biometric authentication and government-issued credentials, without the need to build or manage their own identity infrastructure. This allows service providers to focus on delivering their core services while ensuring that only legitimate users can gain access.

Whether it's a financial institution verifying customer identity for KYC compliance, a healthcare provider granting access to medical records, or a digital service requiring strong authentication, eSignet serves as the central identity authority that these services trust.

To learn more about the integration process and technical requirements, please refer to the following resources:

• Integration Options and Discovery Endpoints – Know about the options available to integrate with eSignet in MOSIP collab environment and discovery endpoints.

• – A step-by-step guide to help you prepare your service for integration with identity providers.

• – Technical documentation and best practices for implementing eSignet as your trusted identity provider.

The latest stable version of the eSignet solution is deployed in our Collab environment. featuring the most up-to-date QA-certified Docker images.

This sandbox is designed for:

👉 ID Solution Providers - Representatives of ID solutions who are seeking a convenient method to enable authentication,

👉 Developers & Integrators- who are interested in gaining a better understanding of how eSignet works or those who wish to demonstrate eSignet.

👉 Relying Parties - Relying parties can efficiently utilize this platform to seamlessly integrate and ascertain its compatibility with the protocols employed by eSignet.

Here are some ways you can use our sandbox environment: Collab

Start exploring eSignet today in our Collab Sandbox! 🚀

eSignet is built with a modular architecture that offers multiple integration points, ensuring flexibility to accommodate diverse use cases. This design enables seamless integration across various platforms, providing secure identity verification and delivering a smooth user experience across applications and services.

eSignet currently integrates with the following platforms:

This section contains various guides and information that could benefit:

• Organizations, nations, and ID registries have an identity solution with authentication capabilities to enable Open ID connect-based authentication.

• Relying parties or service providers from countries where the eSignet solution is deployed.

• Digital wallets are those who want to integrate with eSignet and provide wallet-based authentication solutions or store verifiable credentials in their wallets.

For more information on how to get started with these integrations, read through:

Release Name: IdP (Beta)

Release Date: 8th January, 2023

Overview

The IdP (0.9.0 version of eSignet) focuses on essential features such as Login with OTP and Login with Biometrics. The subsequent releases will have more features and integration with digital wallet solutions.

Features Covered

The basic features such as,

• Login with OTP

• Login with Biometrics

are available as a part of this release.

Documentation

OpenCRVS (Open Civil Registration and Vital Statistics) is a digital system designed to capture and manage vital life events such as births, deaths, marriages, and divorces. It provides individuals with a legal identity and serves as a key source of demographic data, supporting policy-making, planning, and resource allocation. OpenCRVS ensures accurate registration of vital events, forming the foundation for a comprehensive and reliable identity management infrastructure.

Integration with MOSIP

• Combines MOSIP’s digital identity management with OpenCRVS’s event registration.

• Enables seamless data exchange for efficient registrations.

• Works in both connected and remote areas with limited connectivity.

How eSignet Integrates with OpenCRVS

• Secure Authentication: eSignet provides secure authentication for individuals reporting vital events, ensuring that only legitimate users can register events in OpenCRVS.

• Identity Verification for Parents/Guardians: Before issuing a Unique Identity Number (UIN) and generating certificates, eSignet verifies the identity of parents or guardians to ensure authenticity.

• Data Accuracy & Security: eSignet enhances the security, accuracy, and integrity of captured data, preventing fraudulent registrations or modifications.

Use Case

eSignet Integration with OpenCRVS for Vital Event Registration

eSignet is used to authenticate the person reporting a vital event, such as a parent, guardian, introducer, or informant, before any vital event registration in OpenCRVS. This ensures secure identity verification, preventing unauthorized individuals from registering or updating events, and ensures data accuracy across various types of vital event registrations.

Events where eSignet Integration can be used:

1. Birth Registration eSignet authenticates the parent or guardian before issuing a Unique Identity Number (UIN) to newborns, ensuring secure and fraud-resistant birth registrations in OpenCRVS.

2. Demographic Data Update eSignet facilitates secure authentication for updating demographic details (e.g., name changes, and address updates), ensuring records remain accurate and up-to-date while preventing unauthorized modifications.

3. Death Registration eSignet verifies the identity of authorized family members or officials before registering a death in OpenCRVS, ensuring the integrity of national identity records and preventing fraudulent use of deceased individuals' identities.

👉 Learn more about integration with .

1. On the portal, the resident clicks on the button Sign In with eSignet.

The login screen appears and the resident is displayed with the options they can choose for login.

2. To get started with login with OTP authentication, the resident clicks on Login with OTP option.

3. The resident needs to enter a valid VID in the Enter Your VID text field and check the box 'I'm not a robot'.

The OTP-based authentication is now secured with a captcha.

4. Next, the resident clicks on the Get OTP button.

5. The resident receives the OTP on the registered channel (either by phone or email).

6. The resident needs to enter the valid OTP received and click on the Verify button.

7. The resident is then navigated to the Consent page. On this page, the Essential and Voluntary claims are displayed.

8. The resident is given the option to choose from a list of Authorized scopes and Voluntary claims. The Essential claims are mandatory and cannot be modified. A master toggle button has been added to allow residents to select all the options at once if desired.

9. The resident should now click the Allow button. The system navigates the resident to the User Profile page which displays all the personal information based on the consent provided.

Welcome to the Develop section of eSignet’s documentation. This section provides developers with the tools, components, and guidelines for building, customizing, and integrating with the eSignet platform.

Explore the sections below to get started:

Technology

Understand the technologies behind eSignet, including architecture diagrams, frameworks used, and system design considerations.

Learn how to configure eSignet’s properties for different implementations, covering authentication, cache, plugins, and key management.

Essential steps to integrate eSignet with any relying party and ID system.

Refer here for all the APIs used by eSignet.

How the Signup Flow Works

1. Redirection to eSignet Signup Portal

When users access the health services portal for the first time, they are redirected to the eSignet Signup Portal to complete their registration.

2. First Login & Video eKYC

Once signed up, users are prompted to complete a video eKYC (electronic Know Your Customer) process on their first login. This ensures verified digital identity and eliminates the need to repeatedly enter personal information.

Why This Integration Matters

Integrating the eSignet Signup Service with the health services portal enables trusted digital onboarding and simplifies access to government and health services by leveraging the country’s foundational ID system.

.

The Signup service is not available in the MOSIP Collab as of now for self experience.

This section provides developers with the tools, components, and guidelines for building, customizing, and integrating with the signup module.

Explore the sections below to get started:

Technology

Understand the technologies behind signup, including architecture diagrams, frameworks used, and system design considerations.

Seamlessly register and verify identities with the Signup Portal’s robust components and secure eKYC integration.

Essential steps to integrate Signup with any Relying Party and ID system

Refer here for all the APIs used by signup.

What is Profile Registry Plugin?

ID registry plugin enables eSignet's Signup service to integrate with any Id registry system. This essentially means that eSignet now does away with tight integration with MOSIP ID-repository and makes way for any ID Repository system to be integrated with eSignet.

Sequence Diagram

Please refer to the sequence diagram below for the detailed working flow of the profile registry plugin.

Profile Registry Plugin Interface

Please for the Profile Registry Plugin interface.

This document details the steps for running eSignet locally on your system for local development and integration.

For the local deployment, eSignet is integrated with the mock identity system using eSignet plugins specifically developed to connect with the mock identity system.

We have a docker-compose setup to start eSignet and its dependent services. Kindly refer to the readme file to know the steps to run the docker-compose in detail.

API Documentation

To know about the query parameters that are required to test the OIDC flow, refer to our API documentation.

Postman Collection

We also have Postman scripts available under the folder in the eSignet GitHub repository.

This is a mock implementation of an identity system. We provide this system so developers can use it for local development and testing of eSignet.

The mock system can be run with endpoints to,

• create an individual

• get an individual's data

Inji enables the secure issuance, storage, exchange, and verification of data as verifiable credentials. It shifts from physical documents to a digital-first approach, simplifying service access, enhancing security, and supporting the growth of the digital economy.

Inji Sub-modules

• Inji Wallet: Securely store and manage verifiable credentials.

Welcome to the Test section! Here, you can explore how to integrate, test, and use eSignet across different scenarios. Whether you're experimenting with mock data, setting up integrations, or guiding end users through login methods, this section has you covered.

Explore the sections below for detailed guides and instructions:

Overview

The oauth-configuration well-known endpoint in eSignet exposes metadata that describes the capabilities, endpoints, and supported features of the authorization server. This metadata follows the OpenID Connect Discovery and OAuth 2.0 Authorization Server Metadata specifications (), enabling client applications to automatically obtain configuration details required for integration.

The values published by eSignet at this endpoint align with the standard OAuth Authorization Server well-known specifications.

The login with biometrics is illustrated with the help of a demo health portal.

1. On the portal, the resident clicks on Sign In with eSignet.

2. To get started with login using biometrics, the resident clicks Login with Biometrics.

3. The resident needs to enter a valid VID in the Enter Your VID text field.

4. Next, the resident selects a device (face/ iris/ finger) and provides their biometrics.

A new "Refresh" button has been implemented to facilitate the display of recently connected devices in the list.

Knowledge Based Identification (KBI) is a security measure to verify the identity of an individual based on information that is typically known only to the individual being authenticated. This method relies on the understanding that the person requesting access to a system or service possesses certain private information that only the legitimate user would know.

In KBI, users are often asked to provide answers to specific questions or prompts that are related to their personal history or identity. These questions could cover a range of topics like:

1. Personal information (e.g., date of birth, address, social security number)

2. Account related details (e.g., last transaction amount, account creation date)

If you are a relying party looking to integrate with eSignet, you can connect with us by completing the here. This will assist us in facilitating a seamless integration on .

Here are some FAQs on the Google form.

Overview

The Signup module is designed with a flexible architecture that allows it to integrate with any Identity Provider (IdP). In this setup, we have provisioned its integration with eSignet to enable seamless user onboarding and identity verification.

To enable this integration, please refer to the configuration details provided in the sections below.

Release Number: v1.4.2(Patch)

Release Date: 22nd Nov, 2024

Overview

We are pleased to announce the patch release 1.4.2 for eSignet. This release includes updates to the missing properties in the docker compose configuration, ensuring a smoother local setup for eSignet. Please note that no changes have been made to the artifacts in this release. The following updates have been added as part of this patch:

A digital ID wallet is a tool or software-based system that stores and manages personal information and identity credentials securely in a digital format. It helps people keep their information organized and protected. This wallet ensures the safety of personal data and makes it easily accessible when needed.

Getting Started: Seamless Access with eSignet

In this user guide, we take the example of a health services portal acting as a Relying Party with eSignet. Residents can quickly and securely identify themselves using their country’s foundation ID system (here, MOSIP), avoiding the hassle of repeatedly filling out account or personal information. This streamlined process ensures faster access to services and benefits while maintaining security and privacy.

1. On the portal, the resident clicks on the button Sign In with eSignet.

The login screen appears, and the resident is displayed with the options they can choose for login.

Please refer for eSignet authentication API documentation.

Services and Rest Endpoints

eSignet leverages a combination of backend technologies to ensure secure identity management and seamless service delivery.

Storage

eSignet utilizes high-performance storage solutions for managing structured and real-time data.

Deployment

eSignet is designed for containerized and automated deployments, leveraging modern DevOps tools.

Testing

eSignet ensures reliability and stability through automated testing frameworks and API testing tools.

Version: 1.7.0

• Name: eSignet

• Date: 2nd December, 2025

Version: 1.6.2

• Name: v1.6.2 (Patch)

• Date: 28th August, 2025

Version: 1.6.1

• Name: eSignet(Patch)

• Date: 29th July, 2025

Version: 1.5.1

• Name: eSignet(Patch)

• Date: 24th Feb, 2025

Version: 1.5.0

• Name: eSignet

• Date: 23rd Jan, 2025

Version: 1.4.2

• Name: eSignet(Patch)

• Date: 22nd Nov, 2024

Version: 1.4.1

• Name: eSignet(Patch)

• Date: 15th July, 2024

Version: 1.4.0

• Name: eSignet

• Date: 23rd April, 2024

Version: 1.3.0

• Name: eSignet (Password based authentication)

• Date: 23rd February, 2024

Version: 1.2.0

• Name: eSignet (VCI)

• Date: 11th December, 2023

Version: 1.1.0

• Name: eSignet (consent registry)

• Date: 22nd September, 2023

Version: 1.0.0

• Name: eSignet

• Date: 14th April, 2023

Version: 0.9.0

• Name: IdP

• Date: 8th January, 2023

Release Name: eSignet

Release Date: 22nd September, 2023

Overview

The 1.1.0 version of eSignet focuses on the Consent Registry feature.

The consent registry is designed to store user consent on claims and scopes requested during login to a relying party application using eSignet or the Wallet application (Inji).

Key highlights of this feature are:

• Storage of user consent against the requested claims and scopes in the database

• If consent is already provided, the consent screen is bypassed when the user logs in using eSignet.

• Recapture consent in the event of changes in requested claims or scopes.

Features Included

Below are the features available in the release:

• Login with OTP

• Login with biometrics

• Wallet based authentication

• Multi-language support

Repositories Released

• eSignet:

• artifactory-ref-impl:

• mosip-config:

For details for deployment go through the helm charts in the .

Documentation

What are Claims?

In the context of authentication and authorization, claims are statements about an entity, such as a user, made by an identity provider (IdP). Claims describe attributes, characteristics, or other properties associated with an entity.

How Claims are Used

Claims are typically packaged into security tokens, such as SAML (Security Assertion Markup Language) tokens or JWTs (JSON Web Tokens). They convey information about the entity's identity and associated permissions.

Importance of Claims

Claims are essential for implementing authentication and authorization processes. Relying parties (e.g., web applications) examine these claims to determine:

• Whether the user should be granted access

• The level of access the user should receive

Claims-based authentication and authorization provide a flexible and standardized approach to identity and access management across applications and services.

Essential and Voluntary Claims

Essential Claims

Necessary user information that the relying party must collect to fulfill service obligations to residents.

Voluntary Claims

Additional user details that residents may choose to provide, enabling access to supplementary features offered by the relying party.

Standard OIDC User Claims Supported

When eSignet is integrated with MOSIP IDA, the following standard OIDC user claims are supported:

• name

• gender

• address

• birthdate

Supported Values in Application Properties

The following properties in application-default.properties hold the supported values:

1. Resident launches the relying party's portal and clicks on Sign In with eSignet.

2. Resident selects the Login with Inji Mobile App option.

1. Now, the resident can scan the QR code displayed on the portal using Inji (on their mobile device).

As seen below, the authentication is in progress.

1. On Inji, the resident can see the VC that is activated for online login. Select the VC and click Verify.

1. After clicking on Verify, the resident is asked to perform face authentication. On successful authentication, the Consent screen is displayed.

1. Here, the residents can provide their consent and click Allow. A successful message is displayed on Inji.

1. The resident can log into the relying party portal and view their details on the user profile page.

While you want to explore eSignet, you can use the following test personas in our Collab environment.

Personas

Individual images are included to facilitate selfie authentication for the Inji application.

Please select the appropriate image file corresponding to the chosen UIN above.

Steps to use eSignet

We have developed a mock health portal that functions as a relying party web portal. As an end user, you can simulate accessing online health services by logging in with your national ID via eSignet.

🔗 Access the Collab Health Portal .

OTP Authentication

To simplify testing with mock data, eSignet supports OTP authentication.

• You can use any of the provided above for testing.

• The default OTP for testing is "111111" (six ones).

For a step-by-step guide on logging in with OTP using eSignet, refer to .

The .well-known folder is a convention used in web development to provide a standardized location for certain files or resources that need to be publicly accessible and discoverable. It typically resides at the root level of a website or web server. The purpose of this folder is to make it easy for web clients (browsers, applications, or services) to find important files or resources related to web services and security.

Why does eSignet use the ".well-known" directory?

eSignet uses the ".well-known" directory to serve the following purposes:

• Standardization: To provide a standardized location for specific public files and resources related to web services and security. It makes it easier for developers and web clients using eSignet to know where to look for important information.

• Security: Security-related files and resources can be placed in the ".well-known" directory, such as the public certificate for encryption and signature verification.

• Interoperability: By following the ".well-known" convention, web developers using eSignet can ensure interoperability with various web standards and protocols. For example, eSignet shares the context file, which contains the structure of its verifiable credentials.

• Ease of Configuration: Web servers can be configured to serve files from the ".well-known" directory without needing custom configurations for each specific resource. This simplifies the server setup and maintenance process.

• Transparency: For matters related to security policies and contact information, such as in the "security.txt" file, placing them in a well-known location makes it transparent and easily accessible to anyone interested in the website's security practices.

How is ".well-known" directory used in eSignet?

eSignet's ".well-know" directory contains the four files mentioned below:

The Key Binder plugin interface provides a method to bind an individual's ID with a public key. On successful binding, it returns a signed certificate called Wallet User ID which uniquely identifies the user and the wallet.

When a new binding request is received, it is expected that the key binder implementation takes care of overriding previously bound certificates with the newly generated signed certificate for a user.

The individual needs to be authenticated before binding the key. The interface is structured to accept any type of authentication challenge, namely OTP or biometrics.

The bound certificate will then be usable to do token-based authentication like WLA (Wallet Local Authentication) from any digital wallet app.

Please refer here for the key binder interface refrence implementation

Who uses this interface?

The APIs exposed by this interface are used by to perform wallet binding while it is implemented by .

How to implement this plugin?

The Key Binder implementation class must be annotated with ConditionalOnProperty with mosip.esignet.integration.key-binder property.

Below is an example of how our has implemented the eSignet KeyBinder plugin.

Appendix - Key Binding

The Key Binding functionality is depicted in the diagram below:

Release Number: v.1.4.0

Release Date: 23rd April, 2024

Overview

Version 1.4.0 of eSignet introduces a new authentication mode and addresses known issues.

1. Knowledge Based Identification (KBI)

   We are excited to share that eSignet has expanded its authentication options to include Knowledge Based Identification (KBI) as one of its factors. With eSignet's integration capabilities, existing ID repositories storing user specific details can now be easily integrated with eSignet. This integration enables OpenID based login, allowing users to access relying party services seamlessly.

To learn more about Knowledge Based Identification, click .

1. Fixes for known issues from v1.3.0

Repositories Released

For details on deployment, refer to the in the eSignet repository.

Documentation

Release Name: eSignet

Release Date: 14th April, 2023

Overview

The 1.0.0 version of eSignet focuses on essential features such as logging in with OTP and logging in with biometrics, along with wallet-based authentication. The subsequent releases will have more features and integration with digital wallet solutions.

Features Covered

The features included in this release are:

• Login with OTP

• Login with biometrics

• Wallet-based authentication

• Multi-language support

Documentation

What is Identity Verifier Plugin?

Identity Verifier plugin helps an external relying party to come as a trusted eKYC partner (verifier). The plugin is used by the verifier to verify an authenticated user (who already signed up with eSignet). An 'authenticated user' can now go to the signup portal, and choose from the list of trusted verifiers, and go through the verification process to update his/her profile with verification metadata and mark claims as verified. With this identity Verifier plugin a video based online verification process has been designed.

The video based process can be used to verify for following:

1. Liveliness check

2. Face match

3. Document verification

4. Disability check

After a successful verification, the verified claims and the verification metadata can be stored in the ID registry which essentially means a successful user verification and thus user creation in the system.

How does it work under the hood?

• Every verification process can consist of any combination of steps.

• Signup service can start the process and end the process when signaled by the chosen verifier.

• The end-step will expect verification details of the User and will update this in the ID registry (against this authenticated end user's individual ID).

How is the 'user authenticated' context shared with the signup portal?

• Authentication of the user before the verification process is carried out in eSignet(OP).

• An authenticated user's transaction is shared as an id_token_hint to the signup portal.

• The signup portal now takes the role of an RP and starts OIDC flow in eSignet with "mosip:idp:acr:id-token" ACR. As the authorize request already contains id_token_hint, the user will not be prompted to enter credentials, However! It may still prompt to user to provide consent, only if required, Most of the time, a "sub" claim in the user info response should suffice the requirement.

Provision to integrate with any Identity verification workflow

The signup service has a provision to add any steps between the start and end step in the verification workflow. We have defined the IdentityVerifierPlugin.java abstract class.

What is it that the Verifier will only need to take care of?

1. Initializing every workflow run with the required configuration based on the provided input.

2. Verify the input frame based on the current step and publish the feedback or details about the next step to start in this run to kafka (publishAnalysisResult concrete method is already defined in the plugin abstract class).

3. Once the verifier decides to end the workflow run, it should hint the signup service by publishing end step details using the same publishAnalysisResult concrete method.

How to add Verifier and its workflow details?

1. Verifier details should be added signup-identity-verifier-details.json

2. Create a JSON file with workflow details, file should be named after the verifier ID as defined in the signup-identity-verifier-details.json

Refer to signup-idv_mock-identity-verifier.json the sample workflow details file. Note the file name is prepended with constant "signup-idv_"

Sequence Diagram

Please refer to the sequence diagram below for the detailed working flow of the identity verifier plugin.

Please for the Identity Verifier Plugin reference implementation.

Digital Wallet Credential Management

A digital wallet that aims to function as a credential holder application in eSignet must go through the onboarding process as a relying party. This document outlines the necessary steps for a wallet to utilize eSignet for downloading credentials issued by a VC Issuer using the OpenID4VCI authorization code flow.

The sequence diagram below illustrates the steps involved in the authorization code flow that are required for downloading a verified credential.

Sequence Diagram

Below are the steps for on-boarding a digital wallet as an OAuth Client and using the eSignet APIs to download verifiable credentials.

Onboard as OAuth Client

1. Get a valid redirect deep link

eSignet adheres to the OpenID4VCI wallet-initiated flow. Consequently, after authentication is completed, eSignet will provide the wallet with an authorization code. Thus, to integrate, the wallet must first generate a valid redirect deep link.

2. Get OAuth client credentials

The wallet can utilize the eSignet client management APIs to formally register as an OAuth client and obtain the necessary client credentials. This will facilitate their connection with eSignet.

To register the client in our Sandbox environment, click .

Authorization Code flow

1. Call the authorized endpoint

In order to initiate the credential issuance flow, the credential holder needs to authenticate and provide consent. Hence, the wallet needs to create a button to initiate authentication using eSignet by calling the "/authorize" endpoint.

This process would redirect the user to a web view of eSignet's authentication screen. In this screen, the user will need to authenticate their identity and give consent to share their credentials.

Upon successful authentication and consent, the authorization code will be sent back to the wallet application through the designated redirect deep link that has been configured.

2. Retrieving the access token and c_nonce

The wallet app now needs to extract the authorization code (auth-code) parameter in the redirected deep link and exchange the authorization code to get the access token and c_nonce from the eSignet server.

3. Generate key pair

The wallet now needs to generate a key pair for the wallet holder and use the private key from the key pair to sign the c_nonce. This will be used to determine that the (PoP) of the private key is the wallet holder.

Corresponding public key is accepted as did:jwk in the PoP.

Note:

• eSignet does not mandate to create a different key pair for a holder on each credential request. it is left to the discretion of the wallet implementer.

• Only jwt Proof Type is currently supported.

4. Get the credential using VCI credential API

Now, the wallet can invoke the "/vci/credential" endpoint of credential service with PoP (Proof of Possession) and share the credential format metadata to get the Verifiable Credential in the requested format.

Only the ldp_vc format in the is supported.

Once the credential is obtained, the wallet should be responsible for securely storing it.

For a digital wallet to function as an authenticator using eSignet, it is necessary to have the user's credentials and ensure that the user's ID in the credential is securely linked to eSignet.

In this document, we will be discussing the application programming interfaces (APIs) that need to be invoked by the wallet application for executing the process of binding and subsequently performing wallet local authentication.

Wallet Binding APIs

As previously stated, before initiating authentication in eSignet, it is necessary to associate the user's ID with the wallet's public key.

eSignet offers endpoints to request a one-time password (OTP) for this association, followed by another API to bind the public key of the wallet to the user's ID.

Here, the challenge can be the OTP or any other authentication type supported by eSignet, like biometrics.

Once the user successfully completes the binding process, their wallet will be assigned a unique user ID and receive a signed certificate from eSignet. This certificate will have an expiration time, and as a result, it will be necessary for the user to periodically reinitiate the wallet binding. It is important for the wallet to securely store this certificate and associate it with the respective Wallet User ID for proper mapping.

Wallet Authentication APIs

To utilize the wallet with a secured credential for authentication, users are required to follow these steps:

• Firstly, users need to visit a relying party website that has enabled eSignet authentication through the wallet.

• Next, users should use the wallet application to scan the QR code provided on the website. This will establish a connection and initiate the authentication process.

• The wallet application will identify a link code within the QR code, which is essential for initiating the authentication.

• To begin the authentication, the wallet will send the link code to the eSignet server using the "/linked-authorization/v2/link-transaction"

Appendix - Wallet Local Authentication

The diagram below illustrates the process of wallet local authentication in eSignet through the use of a digital wallet.

The image below is a block diagram of the sign up portal comprising various components along with the different layers and external systems.

Signup UI

This is the user interface component of the Signup portal is developed using React JS. Its main functionality is to handle user registration and eKYC verification. Signup UI seamlessly integrates with the UI REST endpoints provided by the signup service. The Signup UI supports multiple languages. Signup UI verifies the OTP before the user registration. A notable feature added in the signup UI is to carry out video-based eKYC verification.

Signup Service

This service is the primary backend spring Java application that incorporates various layers.

1. Services: This layer defines the services implemented in the signup service. Registration service implements all the business logic related to OTP verification and the registration process. As we currently support a video-based online eKYC verification process, it requires two-way communication between UI and the backend service. To support this we establish a WS connection between signup UI and signup service, WebSocket Handler manages the WebSocket connection. eKYC verification service contains the logic to initiate and manage the eKYC verification transaction.

2. Rest APIs: This layer exposes REST endpoints for the functionality implemented in the service layer.

3. Cache Layer: The signup service maintains complete transaction details in the cache. Currently, supports “simple” and “redis” cache types.

eKYC Verifiers

Trusted claim providers are authorized(depending on policies and regulations) to carry out an identity verification process in which the user is asked to provide proof and prove legitimacy concerning the user's account.

ID Registry

An ID Registry is a system or database that stores and manages identity information about individuals or entities. An ID Registry is a critical part of digital identity management, acting as a centralized repository for authenticating and verifying the identity of users. In the context of the Signup Portal, the ID Registry could refer to any external system or service that stores user identity information. When a user registers, the Signup Service may interact with an ID registry to validate and store details like the user’s email, phone number, or even government-issued ID, ensuring that the identity is legitimate and unique.

Test Report

Scope

The eSignet testing scope revolves around the following flows:

• Login with OTP

• Login with Biometrics (mock and real device)

• Multiple instances of eSignet

• Cross-browser testing: eSignet flow verification in different browsers (Chrome, Microsoft Edge, Firefox, Opera, Safari)

Test Execution Statistics

Functional Testing

• Stories Verified: 10

• Test cases: 401

  • Passed: 386

  • Failed: 9

Device Based Testing

• Test cases: 12

  • Passed: 11

  • Failed: 1

  • Skipped: 0

API Testing

• Test cases: 261

  • Passed: 261

  • Failed: 0

  • Skipped: 0

Release Number: v.1.3.0

Release Date: 14th March, 2024

eSignet supports integration with both and systems for authentication and identity verification.

The integration flow and configuration steps remain identical for both options, the only difference lies in the discovery endpoints, which determine the environment and underlying ID system you connect to.

eSignet now supports dynamic UI rendering based on the purpose defined by the relying party (client) during client registration. This enhancement ensures that the user experience is tailored and context-aware across different workflows such as Login, Verify, or Link.

Why Purpose-Based Rendering?

Different service interactions require different messaging and UI contexts. For instance:

Overview

The JSON Web Key Set (JWKS) is a collection of public keys used to verify any JSON Web Token (JWT) issued by the Authorization Server. These keys are signed using the RS256 signing algorithm and are exposed through the JWKS well-known endpoint for relying parties to fetch and use for token verification.

Json JWKS Well Known Configuration

The section containing integration guides for the SignUp portal offers valuable resources to help integrate the portal with external systems. These guides provide detailed instructions for seamless communication between the SignUp portal and various third-party services.

1. The guides cover integrating external systems such as identity verification platforms and authentication services with the SignUp portal.

2. They also provide instructions for integrating data management systems to ensure smooth data flow and secure processing during user registration.

Release Number: v1.5.1(Patch)

Release Date: 24th Feb, 2025

Overview

We are excited to announce eSignet v1.5.1, which resolves critical issues to improve user experience and system functionality. Key fixes include IDT authentication, KYC slot availability, and an updated README.md file for the docker compose setup of the signup service. These updates ensure more reliable and efficient access to services.

Major Highlights

1. Fixed bug in IDT authentication: Resolved issues related to invalid individual ID handling, including incorrect individual IDs provided in the request body.

2. Reused Challenge Authentication: Added validations for reused challenge IDT(ID token)-based authentication, ensuring it now functions correctly.

3. Periodic Slot Availability Checks in UI: Added support for periodic slot availability checks during the loading screen process, based on configuration.

Bug Fixes

• Several known issues from v1.5.0 have been resolved to improve platform stability. A detailed list of fixes is available .

We believe this release will greatly improve eSignet's security, efficiency, and user experience.

Thank you for your continued support!

Key Known Issues

Please refer to for the list of all known issues.

Repositories Released

Compatible Modules

DB Changes

eSignet

• Changed public_key column data type to JSONB in the client_details table. Please refer for details.

eSignet mock services

• The length limit on the identity_json column has been removed from the identity database. Please refer for details.

Config Changes

eSignet mock services

• Introduced json schema based validation. Below two properties are added:

  1. mosip.mock.ida.identity.schema.url

  2. mosip.mock.ida.update-identity.non-mandatory.fields

Please refer for details.

Documentation

Release Number: v.1.4.1

Release Date: 15th July, 2024

Overview

This release introduces new features centered on Verifiable Credentials (VC) issuance plugins related to Sunbird RC, enhances configuration capabilities for Knowledge-Based Identification (KBI), and addresses critical known issues from previous versions.

Features

1. Features included

We have developed two new plugins to support the issuance of verifiable credentials (VC) by authenticating users through Knowledge-Based Identification (KBI) using the Authenticator plugin. These enhancements are detailed below:

a.

• Implementation of the Authenticator plugin to enable Knowledge-Based Identification (KBI) within Sunbird RC.

b.

• Implementation of the VC Issuance plugin to facilitate the issuance of verifiable credentials within Sunbird RC.

c. .

• eSignet UI now supports KBI form configuration, making it easier to set up and manage KBI-based identification.

For more information on KBI, please refer to the

Bug Fixes

Fixes from v1.4.0:

• Improved Input Field Validations: Enhanced input field validations using regex implementation.

• User-Friendly Error Messages: Improved error messages for better user experience.

Fixes from v1.3.0:

• eSignet Service Fixes: Critical and major bug fixes related to the eSignet service.

• eSignet Signup Service Fixes: Critical and major bug fixes related to the eSignet Signup service.

For a complete list of all bugs addressed in this release, please refer to the .

Known Issues

• Key Known Issue:

Please refer to for the list of all known issues.

Repositories Released

For details on deployment, refer to the in the eSignet repository.

Documentation

Testing Scope

The scope of testing is to verify fitment to the specification from the perspective of

● Functionality

● Deployability

● Configurability

● Customizability

Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence, the Configurability and Extensibility of the software is also assessed. This ensures the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, the Verification scope required comprehensive automation testing for all the MOSIP APIs. An automated Test Rig is created for the same.

Test Approach

Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble a real-time implementation.

A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software, and thereby determines use cases/scenarios that the customers will execute. The persona's needs may be addressed through any of the following.

● Functionality

● Deployability

● Configurability

● Customizability

The verification methods may differ based on how the need was addressed.

For regression check, “MOSIP Test Rig” - an automation testing suite - is indigenously designed and developed for supporting persona based testing. MOSIP Test Rig covers the end to end test execution and reporting. The end to end functional test scenarios are written starting from pre-registration, to the creation of the packet in the registration center, processing the packet through the registration process, generating UIN, and authenticating identity using IDA through various permutations and combinations of cases being covered. MOSIP Test Rig will be an open source artifact that can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider, etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.

Verified Configuration

Verification is performed on various configurations as mentioned below

● Default configuration - with 7 Lang (English/Khmer/Hindi/Kannada/Tamil/Arabic/French).

Main Features Tested:

• Signup Portal

• Login with Password

• Forgot Password

• Login with OTP

Feature Health

Test Execution Statistics

Functional Test Results

Below are the test metrics by performing functional testing using mock MDS, mock Auth, and mock ABIS. The process followed was black box testing which based its test cases on the specifications of the software component under test. The functional test was performed in combination with individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, End-To-End flows across multiple languages and configurations. The testing cycle included the simulation of multiple identity schema and respective UI schema configurations.

Test Rate: 99% with Pass rate: 97%

Here is the detailed breakdown:

1. API Based Testing - eSignet

Total Test Cases: 1601

• Passed - 1555

• Failed - 44

• Skipped - 2

1. UI Based Testing

Total Test Cases: 664

• Passed - 636

• Failed - 15

• Skipped - 13

API Testrig Results for eSignet and Mimoto:

API Based Testrig - eSignet

Total Test Cases: 1116

• Passed - 1111

• Failed - 3

• Skipped - 2

Detailed Test Metrics

Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking, and efficiency.

The various metrics that assist in test tracking and efficiency are as follows:

● Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100.

● Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100.

Sonar Report:

eSignet:

eSignet Signup Repo:

Overview

eSignet Auth is a modular, standalone identity authentication service designed to enable secure and flexible user verification across digital ecosystems. Built on open standards, it implements OAuth 2.0 and OpenID Connect protocols, functioning as both an authorization server and a resource server.

1. Designed for Inclusivity

eSignet Auth ensures that digital authentication is accessible and adaptable for all, regardless of device type or user capability.

• Multiple Authentication Factors Supports a variety of methods including OTP (for feature phones), biometrics (iris, face, fingerprint), and wallet-based face authentication (for smartphone users). These modes ensure inclusive access across different user demographics and contexts.

• Customizable Authentication Workflows Flexible by design, eSignet Auth can be tailored to meet country-specific, sector-specific, or application-specific requirements. New authentication methods can be easily added and existing flows modified without major system changes.

2. Standards-Based ID Authentication with High Assurance

eSignet Auth delivers secure identity verification through a standards-compliant and assurance-driven approach.

• OAuth 2.0 and OpenID Connect Based Uses established OAuth 2.0 flows and OpenID Connect for secure, token-based identity authentication, enabling seamless and reliable integration with existing systems.

• Support for High Assurance Biometrics Enables robust identity authentication using iris, face, or fingerprint recognition. These high-assurance modalities are ideal for accessing sensitive services such as healthcare, financial services, and government platforms.

This combination of standards compliance and biometric authentication ensures strong, verifiable digital identities with configurable assurance levels.

3. How It Builds Trust

Trust is foundational to eSignet Auth’s architecture, achieved through strong privacy controls, consent-driven design, and secure token handling.

• Consented User Data Sharing Personal data is shared only after explicit, informed user consent. The consent flow is embedded into the authentication process and mandatory for data access.

• No Data Storage eSignet Auth does not store any personally identifiable information (PII). It acts solely as a verification and authentication layer, reducing exposure to privacy risks.

• Prevention of Unwanted Profiling Issues relying-party-specific user tokens for each relying party, ensuring that user activity cannot be tracked or correlated across services—thus preserving privacy and stopping cross-service profiling.

4. Seamless Integration Across Ecosystems

eSignet Auth is built for flexibility, allowing it to plug into various components across digital identity and service delivery ecosystems.

• Compatible with Any ID System Integrates easily with any centralized or federated identity system. Its standards-based framework allows it to work with a wide variety of ID registries and data structures.

• Connects with Any Relying Party (Service Portal) Service providers—such as banks, government departments, healthcare portals, and telecom services—can authenticate users through eSignet Auth with minimal integration effort. The use of standard APIs and protocols enables quick and secure onboarding.

This ecosystem-agnostic design ensures that eSignet Auth can serve as a unifying layer for identity authentication across sectors.

5. Summary

is a powerful, secure, and inclusive authentication module that can be deployed as part of a digital ID system or independently.

It offers:

• Inclusive access through multiple, customizable authentication methods

• Secure and standards-compliant identity verification using OAuth 2.0 and OpenID Connect

• High-assurance options via biometric authentication (iris, face, fingerprint)

• Consent-driven data handling with no storage of user PII

Whether used by governments, enterprises, or technology providers, eSignet Auth delivers a trusted, flexible, and future-ready solution for digital identity authentication.

Please take a moment to watch the video below to explore valuable insights into eSignet and its wide array of powerful features!

Documentation

• Now you can self generate your own UIN Credential using the Collab environment.

  • Click on the Get UIN button located at the top-right corner of the page. This will open the Self Registration Form, Alternatively, you can simply click on this link to self register. You need to duly fill the self registration form.

  • On successful registration the UIN is sent to you over the email you used for registration, For more details you follow the Generating Demo Credentials Guide.

You will be able to explore eSignet’s capabilities and experience seamless authentication through various channels.

Step-by-Step Process

To experience the various methods of login and authentication in the demo health services portal using eSignet, follow the detailed instructions below:

Step 1: Access the health services portal

Navigate to the relying party’s demo portal in the Collab environment, and click on Sign In with eSignet.

Step 2: Explore the various authentication mechanisms

OTP Authentication

Once you receive your UIN/VID, you can navigate to the and try authenticating using your UIN/VID and the default OTP, i.e. "111111" (six ones).

A detailed step-by-step guide on how to log in with OTP using eSignet is also available .

Biometrics-based Authentication

Mock biometrics setup

• To enable biometrics-based login, ensure that your machine is running Windows.

• Make sure you have Java 11 or a higher version installed on your computer.

• Download the collab-mock-mds-auth.zip file from the link provided .

• Unzip the downloaded file to extract its content.

Experience the process of logging in using biometrics, by following the instructions provided .

Authentication using Wallet

For our testing, we have integrated with , which we can use as an authenticator.

To get your credentials onboarded on Inji and enable them for authentication, follow the below steps,

1. Install the Inji APK on your mobile device using

2. Download your credentials on Inji. For details on how to download the credential, click (Refer to step 3 in the guide)

3. Ensure that you have activated your credentials for online login. This step is crucial for wallet-based authentication to work smoothly. For a comprehensive guide on how to activate the VC for online login, refer

Once you are done with the above steps, you can use the Inji wallet to log into the health portal. The detailed steps to log into the health portal using the Inji wallet are available .

Additional Video Resource

• Watch this informative video to gain insights into eSignet.

• Explore the video for a practical demonstration of the authentication process.

• Watch - A quick comprehensive guide for local implementation for eSignet versions up to 1.4.2

• Click for detailed information about eSignet.

By adhering to these guidelines and making use of the available resources, you will be able to smoothly experience the different methods of login and authentication offered by eSignet. This will guarantee secure and efficient access to the services you require.

Get in Touch

If you require any assistance or encounter any issues during the testing and integration process, kindly reach out to us through the support mechanism provided below.

• Navigate to .

• Provide a detailed description of the support you require or provide detailed information about the issue you have encountered, including steps to reproduce, error messages, logs, and any other relevant details.

The eSignet system introduces enhanced flexibility in configuring login ID types to better align with country-specific needs and business requirements. This allows implementation teams to tailor login experiences based on regional standards, supported ID types, and UI preferences.

Overview

eSignet now supports dynamic configuration of login identifiers, giving implementation teams the ability to:

• Enable or disable specific login types (e.g., Mobile Number, NRC ID, Email, VID).

• Display country-specific prefixes dynamically.

• Configure SVG icons to visually represent each login method in the UI.

By default, VID is shown as the primary login ID. However, this can be extended and customized through configuration.

Country-Specific Configuration

Login options available to users can vary depending on the country or deployment region. As for an example:

• A Mobile Number login can display country-specific prefixes like +91 (India), +855 (Cambodia), or +1 (USA).

• These prefixes are shown dynamically in the UI based on the selected login ID type.

This ensures a localized and intuitive login experience for users around the world.

SVG Icon Configuration

Each login ID type can be associated with a custom SVG icon that visually represents the identifier in the login interface.

• These icons are displayed next to their corresponding input fields.

• Icons can be configured to match branding and UI themes.

Configuration Format

All login ID types and their respective properties are defined in the eSignet configuration file:

File: application-default.properties Key: mosip.esignet.ui.config.login-id.options

Example Configuration

Summary

With the new login ID configuration feature, eSignet allows:

• Full control over which login types to show.

• Custom display of country codes for mobile login.

• Visual customization using SVG icons.

• Easy configuration through application-default.properties.

This level of flexibility makes eSignet highly adaptable for diverse identity systems and regional deployment requirements.

Sign up and Try Video eKYC

Use the eSignet Signup service to register and create your user profile. Follow the steps below to complete registration and experience the video eKYC verification flow.

1. The user navigates to the portal.

2. They click on the Sign in with eSignet to initiate the registration process.

The login screen appears, displaying the available login options for the user.

1. To begin the signup process, click on Sign up with Unified Login, located at the bottom of the page.

1. Enter your 8-9 digit mobile number in the provided field and click Continue to proceed.

1. Enter the OTP received on the mobile number and click Verify.

1. A success message confirming the mobile number verification is displayed. Click Continue to proceed with setting up your account.

Clicking Continue redirects the user to a page where they can enter basic personal details to set up their account.

1. Enter your name and create a password. Ensure you agree to the terms and conditions by selecting the checkbox, then click Continue to complete the account setup.

1. The user is successfully registered, and a confirmation message is displayed. The user can now log in using their registered mobile number. Click Login to proceed.

1. The login screen appears, displaying the available login options for the user. To proceed, the user selects the Login with OTP option.

1. Enter the mobile number used during account setup in the previous steps and click Get OTP.

1. The user receives the OTP through their registered channel (either via phone or email). Enter the valid OTP in the provided field and click Verify to proceed.

1. An attention screen with a list of claims is displayed and the user is asked to confirm to proceed with eKYC. Click on Proceed to continue.

1. The user is now redirected to the page where the steps for the eKYC process are listed. Click on the Proceed option to continue.

1. Choose an eKYC provider and click on the Proceed option.

1. Select the I Agree to the ‘Terms & Conditions’ checkbox and click on the Proceed option to continue.

1. A video preview is displayed along with general guidelines to be followed during the video eKYC process.

1. The eKYC process is initiated please follow the instructions on the screen to complete the process.

1. A verification success message is displayed.

1. Once the verification process is completed successfully. A consent screen is displayed to the user to confirm the sharing of the user's information. Click on Allow to continue.

1. Once the consent is given the user data is shared with the service provider and the user lands on the home page of the service portal with user details displayed.

This completes the eKYC verification process for the user.

The image below represents a block diagram of eSignet, illustrating various components, layers, and external systems that work together to provide secure identity verification.

eSignet Components

Relying Party System

The Systems depend on identity providers, such as eSignet, to authenticate and verify the identities of users before granting them access to protected resources or services.

Clients utilizing OpenID Connect within the OAuth 2.0 framework are commonly referred to as Relying Parties (RPs).

In the case of VC issuance, they are simply OAuth 2.0 clients. To ensure enhanced security, eSignet exclusively supports confidential clients.

Digital Wallet

are software-based platforms used to securely store and share the certified credentials of the wallet holder. Stored credentials can be used for login with the eSignet, once the credentials are binded with the RSA key pair and the corresponding public key is shared with eSignet.

To know more about the key binding process please refer to .

eSignet UI

This is the user interface component of eSignet, developed using React JS. Its main functionality is to handle user authentication and obtain user consent. eSignet UI seamlessly integrates with the UI REST endpoints provided by esignet-service.

• One notable feature of the eSignet UI is its support for multiple languages.

• eSignet UI also offers QR code-based login with support for multiple digital wallets.

• In addition, eSignet UI is compatible with MOSIP SBI 2.0 for biometric capture.

• Furthermore, the eSignet UI provides flag-based captcha validation for OTP login.

eSignet Service

This service is the primary backend Spring Java application that incorporates various layers and integrates with other components mentioned on this page.

1. Core components: The eSignet core library is used to manage core service interfaces, constants, exceptions, validators, and utility methods.

2. Service layer: This layer represents the implementation of the interfaces defined in the eSignet core library. Each protocol implementation is a separate service, such as the complete OIDC protocol implementation being part of the oidc-service and VCI protocol implementations residing in the vci-service.

   • Service modules utilize caching to enhance transaction access and update speeds, as well as to prevent the need for persistent storage of transaction details.

All plugin interfaces are defined in the module.

Sign up Portal

The provides a user-friendly registration interface that allows users to securely create and manage accounts.

Identification System (ID system)

The ID System is a fundamental identity repository that stores demographic and biometric details (if applicable).

• Storage Options: This can be a database or a dedicated system.

• Verification & Data Sharing: Facilitates identity verification and enables secure data exchange with eSignet.