# eSignet ## Overview A Modern and Inclusive Digital Identity Authentication SolutionDigital identity is rapidly becoming the standard means of citizen identification across both government platforms and private service portals. As access to services increasingly relies on digital channels, secure user authentication has become a critical requirement. To ensure privacy, security, and inclusivity, authentication mechanisms must adhere to established standards that protect user data and foster trust between citizens, service providers, and governments. #### Where Does eSignet Fit In? eSignet plays a critical role in this landscape by providing a secure, standards-compliant digital identity solution that empowers both users and service providers. It enables: * **Trusted identity verification across platforms** — establishing confidence in a user's identity whenever they access a government or private-sector service, using verifiable, standards-based credentials instead of platform-specific logins. * **Flexible login and authentication methods tailored to various assurance levels** — allowing service providers to choose an authentication method that matches the level of assurance their use case requires, from low-risk logins to high-assurance transactions. * **Inclusive access designed to serve diverse user groups and device capabilities** — ensuring that people with smartphones, feature phones, or no phone at all can still authenticate through a method suited to their situation. * **Consent-driven data and profile sharing, ensuring transparency and user control** — every exchange of personal data happens only after the user has explicitly agreed to it, with clear visibility into what is being shared and with whom. 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, it gives both users and service providers the confidence and control they need to transact digitally. **Refer below to know more:** **Cards** # Welcome Everything you need to build, deploy, and manage eSignet. Welcome to the platform. These docs cover everything from your first project to advanced workflows — pick a starting point below or ask the Assistant to jump straight to what you need. *** {% hint style="success" icon="sparkles" %} **New: scheduled deploys and team-level audit logs.** Schedule deploys for any future date and review every action taken in your workspace. See what's new {% endhint %} ## Where to start


Getting started	Set up your account and ship your first project in minutes.	Broken link
Core concepts	Understand workspaces, projects, and how permissions work.	Broken link
Guides	Walkthroughs for common tasks like custom domains and automations.	Broken link
Reference	Detailed configuration options, limits, and terminology.	Broken link

## Popular tasks


For builders	Broken link	Broken link	Broken link
For admins	Broken link	Broken link	Broken link
For developers	Broken link	Broken link	Broken link

# Overview A Modern and Inclusive Digital Identity Authentication Solution Digital identity is rapidly becoming the standard means of citizen identification across both government platforms and private service portals. As access to services increasingly relies on digital channels, secure user authentication has become a critical requirement. To ensure privacy, security, and inclusivity, authentication mechanisms must adhere to established standards that protect user data and foster trust between citizens, service providers, and governments. ### Where Does eSignet Fit In? eSignet plays a critical role in this landscape by providing a secure, standards-compliant digital identity solution that empowers both users and service providers. It enables: * **Trusted identity verification across platforms** — establishing confidence in a user's identity whenever they access a government or private-sector service, using verifiable, standards-based credentials instead of platform-specific logins. * **Flexible login and authentication methods tailored to various assurance levels** — allowing service providers to choose an authentication method that matches the level of assurance their use case requires, from low-risk logins to high-assurance transactions. * **Inclusive access designed to serve diverse user groups and device capabilities** — ensuring that people with smartphones, feature phones, or no phone at all can still authenticate through a method suited to their situation. * **Consent-driven data and profile sharing, ensuring transparency and user control** — every exchange of personal data happens only after the user has explicitly agreed to it, with clear visibility into what is being shared and with whom. 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, it gives both users and service providers the confidence and control they need to transact digitally. #### Keep reading:

Cover image	Cover image
	About eSignet.png	What is eSignet?
	Features Card.png	Features
Principles	Principles Card.png	Principles
	License Card.png	License
	ChatGPT Image Sep 7, 2026, 07_10_00 PM.png	Standards
	Technology card.png	Technology

# What is eSignet? eSignet is a powerful, open-source digital identity authentication platform that enables secure and standardized access to online services. It is developed by [MOSIP](https://www.mosip.io/) and built by implementing specific [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) RFCs, giving it the foundation to provide high-assurance identity verification, and it functions as both an authorization server and a resource server within the systems it is deployed into. eSignet is designed to function independently as a standalone authentication module, and it can be integrated with any identity system or repository that supports authentication and attribute retrieval. While it includes reference integrations with MOSIP, its architecture is open and flexible enough to be adopted across a wide range of digital service ecosystems, not just MOSIP-based ones. eSignet is also fully open-source and vendor-neutral, so adopting it does not lock an organization into a single vendor's roadmap or pricing — its code, standards compliance, and integration paths are all transparent and available for inspection. Whether the use case is a citizen portal, a financial application, or any service that requires identity verification, eSignet can serve as a trusted, modular identity layer. At a glance, it supports login through OTP, biometrics, and wallet-based methods; enforces configurable, user-driven consent; supports multiple levels of identity assurance; and complies with security standards including [OpenID Connect](https://openid.net/developers/how-connect-works/), [OAuth 2.0](https://oauth.net/2/), and the [FAPI 2.0 Security Profile](https://docs.esignet.io/home/esignet-2.0.0/readme/pages/Tk3eiHfyOsvmzvqNZGRg#id-3.-supported-rfcs) — the full breakdown of these capabilities is covered in [Features](/home/esignet-2.0.0/readme/features). ### How eSignet Builds Trust Trust is foundational to eSignet's architecture, and it is achieved through strong privacy controls, consent-driven design, and secure token handling rather than through policy alone. * **Consented user data sharing**: personal data is shared only after explicit, informed user consent. The consent flow is embedded directly into the authentication process and is mandatory before any data access takes place. * **No storage of personal data**: eSignet does not store any personally identifiable information (PII). It acts solely as a verification and authentication layer, which reduces the platform's exposure to privacy risk since there is no central store of user data for an attacker to target. * **Prevention of unwanted profiling**: eSignet issues relying-party-specific user tokens for each relying party it serves, which means a user's activity with one service cannot be tracked or correlated with their activity on another. This preserves user privacy and actively prevents cross-service profiling, rather than merely discouraging it through policy. ### Seamless Integration Across Ecosystems eSignet is built for flexibility, allowing it to plug into a wide range of components across digital identity and service delivery ecosystems. * **Compatible with any ID system**: eSignet integrates with any centralized or federated identity system. Its standards-based framework allows it to work with a wide variety of ID registries and underlying data structures, rather than requiring a specific one. * **Connects with any relying party (service portal)**: service providers such as banks, government departments, healthcare portals, and telecom operators can authenticate users through eSignet with [minimal integration](/home/esignet-2.0.0/develop/integration/relying-party) effort. Its use of standard APIs and protocols enables quick and secure onboarding rather than a custom integration for every new service provider. This ecosystem-agnostic design allows eSignet to serve as a unifying identity authentication layer across sectors, rather than a solution tied to one industry or one type of identity system. ### Inclusive by Design eSignet is engineered to ensure inclusive access to digital identity verification, supporting multiple verification models to meet the varied needs of users and the devices they use. Digital authentication is only as inclusive as the range of methods it supports, so eSignet is built to remain accessible and adaptable for all users, regardless of device type or individual capability. * **Assisted verification and data collection**: identity verification carried out with the help of an operator, or at a physical kiosk, for users who are unable or prefer not to self-verify online. * **Self-identification for online services**: identity verification that users complete independently through remote digital channels, without needing an operator or a physical location. The specific authentication factors available under each of these models — OTP, biometrics, wallet-based login, and more — are covered in [Features](/home/esignet-2.0.0/readme/features). Please take a moment to watch the video below to explore valuable insights into eSignet and its wide array of powerful features! {% embed url="" %} ### **Who is esignet for?** * **Government agencies**: eSignet offers a secure, standards-based identity verification layer that helps transform existing identity systems into interoperable digital identities, without requiring those agencies to build an authentication layer from scratch. * **Service providers**: eSignet enables efficient service delivery through secure identity verification, eKYC, and consent-based data access across sectors such as banking, telecommunications, and insurance, so providers can verify users without operating their own identity infrastructure. * **Citizens and residents**: eSignet empowers individuals to prove their identity securely and conveniently, while preserving their privacy, across a broad range of digital services — from a single trusted identity rather than a separate credential per service. * **Developers and system integrators**: eSignet provides a comprehensive set of tools and standards that enable seamless integration of digital ID authentication and eKYC functionality into new and existing services. Whether it's deployed by a government, an enterprise, or a technology provider building on top of it, eSignet is designed to deliver a trusted, flexible, and future-ready foundation for digital identity authentication. ### **Potential use cases** * **Healthcare**: Patients use OTP or biometrics to access health portals securely, ensuring inclusive access to medical services regardless of the device they have available. * **Education**: Universities leverage face authentication for secure access to exams or hostel services, improving both security and accessibility for students. * **Social welfare programmes**: eSignet enables precise distribution of benefits to verified and eligible recipients, reducing the risk of benefits reaching the wrong person. * **Taxation**: eSignet facilitates simplified tax filing and accurate taxpayer identification, reducing friction for taxpayers while maintaining verification integrity. * **Voting systems**: eSignet ensures secure and reliable voter authentication during elections, helping protect the integrity of the voting process. * **Banking**: eSignet supports secure customer onboarding and transaction verification, giving banks a standards-based way to confirm who they're transacting with. * **Insurance**: Verified KYC data with high assurance levels enables faster, compliant onboarding, promoting financial inclusion for customers who might otherwise face lengthy manual verification. * **Border control**: eSignet enhances national security by verifying the identity of travelers and supporting secure cross-border movement. {% hint style="info" %} **Note:** 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. {% endhint %} # Migration to Go ### Background eSignet was originally built on Java, and the platform's early growth, its adoption across implementations, and its maturity as a standards-compliant identity solution were all built on that foundation. As eSignet's role has expanded, however, so has the case for revisiting what runs underneath it. This page lays out why the eSignet team made the decision to migrate the platform's core authentication engine to Go, what approach was taken to get there, and what it means for the product going forward. It is a deliberate architectural decision, made for two concrete reasons: long-term sustainability through shared engineering ownership, and a meaningful gain in runtime performance. Both are explained below, along with the approach taken to realize them without disrupting anything the product already promises its users and adopters. ### The Case for Migration #### 1. Sustainability Through Shared Ownership Open-source infrastructure is only as durable as the community maintaining it. For most of its life, eSignet's core engine has been maintained by a single team. That's workable, but it isn't the most resilient model for a piece of infrastructure that governments and service providers are expected to depend on for years. The opportunity to move to Go emerged directly from this concern. [WSO2](https://wso2.com/), **an established identity and access management vendor**, had already built and was actively maintaining [Thunder ID](https://thunderid.dev/) (referred to elsewhere in these docs as the [ThunderID engine](https://github.com/thunder-id/thunderid)), a Go-based identity engine addressing much of the same problem space as eSignet. Rather than build a comparable engine from scratch and maintain it alone, eSignet's team chose to build on top of Thunder, adapting and extending it to meet the OpenID Connect and FAPI 2.0 compliance eSignet requires as a national-scale identity backend. This changes eSignet's maintenance model in a substantive way. The core engine now has two engineering teams with a direct stake in its correctness, security, and continued development, eSignet's own team and WSO2's. Improvements, hardening, and bug fixes made to Thunder for any reason benefit eSignet as well, and the reverse holds true. This kind of shared ownership is a stronger long-term guarantee of maintainability than any single team can offer on its own, and it's the primary reason this migration was worth undertaking. #### 2. Performance and Efficiency The second driver is more straightforward: Go, as a runtime, is materially better suited to the kind of high-throughput, low-latency authentication workloads that a national identity backend needs to sustain. In practice, this has translated into eSignet achieving meaningfully better throughput on comparable or smaller infrastructure footprints than the Java-based engine required. For adopters, this matters in very concrete terms: lower hosting and scaling costs from better throughput per unit of infrastructure, more headroom under peak load (such as large-scale enrollment drives or high-traffic authentication events), and a system that stays responsive as usage grows without a proportional increase in resource spend. ### The Approach: Building on Thunder, Not Apart From It #### Two Products Built for Two Different Problems It's worth being precise about what Thunder is, and isn't. Thunder was built by WSO2 as an enterprise identity and access management engine, designed to secure workforce identity, internal applications, and enterprise service ecosystems. eSignet exists to solve a different problem: it is a country- and government-focused digital identity layer, built specifically to implement the global interoperability standards that let a nation's foundational ID system work seamlessly across banking, healthcare, welfare, and every other sector that depends on trusted identity verification. [Thunder](https://thunderid.dev/) gave eSignet a mature, high-performance, Go-based identity core, but an enterprise-grade engine does not, on its own, make a standards-compliant national identity backend. That compliance layer is what the eSignet team has added on top of Thunder: FAPI 2.0 compliance, along with the assurance levels, consent architecture, and eKYC capabilities that are specific to eSignet's mandate. Thunder was not built with all of these standards natively; eSignet's engineering work is what makes the combined system compliant with them. #### One Codebase, Kept in Sync Rather than maintaining a Go-based engine as a separate, parallel codebase, eSignet is built as a layer on top of Thunder ID itself, using Thunder ID's repository as the foundation and adding the eSignet-specific product layer on top of it: its OIDC and FAPI 2.0 compliance behavior, consent handling, biometric and OTP authentication support, verified claims, and everything else that constitutes eSignet's product experience. This means eSignet's engine tracks Thunder's ongoing development directly. As WSO2 continues to develop and harden Thunder, eSignet inherits those improvements as a natural part of staying current with its upstream, rather than through a separate porting effort each time. The two projects develop in an ongoing collaborative relationship rather than a one-time handoff, which is precisely the sustainability model this migration was intended to create. ### What Stays the Same None of this is visible to the people eSignet ultimately serves, and that is by design. The eSignet user interface remains exactly as it was under the Java-based engine. End users authenticating through eSignet, whether via [OTP, biometrics, or password](/home/esignet-2.0.0/readme/features), will notice no difference in how the product looks, behaves, or responds. Nothing about the user experience has changed as a result of this migration. The same holds for [standards compliance](/home/esignet-2.0.0/readme/standards). eSignet's Go-based engine implements the full set of OpenID Connect, OAuth 2.0, and FAPI 2.0 requirements that the Java-based platform did. No feature, no compliance guarantee, and no integration contract has been dropped or diminished in the move. Relying parties integrating against eSignet's OIDC endpoints today will find the same standards-based surface they always have. In short: the engine underneath has changed meaningfully. What eSignet does, and what it guarantees to the people and systems that depend on it, has not. ### Why This Makes eSignet a Stronger Product Taken together, this migration strengthens eSignet along exactly the dimensions that matter most for infrastructure meant to serve at national scale: * **More durable, better resourced.** eSignet's core engine is now maintained by two engineering organizations instead of one, reducing the risk that comes with any single point of ownership over critical infrastructure. * **More efficient to run.** Better throughput on comparable infrastructure lowers the operational cost of running eSignet at scale, for MOSIP and for every adopter running it independently. * **No loss of trust or compatibility.** Every standard eSignet complied with before, it complies with now. Every integration built against it continues to work exactly as it did. * **Positioned to keep improving.** Because eSignet now develops in step with Thunder's own roadmap, it benefits on an ongoing basis from engineering investment happening outside its own team, rather than depending solely on its own resourcing. # Features Explore eSignet’s powerful features for secure access. ### Capabilities at a Glance | Area | What It Covers | | ------------------------- | ------------------------------------------------------------------------------------------------------------ | | **Authentication** | Password, OTP, Knowledge-Based Identification (KBI), biometrics (SBI 2.0), etc. - selected per relying party | | **Consent & Privacy** | A built-in Consent Registry, configurable expiry, and three consent modes: mandatory, re-consent, and bypass | | **Security & Compliance** | FAPI 2.0 Security Profile — Pushed Authorization Requests, DPoP, and issuer identity verification | | **Personalization** | Branded, context-aware UI and out-of-the-box multi-language support | ### Authentication: Choosing How a User Proves Their Identity A banking transaction and a library sign-in don't need the same bar for proof — so instead of fixing one login method for every user, eSignet lets each relying party decide which authentication factors apply, dynamically, based on the user's context, the sensitivity of the service, or the assurance level the transaction requires. **Password:** Traditional username-and-password login, for relying parties that prefer a familiar credential-based flow. **OTP (One-Time Password):** One-time codes sent via SMS or email for time-bound access, well suited to situations where biometrics is not available to the user. **Knowledge-Based Identification (KBI):** Authentication through answers to identity-based questions, aimed at low-connectivity or limited-device scenarios where OTP or biometric capture isn't practical. {% hint style="warning" icon="question" %} **FAQ Highlights for KBI:** * [How to configure for KBI with Sunbird RC?](/home/esignet-2.0.0/general/faq#how-to-configure-knowledge-based-identification-kbi-with-sunbirdrc) {% endhint %} **Biometric authentication:** Authentication via biometric devices compliant with the IEEE P3167 [SBI 2.0 standard](https://docs.esignet.io/home/esignet-2.0.0/readme/pages/Tk3eiHfyOsvmzvqNZGRg#id-1.-security-standards). Modalities are selected on demand: a service provider can enable facial recognition, fingerprint, or iris scan independently, based on device capability, assurance need, or user preference. {% hint style="info" icon="wallet" %} **Note:** Wallet-based authentication is not supported in eSignet v2.0.0. It will be added in an upcoming release to bring the Go version to feature parity with eSignet (Java). {% endhint %} ### Consent & Privacy: Keeping Data Sharing Transparent and Reversible Authentication only tells a relying party who a user is — what happens next, how their data is shared and for how long, is governed separately by eSignet's consent layer, so that consent is never a single yes/no gate a relying party can quietly bypass. * **Consent storage**: Every user consent is recorded in a built-in Consent Registry, giving both users and service providers an auditable record of what was agreed to and when. * **Consent expiry configuration**: Relying parties define how long a consent stays valid — per session, per time window, or indefinitely — rather than eSignet enforcing one fixed policy for everyone. * **Configuring claims**: eSignet supports every [standard claims](/home/esignet-2.0.0/develop/configuration#claims-what-personal-data-a-client-can-receive) defined by the OpenID Connect (OIDC) protocol, and custom claim configurations can be layered on top depending on a service's authentication requirements. * **Configurable consent behavior**: Consent handling itself can be tuned per flow or per service, in one of three modes: * **Mandatory consent:** Collect it regardless of any prior decision. * **Re-consent:** Prompt again automatically when claim scopes change or existing consent has expired, useful after a policy update. * **Bypass consent:** Skip the step entirely where it isn't warranted. ### Security & Compliance: Meeting the FAPI 2.0 Bar Identity transactions carry more risk than an average API call, which is why eSignet complies with the [FAPI (Financial-grade API) 2.0 Security Profile](https://docs.esignet.io/home/esignet-2.0.0/readme/pages/Tk3eiHfyOsvmzvqNZGRg#id-3.-supported-rfcs) — a set of standards built on OAuth 2.0 and OpenID Connect for high-assurance, interoperable, phishing-resistant flows, widely adopted in banking, government identity management, and digital public infrastructure, where confidentiality, integrity, and client assurance all have to be provable rather than assumed. Adopting FAPI 2.0 raises eSignet's baseline security posture against real-world risks in front-channel flows, token misuse, and server impersonation — protecting sensitive claims and tokens, narrowing the attack surface of its authorization flows, and improving interoperability with partner systems that already follow financial-grade security practices. eSignet implements three RFCs that together harden its authorization flows: * **Pushed Authorization Requests (PAR):** Moves authorization requests from the browser front-channel to a secure server-to-server POST request, so authorization parameters (redirect URIs, scopes, claims) can't be exposed or tampered with in a browser URL, and the authorization server processes exactly what the client intended. * **Demonstrating Proof-of-Possession (DPoP)-** Binds an access token to a client-held cryptographic key and requires a signed, per-request proof of possession, which makes a stolen token unusable by a third party and blocks replay of an intercepted one. * **Authorization Server Issuer Identification:** Enforces verifiable issuer metadata so a client can confirm it's talking to the intended authorization server, preventing environment mix-ups and impersonation, such as sandbox-versus-production confusion or a malicious endpoint posing as the real one. Together, these defend high-risk OAuth/OIDC flows against tampering, mix-up attacks, phishing, token theft and replay, and leakage through front-channel exposure. {% hint style="success" icon="openid" %} **Attacker model and mitigations with FAPI 2.0** FAPI 2.0 defends high-risk OAuth/OIDC flows against tampering, mix-up, phishing, token theft/replay, and leakage via front-channel exposure. To know more about this refer [here](https://openid.net/specs/fapi-2_0-attacker-model.html) {% endhint %} {% hint style="success" icon="openid" %} FAPI 2.0 For a deeper understanding of FAPI 2.0 and the mechanisms implemented in eSignet, see the [FAPI 2.0 Security Profile specification](https://openid.net/specs/fapi-security-profile-2_0-final.html). {% endhint %} ### Personalization: Adapting to Each Relying Party An identity layer only feels native to a service if it looks and reads like part of that service — so eSignet's UI and language support are both built to be configured per relying party rather than shipped as one fixed screen. **Customizable UI** * **Multiple login ID options**: let users choose from different login identifiers, such as email, phone number, or username, improving accessibility across different user segments. * **Theme and layout customization**: match a portal's branding, including colors, logos, fonts, and button styles. * **Context-aware UI behavior**: adjust the flow based on user type, assurance level, or the authentication factor chosen — for example, showing or hiding biometric prompts or OTP inputs dynamically rather than displaying every option at once. **Language support** eSignet ships with multilingual UI support out of the box — Arabic, English, Hindi, Kannada, and Tamil — and additional languages can be integrated to meet country- or region-specific requirements. {% hint style="warning" icon="question" %} **Open questions:** * [How to add a new language to eSignet?](/home/esignet-2.0.0/general/faq#how-to-add-a-new-language-in-esignet) * [How to remove a language from the eSignet default setup?](/home/esignet-2.0.0/general/faq#how-to-remove-a-language-from-the-esignet-default-setup) {% endhint %} # Principles Core principles that define eSignet. eSignet is designed around the architectural principles below. These principles are core to how the system's features are built, and they largely explain why specific software design patterns are used throughout eSignet rather than being an afterthought layered on top. ### Data Privacy eSignet prioritizes user privacy by minimizing data exposure and ensuring secure interactions: * **No storage of personal data, tracked by relying-party-specific tokens**: eSignet does not store any personally identifiable information (PII), sensitive data is processed transiently for authentication and is never retained. Instead of sharing a common user ID across services, eSignet issues a unique Partner Specific User Token (PSUT) for each user–relying party pair, which is also what prevents a user's activity from being tracked or correlated across services. See [How eSignet Builds Trust](/home/esignet-2.0.0/readme/what-is-esignet#how-esignet-builds-trust) for the full explanation. * **Protection of sensitive data**: any sensitive information that does pass through eSignet is never stored or logged in clear text. * **User-controlled consent**: users retain full control over what data is shared with relying parties, and that control is enforced rather than optional, see [User-Centric Design](#user-centric-design) below for how consent enforcement works. ### 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, not only in its authentication protocols, which lets it integrate with a wide range of identity systems and infrastructure components instead of being tied to a specific proprietary format. (The specific protocols its authentication flows are built on are covered under Enhancing Authentication Methods Through Secure Standards. * **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. * **An open-source foundation**: as an open-source product, eSignet provides full transparency and avoids proprietary lock-in, letting adopters customize, extend, and audit the solution to their own requirements, [refer here](/home/esignet-2.0.0/readme/what-is-esignet) for more on what this means in practice. ### Commodity Computing eSignet is optimized for cost-efficiency and scalability: * **Containerized backend**: all eSignet backend services run as Docker containers, which removes any dependency on specialized hardware or a specific cloud provider. * **Multi-platform support**: eSignet can be deployed on any general-purpose virtual machine that supports Docker, rather than requiring a particular platform. Together, these choices mean eSignet's infrastructure requirements don't lock an adopter into a specific cloud provider or hardware vendor, reinforcing the vendor independence described under No Vendor Lock-in, above. ### Secure By Design Security is a core principle of eSignet, ensuring end-to-end protection rather than being addressed only at the perimeter: * **Trusted integrations**: eSignet only integrates with verified and trusted applications, rather than accepting connections from any client that presents itself. * **Fraud prevention**: authentication is tied to specific transactions rather than a generic session, which reduces the risk of unauthorized or replayed access this complements the authorization-code-flow and protocol-level protections described under Enhancing Authentication Methods Through Secure Standards, below. * **Centralized key management**: a robust key management system underpins eSignet's cryptographic operations, rather than leaving key handling to individual components. * **API security**: all state-changing APIs, including data-modification and client-management endpoints, are protected with OAuth 2.0, enforcing authenticated and authorized access to every operation that changes data. ### Enhancing Authentication Methods Through Secure Standards * **Standards-based architecture**: eSignet is built on [OpenID Connect flows layered on the OAuth 2.0 framework](/home/esignet-2.0.0/readme/standards), which allows it to integrate seamlessly with the wide ecosystem of libraries and tools that already support these widely adopted standards, instead of requiring a proprietary integration approach. * **Scalable for country-wide implementation**: eSignet is designed to deliver secure authentication and KYC verification at national scale, with the reliability and performance that scale demands. * **Secure biometric integration**: eSignet incorporates the [Secure Biometric Interface (SBI)](https://docs.esignet.io/home/esignet-2.0.0/readme/pages/Tk3eiHfyOsvmzvqNZGRg#id-1.-security) to enable secure, tamper-resistant biometric data collection for identity verification. * **Advanced security features**: eSignet supports secure OpenID Connect options such as the authorization code flow, and includes enhanced fraud-prevention measures on top of the base protocol. ### User-Centric Design * **A single identity credential**: eSignet lets users access integrated public- and private-sector services using one unified digital identity, rather than juggling separate credentials per service. * **Consent enforcement**: User consent flow is enabled by default, and enforced wherever the use case calls for it; deployments where the country or governing policy has determined consent isn't required can turn it off explicitly. * **Support for diverse authentication methods**: eSignet accommodates a range of verification approaches to meet individual user preferences, and this approach improves both general usability and liveness detection during verification. * **Credential security**: User authentication is handled exclusively on the eSignet platform, which prevents unauthorized data sharing with third parties unless the user has explicitly consented to it. ### Accelerated Digital Transformation * **Fast and secure digital verification**: eSignet facilitates rapid user verification across multiple digital services, rather than requiring a lengthy manual check per service. * **Assurance parity with registration**: eSignet maintains consistent verification quality by using the same methods employed during a user's initial onboarding - OTP, biometrics, or cryptographic keys, so authentication doesn't fall below the assurance bar set at registration. * **Government enablement for e-KYC services**: eSignet empowers governments to offer digital identity verification and e-KYC as a service, fostering broader access to financial and digital services for their citizens. * **Effortless integration for service providers**: eSignet adheres to open standards, which significantly reduces the time it takes to deploy identity services compared to building or integrating a proprietary system. * **Bridging the digital divide**: eSignet offers flexible verification modes to cater to users across the digital access spectrum, see [Inclusive by Design](/home/esignet-2.0.0/readme/what-is-esignet#inclusive-by-design) for how this works in practice. # License Empowering users through transparent licensing. The documentation is licensed under a Creative Commons Attribution 4.0 International License.

🔗 **eSignet's Core Repositories:** All eSignet's [core](https://github.com/mosip) repositories are licensed under the terms of [Mozilla Public License 2.0](https://github.com/mosip/commons/blob/master/LICENSE). All eSignet code is owned and maintained by International Institute of Information Technology, Bangalore, on behalf of eSignet. ⚠️ **Trademark Notice:** All trademarks are the property of their respective holders. Other products and company names mentioned [here](https://github.com/mosip) may be trademarks and/or service marks of their respective owners. # Standards Building on the most trusted security protocols. eSignet is built on industry-leading security standards, ensuring robust privacy and data protection. It implements [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0-final.html) and [OAuth 2.0](https://oauth.net/2/), leveraging the most secure and trusted authentication flows to safeguard user identities. #### 1. Security Standards * **Biometric Integration via SBI**\ eSignet integrates with the [**Secure Biometric Interface (SBI)**](https://standards.ieee.org/ieee/3167/10925/) 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 * [React SBI Library](https://github.com/mosip/mosip-sdk/tree/master/react-secure-biometric-interface-integrator) * [JS SBI Library](https://github.com/mosip/mosip-sdk/tree/master/secure-biometric-interface-integrator) * [Supported Devices](https://docs.mosip.io/1.2.0/id-lifecycle-management/supporting-components/biometrics/biometric-devices) - 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. * **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 [PKCE ](https://www.rfc-editor.org/rfc/rfc7636)(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. {% hint style="info" %} **Note:** eSignet currently supports the S256 challenge method in its PKCE implementation. {% endhint %} #### 2. Standards Promoting Interoperability * **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. | Name | URL Paths | | -------------------- | --------------------------------------- | | OpenID Configuration | /.well-known/openid-configuration | | Jwks Json | /.well-known/jwks.json | | Authorization Server | /.well-known/oauth-authorization-server | #### 3. Supported RFCs eSignet provides a limited implementation of the OpenID protocol, supporting the following RFCs and standards: **a. OAuth 2.0 Standards:** * [OAuth 2.0 RFC 6749](https://www.rfc-editor.org/rfc/rfc6749) - Authorization code flow support * [OAuth 2.0 RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) - Authorization Framework: Bearer Token Usage * [OAuth 2.0 RFC 7523](https://www.rfc-editor.org/rfc/rfc7523) - JWT profile for client authentication * [OAuth 2.0 RFC 7636 ](https://datatracker.ietf.org/doc/html/rfc7636)- PKCE security extension * [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0-final.html) * [Open ID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html) **b. Token and Discovery Standards:** * [RFC 7515](https://www.rfc-editor.org/rfc/rfc7515.html) - JSON Web Signature * [RFC 7516](https://www.rfc-editor.org/rfc/rfc7516.html) - Userinfo as JWE * [RFC 7517](https://datatracker.ietf.org/doc/html/rfc7517) - JSON Web Keys * [RFC-9068](https://www.rfc-editor.org/rfc/rfc9068.html) - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens * [RFC 7519](https://www.rfc-editor.org/rfc/rfc7519) - ID token and access token as JWT * [OAuth 2.0 RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414) - Authorization Server Metadata * [RFC 5785 ](https://www.rfc-editor.org/rfc/rfc5785)- Followed for both openid and oauth well-knowns **c. Identity Proofing and security:** * [Identity Assurance 1.0](https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html) * [IEEE SA P3167 SBI 2.0](https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html) **d. FAPI 2.0 Security Profile:** eSignet adopts key OpenID [**FAPI 2.0 security profile**](https://openid.net/specs/fapi-security-profile-2_0-final.html#section-5.3) 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. * [RFC-9126](https://datatracker.ietf.org/doc/html/rfc9126) - Pushed Authorization Request (PAR) * [RFC-9449](https://datatracker.ietf.org/doc/html/rfc9449) - Demonstrate Proof of Possession (Dpop) * [RFC-9207](https://www.rfc-editor.org/rfc/rfc9207) - Authorization Server issuer Metadata #### 4. 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: | Standards | Flow | Client Authentication | | ---------------------- | ---------------------------- | --------------------- | | OAuth 2.0 | Authorization Code with PKCE | private-key-jwt | | OIDC | Authorization Code with PKCE | private-key-jwt | | Identity Assurance 1.0 | Authorization Code with PKCE | private-key-jwt | {% hint style="info" %} **Note:** eSignet supports confidential clients only, adhering to the principle of [security by design](/home/esignet-2.0.0/readme/principles#secure-by-design). {% endhint %} #### 5. eSignet as OAuth 2.0 server eSignet’s [OAuth 2.0](https://oauth.net/2/) 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. *** # Technology Explore the tools, components, and architecture powering eSignet. eSignet's Go implementation is built on a small, deliberately chosen set of open-source tools rather than a sprawling dependency tree: a statically typed, compiled language for its backend services, a relational database and an in-memory store for persistence, and a React-based interface for the screens a user actually sees. Each choice below is meant to keep the platform straightforward to run, secure to operate, and simple to audit, whether the goal is deploying it, extending it, or clearing it for a compliance review. For eSignet's internal building blocks and how they fit together, see [**Developer Guide**](/home/esignet-2.0.0/develop)**.** ### Language & Runtime eSignet's Go implementation is written in Go itself, chosen for its built-in concurrency model, fast compilation, and suitability for network and infrastructure services. | Tool/Technology | Version | Description | License | | --------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | [Go](https://go.dev/) | 1.26 | Go is a statically typed, compiled programming language designed by Google for simplicity, built-in concurrency, and fast compilation, commonly used for building networked and infrastructure services. | [BSD-3-Clause](https://github.com/golang/go/blob/master/LICENSE) | ### API & Service Layer Rather than building HTTP handling and OIDC/OAuth2 flow logic from scratch, eSignet composes a small set of focused pieces: Go's own standard library for HTTP, an embedded authorization engine for the OIDC/OAuth2 flow itself, structured logging for observability, and a dedicated component for key management and cryptographic operations. | Tool/Technology | Version | Description | License | | ----------------------------------------------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | [net/http](https://pkg.go.dev/net/http) | Go 1.26 stdlib | Go's standard library package for building HTTP clients and servers; eSignet's HTTP entrypoint and routing are built directly on it, with no third-party web framework. | [BSD-3-Clause](https://github.com/golang/go/blob/master/LICENSE) | | [ThunderID engine](https://github.com/thunder-id/thunderid) | pinned via `go.mod` `replace` directive | An OIDC/OAuth2 authorization engine providing flow orchestration and a pluggable authenticator/executor model; eSignet embeds it as the core of its authorization-code flow. | [Mozilla Public License 2.0](https://github.com/thunder-id/thunderid/blob/main/LICENSE) | | [log/slog](https://pkg.go.dev/log/slog) | Go 1.26 stdlib | Go's standard library package for structured, leveled logging; eSignet emits structured JSON logs through it. | [BSD-3-Clause](https://github.com/golang/go/blob/master/LICENSE) | | Keymanager (embedded) | part of `esignet-service` | Provides secure storage, provisioning, and management of cryptographic keys, including encryption/decryption and digital signature/verification operations. | [Mozilla Public License 2.0](https://claude.ai/LICENSE) | ### Data & Storage eSignet separates data by durability need across two stores: a relational database for anything that needs to persist, and an in-memory store for short-lived flow and session state. | Tool/Technology | Version | Description | License | | --------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | [Postgres](https://www.postgresql.org/) | 15 | A free and open-source relational database management system (RDBMS) emphasizing extensibility and SQL compliance. eSignet uses it for OIDC client management and for the keymanager's key/certificate store. | [PostgreSQL License](https://opensource.org/license/postgresql/) | | [Redis](https://redis.io/) | 6.0 and above (requires `KEEPTTL` support) | An open-source, in-memory data store used as a database, cache, streaming engine, and message broker. eSignet uses it to hold runtime flow, session, and pushed-authorization-request state. | [BSD License](https://redis.io/docs/about/license/) | ### Frontend The login and consent screens a user actually interacts with are a separate React application that the OIDC/OAuth2 provider redirects to during an authorization request. | Tool/Technology | Version | Description | License | | ------------------------------ | ------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | [React JS](https://react.dev/) | 19 | Lets you build user interfaces out of individual pieces called components; it powers eSignet's login/consent UI. | [MIT License](https://github.com/facebook/react/blob/main/LICENSE) | ### Build, Packaging & Deployment eSignet is packaged as Docker containers and deployed via Helm charts, with dependency management and CI/CD handled by tooling native to each side of the stack — Go modules for the backend, npm for the UI. | Tool/Technology | Version | Description | License | | --------------------------------------------------------- | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | [Go modules](https://go.dev/ref/mod) | Go 1.26 | Go's built-in dependency-management system, recording a project's dependencies and their versions in `go.mod`/`go.sum`. | [BSD-3-Clause](https://github.com/golang/go/blob/master/LICENSE) | | [Docker](https://www.docker.com/) | 20.4 and above | A set of platform-as-a-service products that use OS-level virtualization to deliver software in packages called containers. | [Apache License 2.0](https://github.com/moby/moby/blob/master/LICENSE) | | [npm](https://www.npmjs.com/) | Node.js 18 and above, npm 9 and above | The package manager for the Node.js JavaScript platform; it installs and manages the UI's dependencies. | [Artistic License 2.0](https://docs.npmjs.com/policies/npm-license) | | [Helm Chart (MOSIP)](https://github.com/mosip/mosip-helm) | depends on eSignet version | Helps manage Kubernetes applications — defining, installing, and upgrading them via versioned, shareable charts. | [Apache License 2.0](https://github.com/mosip/mosip-helm/blob/master/LICENSE) | | [kattu (MOSIP)](https://github.com/mosip/kattu) | reusable CI/CD workflow | Holds the reusable GitHub Actions workflows used to build, test, and gate MOSIP projects' pull requests and releases. | [Apache License 2.0](https://github.com/mosip/kattu/blob/master/LICENSE) | ### Testing eSignet's automated tests span two levels: Go's own unit-testing tooling for the backend logic itself, and Postman/Newman-driven tests that exercise its APIs end to end. | Tool/Technology | Version | Description | License | | -------------------------------------------------------------------------------------------------------------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | [Go testing](https://pkg.go.dev/testing) / [testify](https://github.com/stretchr/testify) | Go 1.26 stdlib / v1.11.1 | Go's built-in `testing` package, together with the testify toolkit (assertions and suite-based test structure), used to write and run unit tests via `go test`. | [BSD-3-Clause](https://github.com/golang/go/blob/master/LICENSE) / [MIT License](https://github.com/stretchr/testify/blob/master/LICENSE) | | [Newman](https://learning.postman.com/docs/collections/using-newman-cli/command-line-integration-with-newman/) | — | A command-line tool that runs Postman collections and automates API tests; used for CI/CD-integrated API testing. | [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) | # Quickstart To dive straight into the hands-on experience and see eSignet's features and capabilities for yourself, this is the place to start running a real instance on your own machine and walking through an actual login, rather than just reading about one. This section is for anyone who wants their hands on eSignet before committing to it: someone evaluating whether it fits their use case, a developer about to start an integration, or a reviewer who just wants proof that the OIDC flow actually works end to end. It isn't a production deployment guide that comes later, once you already know eSignet does what you need it to. Everything here runs on your own machine, using mock stand-ins for the pieces you wouldn't otherwise have on hand, a mock identity system in place of a real national ID system, and a mock relying party in place of a live production service. Nothing you do here depends on real credentials, a live government ID system, or infrastructure beyond what's already on your laptop. By the end, you'll have watched a real login happen, from clicking "sign in" through to a completed, authenticated session, rather than just read about one. ### Don't Want to Set Anything Up? eSignet is already running in MOSIP's collaboration environment (a shared sandbox) you can try without installing or running anything locally. Try eSignet in the [MOSIP Collab](https://collab.mosip.net/) Environment. This is the fastest way to get a feel for eSignet if you just want to see it in action. The rest of this section is for anyone who wants it running on their own machine instead, useful if you're planning to integrate with it, poke around its configuration, or just want an environment that's entirely yours. Continue reading the pages below to complete the local set up or try it yourself in MOSIP Collab.

Cover image	Cover image
	eSignet Local Setup.png	Local Setup
	Try It Yourself.png	Try It Out

# Local Setup Getting eSignet running on your own machine is usually the first real interaction you have with the codebase, before writing any integration, most people just want to watch the OIDC flow work end to end. Docker Compose is how eSignet makes that possible without a lengthy manual setup. ### Why Docker Compose eSignet's OIDC flow depends on more than the eSignet service itself, it needs a database and a source of identity data to authenticate against. Rather than asking you to install and configure each of these individually, matching versions and wiring configuration by hand, Docker Compose brings up the whole stack with a single command and tears it down just as easily. It also mirrors the way these services actually run in production - as separate containers behind well-defined ports, so what you learn locally carries over directly to how the pieces fit together in a real deployment. ### What's Included A real government or enterprise identity system usually isn't something you have, or should have access to in a local development environment. So eSignet ships with a [Mock Identity System](/home/esignet-2.0.0/local-deployment/local-setup/mock-id-system): a stand-in identity backend that eSignet's [Authn Provider](/home/esignet-2.0.0/develop/integration/authenticator) connects to, supporting the same authentication factors a real system would (PIN, OTP, and biometrics). This lets the full OIDC flow run end to end locally without any external dependency. ### Two Ways to Start It There are two Docker Compose files, and which one you need depends on what you're doing: | Compose file | Services it brings up | Use it when | | ----------------------------------------------------------- | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | **Full demo** -`docker-compose.yaml` | Database, Mock Identity System, the eSignet OIDC/OAuth2 service, and the OIDC login UI. | You want to evaluate or demo eSignet end to end without building anything from source. | | **Dev dependencies only** - `dependent-docker-compose.yaml` | Database and Mock Identity System only | You're running the eSignet service itself from source and don't want a containerized copy running alongside it. | ### Get Started {% hint style="info" icon="github" %} **Docker Compose setup**: GitHub — [docker-compose](https://github.com/mosip/esignet/tree/master/docker-compose) {% endhint %} {% hint style="info" icon="github" %} **Step-by-step setup guide**: [Local setup README](https://github.com/mosip/esignet/blob/master/docker-compose/README.md) {% endhint %} ### In This Section

Cover image	Cover image
	Mock Identity System.png	Mock Identity System
	Mock Relying Party.png	Mock Relying Party

# Mock Identity System ### What It Is The Mock Identity System is a mock implementation of an identity system, provided so developers can use it for local development and testing of eSignet. It exposes endpoints to: * Create an individual * Get an individual's data * Authenticate an individual * Send an OTP * Share KYC data about the individual, post-authentication It supports the same authentication factors a real identity system would: PIN-based authentication, OTP authentication, and biometric authentication. ### Why It's Used eSignet is designed to connect to an identity system via an [Authn Provider](/home/esignet-2.0.0/develop/integration/authenticator) built specifically for that purpose, but a real government or enterprise identity system usually isn't something a developer has, or should have, access to in a local environment. The Mock Identity System stands in for that real system, so eSignet's full authentication flow can run end to end on a local machine, without any external dependency or access to production identity data. It's brought up automatically as part of both Docker Compose files described under [Local Setup](/home/esignet-2.0.0/local-deployment/local-setup). ### Repository and Setup {% hint style="info" icon="github" %} **Codebase**: [esignet-mock-services](https://github.com/mosip/esignet-mock-services/tree/master) {% endhint %} {% hint style="info" icon="github" %} **Setup guide (README)**: [mock-identity-system README ](https://github.com/mosip/esignet-mock-services/blob/master/README.md) {% endhint %} # Mock Relying Party ## Mock Relying Party ### What It Is The Mock Relying Party is a sample OIDC relying party (RP) portal, a stand-in for a real service provider's application, built with React JS. It's made up of two components: * [**mock-relying-party-ui**](https://github.com/mosip/esignet-mock-services/tree/master/mock-relying-party-ui): the front end, consisting of a login page and a user profile page. * [**mock-relying-party-service**](https://github.com/mosip/esignet-mock-services/tree/master/mock-relying-party-service): a backend service that hosts a single endpoint to fetch user info The portal uses the authorization code flow with private key JWT client authentication to fetch the logged-in user's profile — the same flow a real relying party would use in production, not a simplified stand-in for it. ### Why It's Used Docker Compose and the Postman collection can each exercise pieces of the OIDC flow, but neither shows what it actually looks like from a relying party's side of the exchange — including the private-key-JWT client authentication step, which is one of the more security-sensitive parts of integrating with eSignet. The Mock Relying Party gives you a real, clickable "Log in with eSignet" experience end to end, so you can see exactly what a relying party sends, receives, and does with each token along the way. ### Repository and Setup {% hint style="info" icon="github" %} **Codebase**: [esignet-mock-services](https://github.com/mosip/esignet-mock-services/tree/master) {% endhint %} {% hint style="info" icon="github" %} **Setup guide (README)**: [mock-identity-system README ](https://github.com/mosip/esignet-mock-services/blob/master/README.md) {% endhint %} # Try It Out Experience eSignet in our Collab sandbox – try, integrate, and explore. The latest stable version of the eSignet solution is deployed in our [MOSIP Collab](https://collab.mosip.net/) environment, featuring the most up-to-date released version. This sandbox is designed for: 1. **ID Solution Providers -** Representatives of ID solutions who are seeking a convenient method to enable authentication. 2. **Developers & Integrators-** who are interested in gaining a better understanding of how eSignet works or those who wish to demonstrate eSignet. 3. **Relying Parties -** Relying parties can efficiently utilize this platform to seamlessly integrate and ascertain its compatibility with the protocols employed by eSignet. Start exploring **eSignet** today in our [**MOSIP Collab**](https://collab.mosip.net/)!

Cover image	Cover image
	Using Mock Data.png	Using Mock Data
	Register Yourself.png	Register Yourself
Principles	End User Guides.png	End User Guides

# Using Mock Data #### Exploring eSignet with MOSIP Deployment in Collab Environment **Personas - MOSIP Foundational ID** You can use one of following personas and UINs on the respective cards

Name	UIN	Gender	DOB	Address
Maria Powell	3519657608	Female	30/10/1991	26/C, IIIT-B, ABC Region, ABC City, ABC Zone, 10106
James Rodrigious	2760459465	Male	29/04/1992	26/C, IIIT-B, ABC Region, ABC City, ABC Zone, 10106
George Cooper	2018502367	Male	29/04/1985	26/C, IIIT-B, ABC Region, ABC City, ABC Zone, 10106
Jane Thompson	3473541796	Female	29/04/1985	26/C, IIIT-B, ABC Region, ABC City, ABC Zone, 10106

![](https://content.gitbook.com/content/GLWCTe02ubJM6M7TcHlg/blobs/8UEFnP0Wb7rjLgcWLwxq/maria-powell.png) ![](https://content.gitbook.com/content/GLWCTe02ubJM6M7TcHlg/blobs/Os9tV8nZar2ji0U8Qygn/james-rodrigious.png) ![](https://content.gitbook.com/content/GLWCTe02ubJM6M7TcHlg/blobs/NvA4CWSKcK31jC4LomZa/george-cooper.png) ![](https://content.gitbook.com/content/GLWCTe02ubJM6M7TcHlg/blobs/MV6HZSmpOaVXoGqrR7ni/jane-thompson.png) Individual images are included to facilitate **selfie authentication** for the Inji application. {% hint style="info" %} **Note:** The data used for these Virtual IDs (VIDs) is entirely fictitious, and the images displayed are AI-generated from an [external website](https://this-person-does-not-exist.com/en). {% endhint %} **Personas - MOCK IDs and UINs** Name: Dr. William Anderson - * UIN: 2345890124 * Age: 56 * DOB: 14/05/1968 * Email: * Phone Number: [+91-9090909088](tel:+919090909088) * Address - 26/C, IIIT-B, ABC Province, ABC Region ABC Zone, -10106, ABC Name: Sara Al-Mansouri
* UIN: 8294297335 * Age: 27 * DOB: 11/01/1998 * Email: * Phone Number: [+91-9090909085](tel:+919090909085) * Address - 26/C, IIIT-B, ABC Province, ABC Region ABC Zone, -10103, ABC Name: Michael Chen
1. UIN: 6819805520 2. Age: 37 3. DOB: 22/08/1987 4. Email: 5. Phone Number: [+91-9090909086](tel:+919090909086) 6. Address - 26/C, IIIT-B, ABC Province, ABC Region ABC Zone, -10104, ABC Name: Jasmine Robinson * UIN: 3945691120 * Age: 19 * DOB: 03/04/2005 * Email: * Phone Number: [+91-9090909087](tel:+919090909087) * Address - 26/C, IIIT-B, ABC Province, ABC Region ABC Zone, -10105, ABC

	Cover image
	cred-william-anderson.png
	cred-sara-al-mansouri.png
	cred-michel-chen.png
	cred-jasmine-robinson.png

#### Steps to use eSignet Access the Collab Health Portal [**here**](https://healthservices-esignet-mock.collab.mosip.net/). 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. #### OTP Authentication To simplify exploring it with a 'Collab MOSIP Identity Deployment' eSignet supports OTP authentication. * You can use any of the provided [personas](#personas) above for testing. {% hint style="info" %} **Note: OTP Delivery Update for eSignet Login**\ Previously, the eSignet login flow in the MOSIP Collab (Sandbox) environment used a static OTP (`111111`) for easy self-experience by the community. As per the latest MOSIP platform deployment, OTP delivery now works as follows: * If you registered with a **valid, accessible email address**, the **OTP will be sent to that email**. Please ensure you use a valid, accessible email ID during self-registration to receive it directly. * If you did not add a valid email during registration, **you can still get an OTP!** Go to [smtp.collab.mosip.net](http://smtp.collab.mosip.net) **(public mailbox) to get the OTP.** (**Important:** You must refresh/reload the public mailbox ([smtp.collab.mosip.net](http://smtp.collab.mosip.net)) to clear any previous OTPs and then click Get OTP and use the newly received one to complete login. {% endhint %} For a step-by-step guide on logging in with OTP using eSignet, refer to [Login with OTP](/home/esignet-2.0.0/local-deployment/try-it-out/end-user-guide/health-portal/login-with-otp). # Register Yourself * Now you can self generate your own UIN Credential using the [Collab environment](https://collab.mosip.net/). * Click on the **Get UIN** button located at the top-right corner of the page. This will open the [Self Registration Form](https://self-register.collab.mosip.net/), Alternatively, you can simply click on this [link](https://self-register.collab.mosip.net/) 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](https://docs.mosip.io/1.2.0/general/collab-getting-started-guide/generating-demo-credentials). 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 [**Health Services** ](https://healthservices-mosipid.collab.mosip.net/)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 [**health portal**](https://healthservices-mosipid.collab.mosip.net/) and try authenticating using the OTP. {% hint style="info" %} **Note: OTP Delivery Update for eSignet Login**\ Previously, the eSignet login flow in the MOSIP Collab (Sandbox) environment used a static OTP (`111111`) for easy self-experience by the community. As per the latest MOSIP platform deployment, OTP delivery now works as follows: * If you registered with a **valid, accessible email address**, the **OTP will be sent to that email**. Please ensure you use a valid, accessible email ID during self-registration to receive it directly. * If you did not add a valid email during registration, **you can still get an OTP!** Go to [smtp.collab.mosip.net](http://smtp.collab.mosip.net) **(public mailbox) to get the OTP.** (**Important:** You must refresh/reload the public mailbox ([smtp.collab.mosip.net](http://smtp.collab.mosip.net)) to clear any previous OTPs and then click Get OTP and use the newly received one to complete login. {% endhint %} Please refer the end user guide [here](/home/esignet-2.0.0/local-deployment/try-it-out/end-user-guide/health-portal/login-with-otp) to know the step by step process. #### 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 [here](https://drive.google.com/drive/folders/14q7E5pZtfj0eimF3JGzlVfU4eV-MRPCQ). * Unzip the downloaded file to extract its content. * Locate the `run_auth.bat` file within the extracted folder. * Double-click on the `run_auth.bat` file to start the authentication MDS. Experience the process of logging in using biometrics, by following the instructions provided [here](/home/esignet-2.0.0/local-deployment/try-it-out/end-user-guide/health-portal/login-with-biometrics). {% hint style="info" %} **Note**: Biometric-based login with Mock MDS is currently unavailable in the Collab environment. Stay tuned to the MOSIP [Community](https://community.mosip.io/) for updates! {% endhint %} ### Additional Video Resource * Watch this informative video [here](https://www.youtube.com/watch?v=ZfUPRv71s_0,) to gain insights into eSignet. * Explore the [eSignet Online Authentication Demo](https://www.youtube.com/watch?v=uNKlmw9KRFg) video for a practical demonstration of the authentication process. * Click [here](https://docs.esignet.io/) for detailed information about eSignet. {% hint style="info" %} **Note:** 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. {% endhint %} ### 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 [Community](https://community.mosip.io/). * 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. # End User Guides Fast, secure authentication for residents made easy. The guides in this section walk through what logging in with eSignet actually looks like from an end user's point of view — step by step, through a real relying-party application, rather than as an abstract flow diagram. Each guide sets the same underlying eSignet login and consent experience in a different real-world context, so you can see how the authentication factors and consent flow described under [Features](/home/esignet-2.0.0/readme/features) come together in practice, whichever kind of service is asking a resident to prove who they are. > **Before you start**: these guides assume some familiarity with how eSignet handles identity claims — see [Claims Configuration](/home/esignet-2.0.0/develop/configuration#claims-what-personal-data-a-client-can-receive) under Developer Guide if you haven't already. Screenshots and specific steps shown in each guide are for demonstration purposes only, and may differ from what you see in your own environment. ### Guides in This Section

Cover image	Cover image
	Health Portal.png	Health Portal
	Telecom Portal.png	Telecom Portal
Principles	Patient Registration Portal.png	Patient Registration Portal

# Health Portal Explore eSignet Authentication: Your Interactive Health Portal Experience. ### **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: * [**OTP authentication**](/home/esignet-2.0.0/local-deployment/try-it-out/end-user-guide/health-portal/login-with-otp) * [**Biometric authentication**](/home/esignet-2.0.0/local-deployment/try-it-out/end-user-guide/health-portal/login-with-biometrics) [Real MOSIP ID or mock ID](/home/esignet-2.0.0/local-deployment/try-it-out/using-mock-data) — both work. In just a few clicks, you get a secure, smooth, and personalized login journey. Use this demo portal as your **hands-on playground** to understand eSignet’s multi-modal capabilities and experience how easily it fits into service portals across sectors — health, education, social welfare, or any platform that needs trusted resident authentication. # Login with Biometrics 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. ![](https://content.gitbook.com/content/GLWCTe02ubJM6M7TcHlg/blobs/F0XRAydbaS9Sm0FxVIuQ/new4-esignetLogin-biometric-loaded.png) The resident clicks on the ***Scan and Verify*** button. 5\. The resident is then navigated to the Consent page. On this page, the **Essential** and **Voluntary** claims are displayed. ![](https://content.gitbook.com/content/GLWCTe02ubJM6M7TcHlg/blobs/fRG9wh0JWrUZHk09jpDs/new6-esignetconsent.png) {% hint style="info" %} The consent screen is presented solely to the resident if consent has not previously been obtained. Additionally, a timer is incorporated into the consent screen, allowing the resident to respond within the designated time frame. If the allotted time elapses, residents will be redirected to the relying party user interface. {% endhint %} 6\. 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. In eSignet, a "**master toggle button**" has been added to allow residents to select all the options at once if desired. ![](https://content.gitbook.com/content/GLWCTe02ubJM6M7TcHlg/blobs/886kv6RCpyaMyVPyTCSt/new7-esignetConsent-claims.png) 7\. The resident clicks on the ***Allow*** button. The system navigates the resident to the User Profile page and the page displays their details based on the consent provided. ![Profile page](https://content.gitbook.com/content/GLWCTe02ubJM6M7TcHlg/blobs/U4Kc2v6GWMfLV7Rt2Egn/new8-healthservices-user-profile.png) # Login with Password {% hint style="success" %} **Prerequisites:** The resident is registered with a username and password using eSignet's Signup portal. In the below demo application, we are using the resident's phone number as a username. {% endhint %} 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. {% hint style="info" %} **Note:**\ If the `acr_values` the query parameter is presented with only one `acr` in the authorized URL, then the login options page is skipped, and the resident is directly taken to the login page. {% endhint %} 2\. The resident needs to enter a registered username in the **Enter 8–9-digit mobile number** and password in the **Enter password** text field and check the box 'I'm not a robot'. The password-based authentication is secured with a captcha. ![](https://content.gitbook.com/content/GLWCTe02ubJM6M7TcHlg/blobs/RRvaQDU7jT8yZY3kW9Hu/login-with-pwd-form.png) 4\. Next, the resident clicks the **Continue** button. {% hint style="info" %} Note: * The login with Password form also has a link to **Sign Up With Unified Login** to navigate to the Signup portal, if the resident is still not registered. * **Forgot password** link is also available for resident to navigate to the signup portal to reset the password. * Resident can resume back login after successful registration as well as after successful reset of password. {% endhint %} 5\. The resident is then navigated to the Consent page. On this page, the **Essential** and **Voluntary** claims are displayed. ![](https://content.gitbook.com/content/GLWCTe02ubJM6M7TcHlg/blobs/VtFFmtY6khIHGJRgLvnN/consent-page.png) {% hint style="info" %} The consent screen is presented solely to the resident if consent has not previously been obtained. Additionally, a timer is incorporated into the Consent screen, allowing the resident to respond within the designated time frame. If the allotted time elapses, residents will be redirected to the relying party user interface. {% endhint %} 6\. 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. ![](https://content.gitbook.com/content/GLWCTe02ubJM6M7TcHlg/blobs/AyUcHraAq9Rznognlnuz/healthservices-user-profile.png) # Login with OTP {% hint style="success" %} **Prerequisites:**\ The resident is issued with a unique virtual ID for a country's foundation ID. In the below demo application, which is a health portal, the resident is registered with MOSIP and has a valid UIN or VID. {% endhint %} 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'. {% hint style="info" %} **Note:** The OTP-based authentication is now secured with a captcha. {% endhint %}

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). {% hint style="info" %} **Note: OTP Delivery Update for eSignet Login**\ Previously, the eSignet login flow in the MOSIP Collab (Sandbox) environment used a static OTP (`111111`) for easy self-experience by the community. As per the latest MOSIP platform deployment, OTP delivery now works as follows: * If you registered with a **valid, accessible email address**, the **OTP will be sent to that email**. Please ensure you use a valid, accessible email ID during self-registration to receive it directly. * If you did not add a valid email during registration, **you can still get an OTP!** Go to [smtp.collab.mosip.net](http://smtp.collab.mosip.net) **(public mailbox) to get the OTP.** (**Important:** You must refresh/reload the public mailbox ([smtp.collab.mosip.net](http://smtp.collab.mosip.net)) to clear any previous OTPs and then click Get OTP and use the newly received one to complete login. {% endhint %} 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.

{% hint style="info" %} The consent screen is presented solely to the resident if consent has not previously been obtained. Additionally, a timer is incorporated into the Consent screen, allowing the resident to respond within the designated time frame. If the allotted time elapses, residents will be redirected to the relying party user interface. {% endhint %} 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.

Profile page

# Knowledge Based Identification 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) 3. Preferences or history (e.g., favorite colour, first pet's name) eSignet has expanded its authentication options to include 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. {% hint style="info" %} Note: 1. The authentication factor can be referred to as either Knowledge Based Authentication (KBA) or Knowledge Based Identification (KBI). However, from the eSignet’s perspective, we will specifically refer to the authentication method as Knowledge Based Identification (KBI). 2. Given the relatively low level of assurance provided by Knowledge Based Identification (KBI), we recommend that Knowledge Based Authentication (KBA) / Knowledge Based Identification (KBI) should be used for the issuance of Verifiable Credentials (VC) or certificates rather than serving as a primary method of authentication. {% endhint %} The below mentioned scenario describes a user attempting to download a VC (Verifiable Credential) from the list of VC issuers through their mobile wallet (for example., Inji Wallet). The user is verified using Knowledge Based Identification (KBI) through eSignet. ### Prerequisite: 1. The Resident has installed a mobile wallet (for example., Inji app) on their mobile device 2. The Resident has received the policy number from their insurance provider, which would be required for KBI ### Steps 1. The resident accesses their digital wallet (e.g., Inji Wallet) and taps on the plus '+' button. 2. Resident selects their preferred issuer from the available list. 3. Resident provides their **Policy Number**, **Full Name**, and **Date of Birth** as credentials for KBI login. 4. The resident clicks on the Login button. 5. Upon successful completion, the user downloads their Insurance Card into their digital wallet (Inji Wallet).

# Telecom Portal #### Experience eSignet in Action Through the eSIM Allocation Demo Portal Experience eSignet in action with a demo eSIM allocation on the **Fyntel Telecom** portal, illustrating secure National ID-based authentication before eSIM issuance. Hosted on the [**MOSIP Collab Sandbox**](https://collab.mosip.net/), this portal acts as a relying party application and allows you to experience how eSignet integrates seamlessly into service workflows that require trusted identity authentication. Using a **National ID (UIN)**, you can authenticate and login to proceed with eSIM allocation using the following authentication methods: * [**OTP-based authentication**](broken://pages/9CmUG8MeLXU792Xv339m) * [**INJI Wallet–based authentication**](broken://pages/JQF2VdqcALtMxHx0W9AT) The portal supports **real MOSIP IDs** , enabling easy exploration without prerequisites. In just a few steps, you can experience a secure and smooth authentication flow that culminates in the allocation of an eSIM linked to the authenticated National ID. This demo portal serves as a hands-on environment to understand how eSignet can be used for **identity-verified service delivery**, and sets the context for the detailed end-user guide that follows. ### Prerequisites The resident is registered in the national identity system and holds a valid [MOSIP ID (UIN) or Virtual ID (VID).](https://docs.mosip.io/1.2.0/id-lifecycle-management/identity-management/identifiers) {% hint style="info" %} Note: To generate the MOSIP ID(UIN) please visit the [Self Registration Portal](https://self-register.collab.mosip.net/) hosted on MOSIP collab. {% endhint %} # Login with OTP ### Try It Yourself This demo uses **Fyntel Telecom** as a **simulated service provider portal** to demonstrate how a telecom operator can securely authenticate a resident using their National ID before allocating an eSIM. Click **here** to navigate to the [**Fyntel eSIM Allocation Portal**](https://esim-mosipid.collab.mosip.net/), and follow the steps below to complete the eSIM allocation flow using **OTP-based authentication via eSignet**. ### Step-by-Step Flow #### Step 1: Access the eSIM Portal The resident opens the [**Fyntel Portal**](https://esim-mosipid.collab.mosip.net/) and clicks **Get Started** to begin the authentication process.

#### Step 2: Choose an Authentication Method The eSignet login screen is displayed with available authentication options.To proceed with OTP-based authentication, the resident selects **Login with OTP**.

#### Step 3: Enter National ID Details The resident enters a valid **UIN**/**VID** in the *Enter UIN/VID* field.

#### Step 4: Request OTP The resident clicks **Get OTP**. An OTP is sent to the resident’s registered mobile number or email address. {% hint style="info" %} **Note: OTP Delivery Update for eSignet Login**\ Previously, the eSignet login flow in the MOSIP Collab (Sandbox) environment used a static OTP (`111111`) for easy self-experience by the community. As per the latest MOSIP platform deployment, OTP delivery now works as follows: * If you registered with a **valid, accessible email address**, the **OTP will be sent to that email**. Please ensure you use a valid, accessible email ID during self-registration to receive it directly. * If you did not add a valid email during registration, **you can still get an OTP!** Go to [smtp.collab.mosip.net](http://smtp.collab.mosip.net) **(public mailbox) to get the OTP.** (**Important:** You must refresh/reload the public mailbox ([smtp.collab.mosip.net](http://smtp.collab.mosip.net)) to clear any previous OTPs and then click Get OTP and use the newly received one to complete login. {% endhint %}

#### Step 5: Verify OTP The resident enters the received OTP and clicks **Verify** to complete authentication.

#### Step 6: Provide Consent After successful authentication, the resident is redirected to the **Consent screen**. * **Essential claims** required for eSIM allocation are mandatory * **Voluntary claims** are optional and may be selected by the resident * A **master toggle** allows selecting all voluntary claims at once * The consent screen is shown only if consent has not been previously granted * A timer is enforced; if no action is taken within the allowed time, the resident is redirected back to the eSIM portal

#### Step 7: Confirm and Proceed The resident reviews and selects the claims to be shared, then clicks *Allow* to provide consent. Upon approval, the resident is redirected back to the eSIM Allocation Portal to continue the eSIM allocation process.

#### Step 8: Select eSIM Plan The resident selects the desired eSIM plan from the available options and clicks **Next** to proceed.

#### Step 9: Enter Device Information The resident provides device-specific details, such as: * **IMEI number** * **EID number** After entering the required information, the resident clicks **Next**.

#### Step 10: Review Pre-filled Personal Details The user’s personal information is **automatically fetched from the MOSIP ID system** and pre-filled based on the **claims approved during the consent step**. The resident reviews the details, verifies their accuracy, and clicks **Submit**.

#### Step 11: eSIM Allocation Confirmation Upon successful submission: * An **eSIM is allocated** to the resident * A **success acknowledgment** is displayed on the portal

This completes the **eSIM allocation process using National ID authentication via eSignet**. # Patient Registration Portal #### **Experience eSignet in Action Through the ANC Patient Registration Demo Portal** Experience eSignet in action with a demo ANC patient registration on the [DHIS2 Registration Portal](https://mosip.integration.dhis2.org/dhis-web-login/#/), illustrating secure National ID-based identity verification before patient enrollment into the health registry. Hosted on the [MOSIP Collab Sandbox](https://collab.mosip.net/), this portal acts as a relying party application and allows you to experience how eSignet integrates seamlessly into healthcare registration workflows that require trusted identity authentication. A Public Health Midwife (PHM) uses this portal to register a pregnant mother by verifying her identity using a National ID (UIN) before her demographic details are fetched and a Patient Health Number (PHN) is issued. * OTP-based authentication The portal supports real MOSIP IDs, enabling easy exploration without prerequisites. In just a few steps, you can experience a secure and smooth authentication flow that culminates in the registration of a patient into the national health registry, with her record automatically synced to the FHIR server. This demo portal serves as a hands-on environment to understand how eSignet can be used for identity-verified patient registration in healthcare, and sets the context for the detailed end-user guide that follows. #### **Prerequisites** The patient is registered in the national identity system and holds a valid [MOSIP ID (UIN) or Virtual ID (VID)](https://docs.mosip.io/1.2.0/id-lifecycle-management/identity-management/identifiers) with an active mobile number linked to their National ID for OTP delivery. # Try It Yourself ### Section 1: Introduction & Overview This guide walks you through the ANC (Antenatal Care) patient registration journey powered by the integration of eSignet with the [DHIS2 Registration Portal](https://mosip.integration.dhis2.org/dhis-web-login/). The focus of this guide is registration — the first and most critical step in the healthcare journey — where a Public Health Midwife (PHM) registers a pregnant mother into the national health registry using her verified National ID. You can self-experience the complete registration flow by following the step-by-step instructions in this guide. You will need access to the DHIS2 Registration Portal, an eSignet-enabled test environment, and a test National ID with a registered mobile number for OTP delivery. #### The Story: One Registration, One Identity, One Record A pregnant mother visits her local PHM centre for the first time. Rather than filling out paper forms with details that may be incomplete or duplicated across facilities, her identity is verified in real time against the national ID system. In a matter of minutes, her demographic details are fetched automatically, a registration record is created in the [DHIS2 portal](https://mosip.integration.dhis2.org/dhis-web-login/), a Patient Health Number (PHN) is issued to uniquely identify her across all health services, and her complete record is securely stored in a central FHIR server — ready to be accessed by any authorised healthcare provider. Her data belongs to her and is anchored to a single verified identity. No manual re-entry, no duplicate records, no paperwork to carry between visits. #### The Platforms in This Guide This guide focuses on two core platforms that work together to deliver a trusted, connected registration experience. DHIS2 is the health information software that powers the PHM Registration Portal — it is where the PHM logs in, enters clinical details, and submits the patient registration. Once registration is complete, the full patient record is automatically pushed to the FHIR Server — the central, shared health data repository that stores every patient record in a structured, interoperable format. The FHIR Server is what makes the patient's data available to any authorised health system beyond this registration step. The portals and components covered in this guide are: * [**DHIS2 PHM Registration Portal**](https://mosip.integration.dhis2.org/dhis-web-login/) — where the PHM registers the pregnant mother, verifies her identity via eSignet, and issues a Patient Health Number (PHN). * **FHIR Server** — the central backend health data store that receives and stores the patient record immediately after registration. #### The Shared Identity & Authentication Layer Underpinning the registration process is a shared identity and authentication layer made up of MOSIP and eSignet. MOSIP is the national identity platform — it holds the verified demographic record (name, date of birth, address) and the registered mobile number for every National ID holder. eSignet is MOSIP's OpenID Connect-based authentication layer, used to verify the patient's identity against the National ID system at the point of registration. When a PHM initiates identity verification, eSignet triggers an OTP to the patient's registered mobile, confirms the response with MOSIP, obtains explicit data-sharing consent, and returns the verified demographic data to pre-populate the registration form — all within a single, seamless flow. #### Registration Journey at a Glance 1. **PHM Logs into DHIS2 Portal** — The PHM authenticates via eSignet using her own National ID and accesses the DHIS2 Registration Portal dashboard. 2. **New Patient Registration Initiated** — The PHM selects the health facility and clicks "Create new person" to begin a new patient registration. 3. **Patient Identity Verified via eSignet** — The PHM clicks "Verify with National ID". eSignet sends an OTP to the patient's registered mobile. The patient provides the OTP. MOSIP confirms identity and returns verified demographics. 4. **Demographics Auto-Populated** — The patient's name, date of birth, and address are automatically filled in the registration form from MOSIP data. The PHM completes the remaining clinical details. 5. **PHN Issued** — A new Patient Health Number (PHN) is generated and assigned, or an existing PHN is linked if the patient is already in the system. 6. **Record Pushed to FHIR Server** — On submission, the complete patient record — verified identity, PHN, and clinical details — is automatically synced to the FHIR Server. > 💡 **Note:** eSignet-based National ID authentication is used at two points in registration: once for the PHM to log in to the portal, and once to verify the patient's identity and fetch her demographic data from MOSIP. *** ### Section 2: PHM-Assisted DHIS2 Registration Portal The PHM-Assisted Registration Portal is the entry point of the ANC journey. A Public Health Midwife (PHM) uses this portal to register pregnant mothers who visit the PHM centre. The portal integrates with eSignet to verify the patient's identity using her National ID, ensuring that every registration is tied to a government-verified identity from the very first step. Once the patient's identity is verified and her demographic data is fetched automatically from MOSIP, the PHM completes the health-specific details and submits the registration. A Patient Health Number (PHN) is either retrieved — if the patient is already in the system — or newly generated and assigned to uniquely identify her across all future health services. You can access the DHIS2 Registration Portal #### Who Uses This Portal? * **Primary User:** Public Health Midwife (PHM) — logs in and operates the portal on behalf of the patient. * **Patient:** Present at the PHM centre but does not operate the portal directly. She provides her National ID and receives the OTP on her registered mobile phone. #### Step-by-Step: Patient Registration 1. **PHM Opens the Registration Portal** — The PHM navigates to the DHIS2 Registration Portal on the workstation at the PHM centre. The eSignet login page is displayed. 2. **PHM Logs in with National ID via eSignet** — The PHM clicks "Sign in with eSignet". The eSignet login page opens. The PHM enters her own National ID and completes OTP authentication to securely access the portal. 3. **Select Organisation Unit and New Registration** — After login, the PHM selects the health facility (organisation unit) and clicks "Create new person" on the dashboard to begin registering a new patient. 4. **Initiate Patient Identity Verification** — The PHM clicks the "Verify with National ID" button in the registration form. The eSignet verification page opens on-screen. 5. **Enter Patient's National ID** — The PHM enters the pregnant mother's National ID into the eSignet verification page. 6. **eSignet Triggers OTP to Patient** — eSignet sends a One-Time Password (OTP) to the mobile phone number linked to the patient's National ID in MOSIP. The patient receives the OTP on her phone. 7. **Patient Provides OTP** — The patient reads out the OTP she received. The PHM enters the OTP into the portal on the patient's behalf. The patient's identity is now successfully verified by eSignet and MOSIP. 8. **PHM Obtains Patient Consent** — eSignet displays a consent screen listing the demographic data that will be retrieved from MOSIP (name, date of birth, address). The PHM presents this to the patient, obtains explicit verbal consent, and clicks "Allow". 9. **Demographics Auto-Populated** — eSignet returns the patient's verified demographic details from MOSIP. The fields — full name, date of birth, and address — are automatically populated in the registration form. The PHM verifies these details with the patient. 10. **Check for Existing PHN** — The PHM asks whether the patient already has a Patient Health Number (PHN). Two paths are possible — see PHN Handling below. 11. **Complete Clinical Health Information** — The PHM completes the remaining registration details not covered by the identity system: gestational age, obstetric history, blood group, known conditions, and any other relevant clinical information. 12. **Submit Registration** — The PHM reviews the completed form and clicks "Save". The patient's registration record is created in the DHIS2 system. 13. **Record Pushed to FHIR Server** — The full patient record — verified demographics, PHN, and clinical details — is automatically synced to the FHIR server, making it immediately available to any authorised healthcare system. #### PHN Handling — Two Scenarios **Scenario A: Patient Already Has a PHN** 1. **PHM Enters Existing PHN** — The PHM enters the patient's existing PHN in the dedicated "Existing PHN" field on the registration form. 2. **PHN System Returns Existing Record** — The portal fetches the demographic details stored against that PHN from the PHN system. 3. **Manual Verification** — The PHM manually compares the data from the PHN system against the verified demographics fetched from MOSIP via eSignet. Both sets of data are displayed side by side. 4. **Proceed if Details Match** — If the information matches, the PHM confirms and proceeds with the registration linked to the existing PHN. If details do not match, the PHM escalates to a supervisor before proceeding. **Scenario B: Patient Does Not Have a PHN** 1. **PHM Completes Registration Without PHN** — The PHM leaves the PHN field blank and completes the rest of the registration form normally. 2. **New PHN Generated** — Upon submission, the system automatically generates a new Patient Health Number (PHN) and assigns it to the patient. 3. **PHN Communicated to Patient** — The newly issued PHN is displayed on the confirmation screen. The PHM communicates the PHN to the patient, who should note it down for all future health visits. > ⚠️ **Important:** The PHN is the patient's unique identifier across all health services. Once issued, it is the key used to retrieve and link her records across any facility or health system that is connected to the FHIR Server. The patient should keep it safe and bring it to every future visit. *** ### Section 3: FHIR Server — The Shared Health Data Layer The FHIR (Fast Healthcare Interoperability Resources) server is the central health data repository that stores every patient record created through the DHIS2 Registration Portal. It operates in the background — end users never interact with it directly — but it is what gives the registration its lasting value. The moment a patient is registered and her record is submitted in the DHIS2 portal, that record is automatically pushed to the FHIR server, where it becomes available in a structured, standards-based format to any authorised health system. FHIR is an international standard published by HL7 for exchanging healthcare information electronically. By storing patient data in FHIR format, the registration record can be shared across hospitals, labs, insurance systems, and government platforms without requiring custom integrations for every new connection. #### What the FHIR Server Stores After Registration When the PHM completes and submits a patient registration in the DHIS2 portal, the following data is pushed to the FHIR server: * **Patient demographic record** — name, date of birth, and address, as verified via eSignet and MOSIP at the point of registration. * **Patient Health Number (PHN)** — the unique identifier that links all future records for this patient. * **Initial clinical information** — gestational age, blood group, obstetric history, and any other health details entered by the PHM during registration. As the patient progresses through the health system, further records — such as ANC visit notes, observations, prescriptions, and appointment schedules — will be added to her FHIR record by authorised care providers. #### How the FHIR Server Fits into Registration | Step in Registration | What is Sent to the FHIR Server | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | PHM submits the completed registration form | A new FHIR Patient resource is created containing the verified demographics (from MOSIP via eSignet) and the assigned PHN. | | Clinical details are saved | A FHIR Observation or Encounter resource is created containing the initial clinical data entered by the PHM (gestational age, blood group, etc.). | | PHN is issued or linked | The PHN is stored as the patient's primary identifier within the FHIR resource, enabling future lookup and record linking by any authorised portal. | #### Why the FHIR Server Matters Without the FHIR server, each registration would be an isolated record visible only within the DHIS2 portal. The FHIR server is what transforms the registration into a shared, living health record. Any authorised system — a doctor's portal, a hospital, a health insurance platform — can retrieve the patient's data using her PHN, without needing to ask her to re-register or re-verify her identity. The data entered by the PHM at registration is the foundation of everything that follows in the patient's health journey. Because FHIR is a global open standard, this architecture is future-proof: new health systems can be connected to the same FHIR server at any time without rebuilding the registration workflow. > 🔗 **FHIR:** The FHIR server is not a portal or application that users log into. It is a backend service that receives data automatically when the PHM submits a registration. From the PHM's perspective, the sync is invisible — the record is simply saved and available. *** ### Section 4: MOSIP & eSignet — The Shared Identity & Authentication Layer MOSIP and eSignet form the trusted identity backbone of the DHIS2 registration workflow. Every time an identity needs to be verified — whether a PHM logging in to the portal or a patient's identity being confirmed before registration — MOSIP and eSignet handle that verification seamlessly in the background. From the end user's perspective, it is simply a button click followed by an OTP. What happens beneath is a secure, standards-based exchange between eSignet and the national identity system. #### MOSIP — The National Identity Platform MOSIP (Modular Open Source Identity Platform) is the government's foundational digital identity system. It issues and manages the National ID used by every person in the ecosystem — patients and PHMs alike. MOSIP holds the authoritative record of each person's verified demographic details and the mobile number linked to their National ID, which is used when delivering OTPs during authentication. In the context of the DHIS2 ANC registration, MOSIP provides three critical things. First, it holds the verified demographic profile — name, date of birth, and address — for every National ID holder, which eSignet fetches and returns to the registration form after successful authentication. Second, it delivers the OTP to the patient's registered mobile number at the moment identity verification is triggered. Third, through its ID Authentication (IDA) service, it validates that the OTP entered is correct and that the identity has been successfully confirmed. MOSIP itself has no consumer-facing interface in this workflow. It operates entirely as backend infrastructure, communicating with eSignet automatically and invisibly to both the PHM and the patient. **Key MOSIP Concepts** | Term | Meaning | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **National ID** | The unique, government-issued identity number assigned to every registered person. Used as the authentication identifier during eSignet login and patient verification. | | **IDA (ID Authentication)** | MOSIP's authentication service. When the PHM submits an OTP on behalf of the patient, eSignet calls MOSIP IDA to validate it and confirm the identity. | | **VID (Virtual ID)** | A temporary, revocable alias for the National ID. Can be used in place of the full National ID during eSignet authentication to protect the real ID number from exposure. | | **KYC (Know Your Customer)** | The verified demographic profile returned by MOSIP to eSignet after successful authentication. This data — name, date of birth, address — is what gets auto-populated in the DHIS2 registration form. | #### eSignet — The Authentication Solution eSignet is MOSIP's OpenID Connect (OIDC) authentication layer. It acts as the bridge between the MOSIP identity database and any application that needs to verify a user's identity. In the DHIS2 registration workflow, eSignet is used at two distinct points: first to authenticate the PHM when she logs in to the portal, and again to verify the patient's identity before her demographics are fetched for the registration form. Think of eSignet as the "Verify with National ID" mechanism that appears at each authentication point. It handles the entire flow — prompting for the National ID, sending the OTP to the registered mobile, displaying the consent screen, and returning the verified data — so that neither the PHM portal nor the DHIS2 system needs to handle raw identity credentials directly. **How eSignet Works in the Registration Portal** 1. **Authentication Triggered** — Either the PHM clicks "Sign in with eSignet" (for portal login) or "Verify with National ID" (for patient verification). The eSignet page is displayed. 2. **National ID Entered** — The relevant National ID is entered — the PHM's own ID for portal login, or the patient's ID for patient verification. 3. **OTP Delivered by MOSIP** — eSignet calls MOSIP, which sends a 6-digit OTP to the mobile number registered against that National ID. The OTP is valid for a limited time, typically 3 minutes. 4. **OTP Submitted** — The OTP is entered on the eSignet page. eSignet submits it to MOSIP IDA for validation. 5. **Consent Screen Displayed** — On successful OTP validation, eSignet shows a Consent screen listing the specific data claims that will be shared (e.g., name, date of birth, address). The user reviews and clicks "Allow". 6. **Verified Data Returned** — eSignet returns an authorisation token and the consented KYC data to the portal. For patient verification, this is what auto-populates the demographics fields in the registration form. **Authentication Methods Available** eSignet supports multiple ways for a user to prove their identity. In the DHIS2 registration context, OTP is the primary method used for both PHM login and patient verification: * **OTP (One-Time Password):** MOSIP sends a 6-digit OTP to the registered mobile number. The user (or PHM on behalf of the patient) enters it to confirm identity. This is the method used in the registration portal. * **Biometrics:** Fingerprint or iris scan via a registered biometric device, used in field registration scenarios where biometric hardware is available. * **QR Code / Inji Wallet:** The user scans a QR code on the eSignet page using the Inji mobile wallet app, which authenticates using a locally stored Verifiable Credential. **eSignet's Role in the Registration Portal** | Authentication Point | Who Authenticates | What eSignet Does | | -------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Portal Login | PHM (Public Health Midwife) | Verifies the PHM's identity against MOSIP. Returns an access token to the portal, granting the PHM access to the DHIS2 registration dashboard. | | Patient Verification | Patient (via PHM) | Verifies the patient's identity against MOSIP. Returns the patient's KYC data (name, DOB, address) to pre-populate the registration form. Displays a consent screen before any data is shared. | > 💡 **Note:** The Consent screen is a mandatory privacy control. Before any personal demographic data is shared from MOSIP with the DHIS2 portal, eSignet displays exactly what will be shared. The patient must explicitly consent — verbal confirmation to the PHM, who clicks "Allow" on her behalf — before any data is transferred. *** ### Section 5: Glossary of Key Terms | Term | Definition | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **ANC** | Antenatal Care — healthcare provided to pregnant women during pregnancy, covering medical check-ups, monitoring, and advice from conception to delivery. | | **DHIS2** | District Health Information Software 2 — an open-source, web-based platform for health data management, deployed in over 80 countries. Powers the PHM Registration Portal in this use case. | | **PHM** | Public Health Midwife — the healthcare worker who operates the DHIS2 Registration Portal to register pregnant mothers at the PHM centre. | | **PHN** | Patient Health Number — the unique identifier assigned to each registered patient. Issued at registration and used to retrieve and link health records across all connected health systems. | | **MOSIP** | Modular Open Source Identity Platform — the national identity platform that issues and manages National IDs and provides the ID Authentication service used by eSignet. | | **National ID** | The unique, government-issued identity number assigned to every registered person. Used as the authentication identifier for both PHM login and patient verification via eSignet. | | **VID** | Virtual ID — a temporary, revocable alias for the National ID. Can be used in place of the full National ID during eSignet authentication to protect the real ID number. | | **eSignet** | MOSIP's OpenID Connect-based authentication service. Used in the DHIS2 portal to verify the PHM's identity (login) and the patient's identity (registration), returning verified KYC data to pre-populate the form. | | **OIDC** | OpenID Connect — the open authentication protocol that eSignet implements, enabling secure, standardised identity verification between the DHIS2 portal and MOSIP. | | **OTP** | One-Time Password — a 6-digit code sent to the user's registered mobile number by MOSIP during eSignet authentication. Valid for a limited time (typically 3 minutes). | | **KYC** | Know Your Customer — the verified demographic profile (name, date of birth, address) returned by MOSIP to eSignet after successful authentication. Auto-populates the patient registration form. | | **IDA** | ID Authentication — the MOSIP service that validates OTPs submitted via eSignet, confirming that the identity has been successfully verified. | | **Consent Screen** | The page displayed by eSignet after successful OTP authentication, listing exactly which demographic data will be shared with the DHIS2 portal. The PHM clicks "Allow" on the patient's behalf after obtaining verbal consent. | | **FHIR** | Fast Healthcare Interoperability Resources — an international HL7 standard for structuring and exchanging healthcare data electronically. | | **FHIR Server** | The central backend health data repository. Patient records created in the DHIS2 portal are automatically synced here upon registration, making them available to any authorised health system using the patient's PHN as the lookup key. | To learn more about DHIS2 please [refer here](https://dhis2.org/). # Roadmap and Releases Explore the eSignet Roadmap & Releases to stay updated on key milestones, new features, and major updates.

Cover image
Roadmap Card.png	Roadmap
Releases Card.png	Releases

# Roadmap Explore eSignet roadmap for key milestones, objectives, and highlights every year.

Cover image	Cover image
	Roadmap 2026.png	Roadmap 2026

# Roadmap 2026 Here we present the eSignet product roadmap for 2026 and our strategic horizon forward. This roadmap outlines the planned features, progress, and release details for eSignet. > **Annual product cycle** of eSignet commences in **January** and concludes in **December**.

Vision

eSignet Go's vision is simple: nail the foundations first, then keep expanding what's possible on top of them. The roadmap starts with a stable, standards-based general-availability release — carrying forward everything the Java version proved, on the leaner stack described under Tech Stack — and builds from there: Face and Passkey Authentication alongside today's PIN, OTP, and biometric options, wallet-based login through OpenID4VP, decoupled sign-in via CIBA, and eventually user-level MFA and single sign-on across "super app" ecosystems. Each milestone ships as its own release, one step at a time toward a more flexible, more capable eSignet.\ The table below tracks where things stand.

Priority 🗓️	Features 🛠️	Details📝	Status 📊	Release 📌
P1	eSignet Go Version (GA) Deliver a stable release of eSignet for production deployments.	Milestone	🟠 In Progress	v2.0.0
P1	Face Authentication with eSignet: Introduce face authentication as a high-assurance, on-the-go authentication factor in eSignet.	TBA	🔵 Planned
P1	Wallet-based login using OpenID4VP Standard way to request specific credentials from a wallet and receive verified presentation	TBA	🔵 Planned
P1	Passkey Authentication Support Enable passkeys for passwordless, phishing-resistant authentication.	TBA	🔵 Planned
P1	CIBA Support in eSignet	TBA	🔵 Planned
P3	MFA Support – User Level: Allow users to manage and use multiple authentication factors during login.	TBA	🔵 Planned
P2	Single Sign-On (SSO) Super App Support: Enable SSO capabilities to support super apps and seamless cross-application login experiences.	TBA	🔵 Planned

> This roadmap covers eSignet Go only, starting from the v2.0.0 general availability release. Earlier Java-versioned releases (v1.x.x and below v2.0.0) follow a separate roadmap and aren't reflected here. **Acronyms and Legends**: TBA - 'Github Issues Link - To Be Added' # Releases Please refer below for all the latest release details ✨ ## Version: v2.0.0-Beta.1 * **Name**: eSignet * **Date:** 19th May, 2026 * [**Release Notes**](broken://pages/012L3vqZT3SxDZxsHHi0) # v2.0.0-Beta.1 **Release Number:** v2.0.0-Beta.1\ **Release Date:** 26th Aug, 2026 ## Overview [eSignet v2.0.0-Beta.1](https://github.com/mosip/esignet/tree/v2.0.0-beta.1) marks the migration of eSignet's core authentication engine from Java to Go, built on the [Thunder ID engine](https://github.com/thunder-id). This is a migration release: the eSignet user interface and feature set carry over unchanged, and this beta is at full feature parity with [eSignet (Java) v1.8.0](https://github.com/mosip/esignet/tree/v1.8.0), unless explicitly called out as out of scope below. No end-user-facing behavior has changed as part of this migration; what's changed is the engine running underneath. ## Major Highlights ### Go-Based Core Engine eSignet's authentication engine has been rebuilt on **Go**, using the [**Thunder ID engine**](https://github.com/thunder-id) — a Go-based identity provider engine from WSO2. This is the foundational change behind this release, and everything else in this beta builds on it. ### Feature Parity with eSignet v1.8.0 All eSignet features present in the latest [Java release (**v1.8.0**)](https://github.com/mosip/esignet/tree/v1.8.0) are carried forward in this Go-based beta at full parity, except where explicitly listed as out of scope below. The UI, authentication flows, and standards compliance are unchanged for end users and integrators. ## Out of Scope The following are **not supported** in this beta release: * **WLA (Wallet-based Login Authentication)** login is not supported in this release. * **Client management endpoint support for title and subtitle fields** during relying party (RP) onboarding is not supported in this release. * **Database support is limited to PostgreSQL only** in this release; no other database backends are supported at this time. * **This beta does not include the eSignet Signup module.** eKYC and Identity Assurance 1.0 capabilities remain on the Java-based Signup module for now and have not yet been migrated to Go. ## Story Development Please [refer here](https://github.com/mosip/esignet/issues?q=milestone%3AeSignet_thunder_2.0.0_beta.1%20and%20type%3AFeature) for the full list of stories implemented for this release. ## Known Issues Please [refer here](https://github.com/mosip/esignet/issues?q=state%3Aopen%20milestone%3AeSignet_v2.0.0%20type%3ABug) for the full list of known issues in the beta version. ## Repositories Released | Repository | Version/Tag | | --------------------- | ------------------------------------------------------------------------------------ | | eSignet | [v2.0.0-Beta.1](https://github.com/mosip/esignet/tree/v2.0.0-beta.1) | | eSignet-mock-services | [v0.14.0-Beta.1](https://github.com/mosip/esignet-mock-services/tree/v0.14.0-beta.1) | ## Compatible Modules ### eSignet compatibility with MOSIP | Module/Repo | Compatible Version | | ----------- | ----------------------------------------------------------------------------- | | PMS | [1.2.2.3](https://github.com/mosip/partner-management-services/tree/v1.2.2.3) | | IDA | [1.3.0](https://github.com/mosip/id-authentication/tree/v1.3.0) | ### eSignet compatibility with Sunbird | Module/Repo | Compatible Version | | ----------- | --------------------------------------------------------------------------- | | Sunbird | [v2.0.0-rc3](https://github.com/Sunbird-RC/sunbird-rc-core/tree/v2.0.0-rc3) | ## DB Changes **eSignet** * Please refer the [link here](https://github.com/mosip/esignet/blob/release-2.0.x-beta.1/db_upgrade_script/mosip_esignet/sql/1.8.0_to_2.0.0_upgrade.sql) for the DB upgrade script. * Please refer the [link here](https://github.com/mosip/esignet/blob/release-2.0.x-beta.1/db_upgrade_script/mosip_esignet/sql/1.8.0_to_2.0.0_rollback.sql) for the DB rollback script. ## Configuration Changes For a comprehensive view of all configuration properties in eSignet (Go), please [refer here](https://github.com/mosip/esignet/blob/release-2.0.x-beta.1/esignet-service/.env.example). ## Documentation ### API Documentation * [eSignet (Go) API](https://github.com/mosip/esignet/blob/release-2.0.x-beta.1/docs/esignet-openapi.yaml) # v2.0.0 Coming Soon! # Test Report Coming Soon! # Performance Report ## **Overview** The eSignet Performance Testing Report provides a comprehensive analysis of the system’s responsiveness, reliability, and scalability under various operational conditions. It captures key performance metrics such as throughput, resource utilization and memory consumption. This report is designed to help stakeholders understand how eSignet performs in real-world scenarios, identify potential bottlenecks, and guide future optimizations to ensure a seamless and secure authentication experience. ## **Summary** Load tests were conducted to assess the performance and stability of eSignet APIs. The mock-identity-system was used to artificially induce 1,3 and 5 second delay in 3 different tests to check for performance variability under different response times. During each of the three 10‑hour test windows, the system successfully processed \~1.9 million authentications originating from 100,000 unique identities, maintaining a steady throughput of \~50 transactions per second. Throughout the test, all API response times consistently remained close to the 100‑millisecond SLA target (not including the artificial mock delay). A Resource Calculator is provided to help estimate their hardware requirement to achieve similar performance at a larger scale. No major performance degradation or bottlenecks were observed throughout the test duration. Based on the results, this module is assessed to be stable, performant, and ready for release. However, few issues have been recognized, documented and will be addressed in future release. ## **Performance Improvements** In this release the core authentication engine has been migrated from Java to Go, for better long-term sustainability, performance and efficiency. Go, as a runtime, has been judged to be better suited to the kind of high-throughput, low-latency authentication workloads that a national identity backend needs to sustain. Improvements have been made in caching, connection management. Go configs have also been tuned to match varying possible auth response times. ## **Test Environment** ### **Deviation from the default** * `mock-identity-system` service was used as an Identity authentication provider. The response delay was set to 1,3 and 5 seconds in three different tests. ### **Software Under Test** Following ‘Images’ were under the scope of ‘Performance Testing’, and will be transferred as mosipid images #### **Modules Segregation** | Image ID | Branch Name | Comments | | ----------------------------------- | -------------- | --------------------------------------- | | mosipqa/eSignet:2.0.x | release-2.0.x | | | mosipqa/oidc-ui:2.0.x | release-2.0.x | | | mosipqa/mock-identity-system:0.14.x | release-0.14.x | Repo used is mosip/eSignet-mock-service | ### **Test Data** Performance data load was populated before the run to ensure realistic results. | DB | Table Name | Number Of Records (Target) | Number Of Records (Tested with) | | ------------------------- | -------------- | -------------------------- | ------------------------------- | | mosip\_mockidentitysystem | Mock\_identity | 100,000 | 100,000 | ### **Test Design** * Test Duration: 10-Hours * Test Type: Load Test * Ramp Up: 15 mins * Total TPS: 50 #### **Workload Model** | Scenario Name | API Endpoint | SLA (ms) | Weightage/ Load Distribution | Throughput (TPS) | Target Volume | | ---------------------------- | ------------------------------------------------------ | -------- | ---------------------------- | ---------------- | ------------- | | S01 OTP Authentication | S01 T01 Initiate PAR Endpoint | 100 | 80% | 40 | 1,440,000 | | | S01 T02 Send Authorize Endpoint | 100 | | | | | | S01 T03 Flow Meta Endpoint | 100 | | | | | | S01 T04 1 Authentication Flow - Start Endpoint | 100 | | | | | | S01 T04 2 Authentication Flow - ACR Endpoint | 100 | | | | | | S01 T04 3 Authentication Flow - Individual ID Endpoint | 100 | | | | | | S01 T04 4 Authentication Flow - OTP Endpoint | 100 | | | | | | S01 T04 5 Authentication Flow - Consent Endpoint | 100 | | | | | | S01 T05 Obtain Authorization Code Endpoint | 100 | | | | | | S01 T06 Obtain Access Token Endpoint | 100 | | | | | | S01 T07 User Info Endpoint | 100 | | | | | S02 Biometric Authentication | S02 T01 Initiate PAR Endpoint | 100 | 20% | 10 | 360,000 | | | S02 T02 Send Authorize Endpoint | 100 | | | | | | S02 T03 Flow Meta Endpoint | 100 | | | | | | S02 T04 1 Authentication Flow - Start Endpoint | 100 | | | | | | S02 T04 2 Authentication Flow - Select acr Endpoint | 100 | | | | | | S02 T04 3 Authentication Flow - Individual ID Endpoint | 100 | | | | | | S02 T04 4 Authentication Flow - Bio Endpoint | 100 | | | | | | S02 T04 5 Authentication Flow - Consent Endpoint | 100 | | | | | | S02 T05 Obtain Authorization Code Endpoint | 100 | | | | | | S02 T06 Obtain Access Token Endpoint | 100 | | | | | | S02 T07 User Info Endpoint | 100 | | | | ## **Test Results** ### **Performance test execution results** #### **Test 1** | **Application Name** | eSignet (under 5 second mock response delay) | | ------------------------------ | ---------------------------------------------- | | **Test Duration** | 7/9/26, 1:56 PM - 11:56 PM (10-Hours) | | **Number of parallel threads** | 802 | | **Status** | **GREEN** | #### **Test 2** | **Application Name** | eSignet (under 3 second mock response delay) | | ------------------------------ | ---------------------------------------------- | | **Test Duration** | 8/9/26, 10:27 AM – 8:27 PM (10-Hours) | | **Number of parallel threads** | 516 | | **Status** | **GREEN** | #### **Test 3** | **Application Name** | eSignet (under 1 second mock response delay) | | ------------------------------ | ---------------------------------------------- | | **Test Duration** | 8/9/26, 9:00 PM - 9/9/26 7:00 PM (10-Hours) | | **Number of parallel threads** | 191 | | **Status** | **GREEN** | ### **Test Reports** #### **Test 1 - under 5 second mock response delay** | Scenario Name | Transaction Name | API Endpoint | 50 TPS 802 VUsers | | | | | | | ---------------------------- | ------------------------------------------------------ | -------------------------------- | --------------------------- | ------- | ----------- | ------------ | ------- | ----------- | | | | | **Date: 7/9/26 (10 Hours)** | | | | | | | | | | **# Samples** | **Min** | **Average** | **95% Line** | **Max** | **Error %** | | S01 OTP Authentication | S01 T01 Initiate PAR Endpoint | /oauth2/par → POST | 1,582,426 | 4 | 9 | 15 | 275 | 0.0% | | | S01 T02 Send Authorize Endpoint | /oauth2/authorize → GET | 1,582,426 | 6 | 14 | 25 | 272 | 0.0% | | | S01 T03 Flow Meta Endpoint | /flow/meta → GET | 1,582,426 | 13 | 22 | 35 | 293 | 0.0% | | | S01 T04 1 Authentication Flow - Start Endpoint | /flow/execute(start) → POST | 1,582,422 | 6 | 13 | 24 | 282 | 0.0% | | | S01 T04 2 Authentication Flow - ACR Endpoint | /flow/execute(select-acr) → POST | 1,582,420 | 6 | 13 | 24 | 280 | 0.0% | | | S01 T04 3 Authentication Flow - Individual ID Endpoint | /flow/execute(submit-uin) → POST | 1,582,418 | 5,010 | 5,019 | 5,031 | 5,667 | 0.0% | | | S01 T04 4 Authentication Flow - OTP Endpoint | /flow/execute(submit-otp) → POST | 1,582,205 | 5,013 | 5,024 | 5,037 | 5,301 | 0.0% | | | S01 T04 5 Authentication Flow - Consent Endpoint | /flow/execute(consent) → POST | 1,581,984 | 5,015 | 5,030 | 5,046 | 5,322 | 0.0% | | | S01 T05 Obtain Authorization Code Endpoint | /oauth2/auth/callback → POST | 1,581,754 | 6 | 15 | 27 | 260 | 0.0% | | | S01 T06 Obtain Access Token Endpoint | /oauth2/token → POST | 1,581,750 | 5 | 12 | 22 | 263 | 0.0% | | | S01 T07 User Info Endpoint | /oauth2/userinfo → GET | 1,581,748 | 6 | 13 | 23 | 231 | 0.0% | | S02 Biometric Authentication | S02 T01 Initiate PAR Endpoint | /oauth2/par → POST | 359,798 | 4 | 9 | 16 | 93 | 0.0% | | | S02 T02 Send Authorize Endpoint | /oauth2/authorize → GET | 359,794 | 6 | 15 | 31 | 256 | 0.0% | | | S02 T03 Flow Meta Endpoint | /flow/meta → GET | 359,793 | 13 | 24 | 42 | 286 | 0.0% | | | S02 T04 1 Authentication Flow - Start Endpoint | /flow/execute(start) → POST | 359,792 | 6 | 13 | 27 | 221 | 0.0% | | | S02 T04 2 Authentication Flow - Select acr Endpoint | /flow/execute(select-acr) → POST | 359,791 | 6 | 13 | 24 | 231 | 0.0% | | | S02 T04 3 Authentication Flow - Individual ID Endpoint | /flow/execute(submit-uin) → POST | 359,791 | 6 | 13 | 24 | 256 | 0.0% | | | S02 T04 4 Authentication Flow - Bio Endpoint | /flow/execute(submit-otp) → POST | 359,791 | 5,012 | 5,024 | 5,039 | 5,283 | 0.0% | | | S02 T04 5 Authentication Flow - Consent Endpoint | /flow/execute(consent) → POST | 359,739 | 5,017 | 5,032 | 5,054 | 5,295 | 0.0% | | | S02 T05 Obtain Authorization Code Endpoint | /oauth2/auth/callback → POST | 359,686 | 6 | 15 | 30 | 199 | 0.0% | | | S02 T06 Obtain Access Token Endpoint | /oauth2/token → POST | 359,682 | 5 | 12 | 22 | 130 | 0.0% | | | S02 T07 User Info Endpoint | /oauth2/userinfo → GET | 359,680 | 6 | 12 | 23 | 129 | 0.0% | #### **Test 2 - under 3 second mock response delay** | Scenario Name | Transaction Name | API Endpoint | 50 TPS 516 VUsers | | | | | | | ---------------------------- | ------------------------------------------------------ | -------------------------------- | --------------------------- | ------- | ----------- | ------------ | ------- | ----------- | | | | | **Date: 8/9/26 (10 Hours)** | | | | | | | | | | **# Samples** | **Min** | **Average** | **95% Line** | **Max** | **Error %** | | S01 OTP Authentication | S01 T01 Initiate PAR Endpoint | /oauth2/par → POST | 1,611,896 | 4 | 7 | 11 | 162 | 0.0% | | | S01 T02 Send Authorize Endpoint | /oauth2/authorize → GET | 1,611,893 | 6 | 13 | 22 | 290 | 0.0% | | | S01 T03 Flow Meta Endpoint | /flow/meta → GET | 1,611,893 | 13 | 35 | 86 | 268 | 0.0% | | | S01 T04 1 Authentication Flow - Start Endpoint | /flow/execute(start) → POST | 1,611,893 | 6 | 40 | 89 | 268 | 0.0% | | | S01 T04 2 Authentication Flow - ACR Endpoint | /flow/execute(select-acr) → POST | 1,611,893 | 6 | 42 | 89 | 3124 | 0.0% | | | S01 T04 3 Authentication Flow - Individual ID Endpoint | /flow/execute(submit-uin) → POST | 1,611,893 | 3,010 | 3,054 | 3,100 | 3877 | 0.0% | | | S01 T04 4 Authentication Flow - OTP Endpoint | /flow/execute(submit-otp) → POST | 1,611,757 | 3,013 | 3,063 | 3,118 | 3673 | 0.0% | | | S01 T04 5 Authentication Flow - Consent Endpoint | /flow/execute(consent) → POST | 1,611,619 | 3,018 | 3,066 | 3,127 | 3295 | 0.0% | | | S01 T05 Obtain Authorization Code Endpoint | /oauth2/auth/callback → POST | 1,611,483 | 6 | 29 | 75 | 302 | 0.0% | | | S01 T06 Obtain Access Token Endpoint | /oauth2/token → POST | 1,611,469 | 5 | 11 | 27 | 190 | 0.0% | | | S01 T07 User Info Endpoint | /oauth2/userinfo → GET | 1,611,462 | 6 | 11 | 17 | 222 | 0.0% | | S02 Biometric Authentication | S02 T01 Initiate PAR Endpoint | /oauth2/par → POST | 359,593 | 4 | 19 | 56 | 192 | 0.0% | | | S02 T02 Send Authorize Endpoint | /oauth2/authorize → GET | 359,590 | 6 | 27 | 86 | 239 | 0.0% | | | S02 T03 Flow Meta Endpoint | /flow/meta → GET | 359,590 | 13 | 36 | 88 | 258 | 0.0% | | | S02 T04 1 Authentication Flow - Start Endpoint | /flow/execute(start) → POST | 359,590 | 6 | 29 | 80 | 239 | 0.0% | | | S02 T04 2 Authentication Flow - Select acr Endpoint | /flow/execute(select-acr) → POST | 359,585 | 6 | 28 | 77 | 257 | 0.0% | | | S02 T04 3 Authentication Flow - Individual ID Endpoint | /flow/execute(submit-uin) → POST | 359,582 | 6 | 25 | 73 | 247 | 0.0% | | | S02 T04 4 Authentication Flow - Bio Endpoint | /flow/execute(submit-otp) → POST | 359,578 | 3,012 | 3,042 | 3,099 | 3296 | 0.0% | | | S02 T04 5 Authentication Flow - Consent Endpoint | /flow/execute(consent) → POST | 359,552 | 3,017 | 3,051 | 3,121 | 3344 | 0.0% | | | S02 T05 Obtain Authorization Code Endpoint | /oauth2/auth/callback → POST | 359,522 | 6 | 25 | 75 | 229 | 0.0% | | | S02 T06 Obtain Access Token Endpoint | /oauth2/token → POST | 359,519 | 5 | 21 | 71 | 236 | 0.0% | | | S02 T07 User Info Endpoint | /oauth2/userinfo → GET | 359,519 | 6 | 32 | 91 | 273 | 0.0% | #### **Test 3 - under 1 second mock response delay** | Scenario Name | Transaction Name | API Endpoint | 50 TPS 191 VUsers | | | | | | | ---------------------------- | ------------------------------------------------------ | -------------------------------- | --------------------------- | ------- | ----------- | ------------ | ------- | ----------- | | | | | **Date: 8/9/26 (10 Hours)** | | | | | | | | | | **# Samples** | **Min** | **Average** | **95% Line** | **Max** | **Error %** | | S01 OTP Authentication | S01 T01 Initiate PAR Endpoint | /oauth2/par → POST | 1,617,619 | 4 | 7 | 11 | 105 | 0.0% | | | S01 T02 Send Authorize Endpoint | /oauth2/authorize → GET | 1,617,613 | 7 | 15 | 35 | 119 | 0.0% | | | S01 T03 Flow Meta Endpoint | /flow/meta → GET | 1,617,613 | 14 | 35 | 63 | 120 | 0.0% | | | S01 T04 1 Authentication Flow - Start Endpoint | /flow/execute(start) → POST | 1,617,613 | 7 | 27 | 52 | 273 | 0.0% | | | S01 T04 2 Authentication Flow - ACR Endpoint | /flow/execute(select-acr) → POST | 1,617,613 | 7 | 24 | 47 | 134 | 0.0% | | | S01 T04 3 Authentication Flow - Individual ID Endpoint | /flow/execute(submit-uin) → POST | 1,617,613 | 1,011 | 1,032 | 1,056 | 1,687 | 0.0% | | | S01 T04 4 Authentication Flow - OTP Endpoint | /flow/execute(submit-otp) → POST | 1,617,567 | 1,014 | 1,037 | 1,062 | 1,707 | 0.0% | | | S01 T04 5 Authentication Flow - Consent Endpoint | /flow/execute(consent) → POST | 1,617,520 | 1,018 | 1,042 | 1,069 | 4,605 | 0.0% | | | S01 T05 Obtain Authorization Code Endpoint | /oauth2/auth/callback → POST | 1,617,474 | 6 | 17 | 36 | 122 | 0.0% | | | S01 T06 Obtain Access Token Endpoint | /oauth2/token → POST | 1,617,474 | 6 | 11 | 19 | 99 | 0.0% | | | S01 T07 User Info Endpoint | /oauth2/userinfo → GET | 1,617,469 | 6 | 10 | 13 | 78 | 0.0% | | S02 Biometric Authentication | S02 T01 Initiate PAR Endpoint | /oauth2/par → POST | 360,350 | 4 | 12 | 28 | 88 | 0.0% | | | S02 T02 Send Authorize Endpoint | /oauth2/authorize → GET | 360,350 | 7 | 21 | 51 | 112 | 0.0% | | | S02 T03 Flow Meta Endpoint | /flow/meta → GET | 360,350 | 14 | 28 | 54 | 123 | 0.0% | | | S02 T04 1 Authentication Flow - Start Endpoint | /flow/execute(start) → POST | 360,350 | 7 | 18 | 43 | 114 | 0.0% | | | S02 T04 2 Authentication Flow - Select acr Endpoint | /flow/execute(select-acr) → POST | 360,350 | 7 | 17 | 43 | 126 | 0.0% | | | S02 T04 3 Authentication Flow - Individual ID Endpoint | /flow/execute(submit-uin) → POST | 360,349 | 7 | 18 | 42 | 105 | 0.0% | | | S02 T04 4 Authentication Flow - Bio Endpoint | /flow/execute(submit-otp) → POST | 360,349 | 1,013 | 1,032 | 1,065 | 1,131 | 0.0% | | | S02 T04 5 Authentication Flow - Consent Endpoint | /flow/execute(consent) → POST | 360,339 | 1,018 | 1,040 | 1,076 | 1,157 | 0.0% | | | S02 T05 Obtain Authorization Code Endpoint | /oauth2/auth/callback → POST | 360,329 | 6 | 18 | 46 | 108 | 0.0% | | | S02 T06 Obtain Access Token Endpoint | /oauth2/token → POST | 360,326 | 6 | 14 | 35 | 124 | 0.0% | | | S02 T07 User Info Endpoint | /oauth2/userinfo → GET | 360,321 | 6 | 16 | 44 | 219 | 0.0% | #### **High Level Observations:** * The system successfully sustained 50 authentications per second for 10 consecutive hours using 100,000 unique mock identities. * No noticeable degradation in response times was observed during the entire test duration. * After excluding the intentionally introduced mock delay, the response times across all three test scenarios were largely comparable. * The 95th percentile response time remained below 100 ms for the majority of measurements. Only 4 out of 66 results exceeded this threshold, with the highest recorded value being 127 ms (Test 2 - S01 T04 5), which remains within an acceptable range. ### **Metrics** #### **Response Times Over time** **Test 1**

**Test 2**

**Test 3**

**Observations:** All transaction response times remained consistent and stable throughout the 10-hour test. #### **Throughput** **Test 1**

**Test 2**

**Test 3**

**Observations:** * Throughput remained stable throughout the 10-hour performance test, with no significant degradation observed over the duration. * The OTP Authentication flow (S01) sustained approximately 44 TPS, while the Biometric Authentication flow (S02) sustained approximately 10 TPS. * Combined, the two authentication flows achieved an aggregate throughput of more than 50 TPS. #### **Resource Utilisation** *(Grouped by Service)* 1. **eSignet**

**Observation:** * No performance bottlenecks or issues were observed in the 3 tests. * The CPU remained consistently at \~80% of 4CPU throughout the 10-hour test. * The memory was stable. But the consumption changed with mock delay. * 5sec delay = 950MB * 3sec delay = 600MB * 1sec delay = 300MB 2. **oidc-ui**

**Observation:** * Performance remained stable throughout the 10-hour run. * The CPU remained consistent around 0.25 per pod. * Memory stayed around \~130MiB per pod for 5 second delay test. For 1sec and 3sec delay tests it stayed around 70MiB per pod. * The OIDC UI can reliably handle approximately 300-400 concurrent connections with the allocated resources (0.3 vCPU and 500 MiB memory). But a larger number of connections can trigger connection churn. An issue has been created to address this in future. [\[BUG\] oidc-ui nginx connection churn and uneven distribution issue at high load · Issue #2583 · mosip/eSignet](https://github.com/mosip/esignet/issues/2583) 3. **mockid**

**Observation:** * No performance bottlenecks or issues were observed in the 3 tests. 4. **redis**

**Observation:** * No performance bottlenecks or issues were observed in the 3 tests. ## **Resource Calculator** Attached is the resource calculator excel tool. [resource\_calculator\_eSignet\_2.0.0](https://github.com/mosip/esignet/blob/release-2.0.x/performance-test/resource_calculator_eSignet_2.0.0.xlsx) ### **Resource level configuration** The following configuration was used for the performance test. | NameSpace | Deployment | Resources | | | | No.of Pods | | --------------- | -------------------- | ---------- | --------------- | ------------ | --------------- | ---------- | | | | **Limits** | | **Requests** | | | | | | **CPU(m)** | **Memory (Mi)** | **CPU(m)** | **Memory (Mi)** | | | eSignet-go-mock | eSignet-go-mock | 4000 | 1000 | 4000 | 1000 | 1 | | eSignet-go-mock | oidc-ui-go-mock | 300 | 500 | 300 | 500 | 4 | | mockid | mock-identity-system | 1000 | 1500 | 300 | 500 | 3 | ## **Comparison with eSignet Java** The primary goal of the migration to the Go engine is to reduce infrastructure resource requirements while maintaining, or improving, the existing level of responsiveness. To evaluate this objective, the performance characteristics of both codebases were compared. The most recent major performance test and report for the Java-based eSignet 1.4.x release was used as the baseline for comparison against the latest eSignet 2.0.0 (Go) release. ### **Resource Requirement Comparison** | Release | Target TPS | vCPU | RAM (GB) | | -------------------- | ---------- | ---- | -------- | | eSignet 2.0.0 (Go) | 292 | 71 | 61 | | eSignet 1.4.x (Java) | 292 | 294 | 524 | **Observation:** * For the same target peak load of 292 TPS, eSignet 2.0.0 requires approximately 76% less CPU and 88% less memory compared to the Java-based eSignet 1.4.x release. * While the improvement is less pronounced at lower TPS levels, the Go-based implementation was consistently observed to have significant reductions in resource consumption. **Additional notes:** * The target TPS and corresponding infrastructure requirements (vCPU and RAM) were calculated using the eSignet Resource Calculator. * The calculation was based on field-provided assumptions of * 105 million total population * 50 million registered users (approx) * 1 million peak-hour users (approx) * **Important Note**: The resource calculator published with eSignet 1.4.x contained a defect where the Performance Run TPS value was incorrectly populated with the RPS value. As a result, the published value was shown as 100, whereas the correct TPS value should have been 14.4. This issue is planned to be fixed in the eSignet 1.8.1 release. The corrected TPS value has already been applied internally when generating the comparison presented above. ([Issue #2584](https://github.com/mosip/esignet/issues/2584)). ### **Response Time Comparison** | eSignet 1.4.x (with 1 sec Delay) | | | | | eSignet 2.0.0 (with 1 sec Delay) | | | | | | -------------------------------- | ------------- | ------- | ------------------------------- | ----------------------------------- | ----------------------------------- | ------------------------------- | ------- | ------------- | ------------------------------------------------------ | | **Transaction Name** | **# Samples** | **TPS** | **Response time (90th pct) ms** | **Total Time (without mock delay)** | **Total Time (without mock delay)** | **Response time (90th pct) ms** | **TPS** | **# Samples** | **Transaction Name** | | S01 T01 GetCsrf | 25,969 | 14.4 | 17 | **17** | **-** | | | | | | | | | | **-** | **9** | 9 | 44.0 | 1,582,426 | S01 T01 Initiate PAR Endpoint | | S01 T02 OAuthdetails | 25,968 | 14.4 | 17 | **17** | **127** | 24 | 44.0 | 1,582,426 | S01 T02 Send Authorize Endpoint | | | | | | | | 57 | 44.0 | 1,582,426 | S01 T03 Flow Meta Endpoint | | | | | | | | 46 | 44.0 | 1,582,422 | S01 T04 1 Authentication Flow - Start Endpoint | | S01 T03 Send OTP | 25,968 | 14.4 | 1260 | **518** | **144** | 41 | 44.0 | 1,582,420 | S01 T04 2 Authentication Flow - ACR Endpoint | | S01 T04 Authentication | 25,952 | 14.4 | 1258 | | | 1048 | 44.0 | 1,582,418 | S01 T04 3 Authentication Flow - Individual ID Endpoint | | | | | | | | 1055 | 44.0 | 1,582,205 | S01 T04 4 Authentication Flow - OTP Endpoint | | S01 T05 Authorization | 25,934 | 14.4 | 19 | **19** | **88** | 1060 | 44.0 | 1,581,984 | S01 T04 5 Authentication Flow - Consent Endpoint | | | | | | | | 28 | 44.0 | 1,581,754 | S01 T05 Obtain Authorization Code Endpoint | | S01 T06 Token | 25,934 | 14.4 | 1267 | **267** | **15** | 15 | 44.0 | 1,581,750 | S01 T06 Obtain Access Token Endpoint | | S01 T07 Userinfo | 25,918 | 14.4 | 17 | **17** | **12** | 12 | 44.0 | 1,5,81,748 | S01 T07 User Info Endpoint | | **Total** | | | | **855** | **395** | | | | | **Observation:** * The overall end-to-end processing time (excluding mock delay) was reduced from approximately 855 ms in eSignet 1.4.x to 395 ms in eSignet 2.0.0, representing an improvement of approximately 54%. * Despite the substantially higher throughput, the endpoint response times in eSignet 2.0.0 remained well within 100 milliseconds (ignoring mock delay) for individual API requests. **Additional Notes:** * Transaction names differ between the two releases due to changes in the engine architecture and authentication flow. Table colour coding has been used to help identify and compare equivalent stages of the authentication journey. * The 90th percentile response time metric is used in this comparison to maintain consistency with the performance data previously published for eSignet 1.4.x. In other section of this performance report 95th percentile response time metric will be used to maintain consistency with latest MOSIP performance reports. ## **Performance Analysis** ### **KPI** The performance test was conducted to ensure this release is able to achieve a stable rate of 50 authentication per second. The test achieved 50tps for 10 hours without any degradation. Additionally, the hardware resources used to achieve this rate of transaction per second (TPS) has been shared via Resource Calculator document. It can be used to estimate resources required for higher processing as per specific needs of client countries. ### **Bottlenecks** Based on the defined scope and the results of this performance test, no major bottlenecks or performance‑limiting issues were observed. All services operated within acceptable resource boundaries. Most API response times remained below the 100ms target with only minor breaches. (max was 127ms) ### **Recommendation** * eSignet 2.0.0 is recommended for release. The build sustained the target rate of 50 authentications per second for 10 continuous hours in all three test runs, with a 0.0% error rate and no degradation in response time or throughput over the duration. * It has been observed that memory consumption increases with upstream ID Authentication latency. Successful tests have been conducted for 1, 3 and 5 second latency with recommended resources. However, if ID Authentication latency is expected to be greater than 5seconds, the resource calculator needs to be updated with new test data within the “Resource used in Internal Test” section. * The oidc-ui-nginx connection churn observed in oidc-ui at high connection counts is tracked under [Issue #2583](https://github.com/mosip/esignet/issues/2583).The issue remains manageable as long as the resource calculator recommendation for oidc-ui pod count is followed.\ . ## **Conclusion** eSignet 2.0.0 is able to reliably process authentication at the rate of 50 transactions per second (TPS) for 10-hours. The Resource Calculator can be used to estimate the hardware requirements for higher TPS rate for larger populations. # Developer Guide Build, integrate, and enhance solutions with eSignet. This section is for anyone building with eSignet directly, rather than just running it: engineers standing up an instance, integrating a relying party, writing a custom authenticator or audit plugin, or tuning a deployment's configuration for their environment. If [Quickstart](https://claude.ai/cowork/quickstart.md) got you a working login on your own machine, this is where you go next to understand how eSignet is actually put together and how to shape it around your own system. The pages here are grouped by what you're trying to do, not just by topic — start with **Understand eSignet** if you're getting oriented, jump to **Configure Your Deployment** if you already know eSignet and need to tune a specific setting, or go straight to **Integrate With eSignet** if you're connecting a relying party or writing a plugin today. ### Understand eSignet Before configuring or integrating anything, it helps to know how the pieces fit together. * [**Architecture**](/home/esignet-2.0.0/develop/architecture) — how eSignet is composed under the hood: its major building blocks and how they interact with each other and with the systems around it. * [**Building Blocks**](/home/esignet-2.0.0/develop/architecture/components) — a closer look at the individual services that make up an eSignet deployment, and what each one is responsible for.

Cover image
Architecture.png	Architecture
eSignet Components.png	eSignet Building Blocks

### Configure Your Deployment Property-by-property reference for tuning eSignet to your own environment, once it's up and running.

Cover image
Configure eSignet.png	Configure eSignet

### Integrate With eSignet Everything you need to connect a relying party or extend eSignet with your own plugins.

Cover image
Integration GUides.png	Integration Guides - eSignet

### Look Up API Details Full set of APIs eSignet exposes, for whenever you need exact request and response details rather than a walkthrough.

Cover image
API Details.png	API

# Architecture eSignet is MOSIP's OpenID Connect (OIDC) / OAuth2 identity provider. It lets a relying party — a government or private-sector application — authenticate an end user against a national or foundational identity system and receive standard OIDC tokens and claims back, without the relying party ever having to handle the user's raw identity credentials itself. This page covers the shape of the system: what eSignet is made of, how a login actually flows through it end to end, and why it's built the way it is. For the full technical breakdown, module-by-module internals, the flow engine's YAML model, identity-provider implementations, security middleware, and the data model, see the Architecture Deep Dive *(Link to be added)*. ### What eSignet Is Made Of eSignet is built from two components, sitting on top of a shared, external protocol engine rather than implementing OIDC/OAuth2 from scratch: * **esignet-service** — the Go backend. It implements client management, consent management, and the MOSIP-specific pieces of the OIDC engine: identity-provider plugins, authentication flows, and screen/security configuration. * **oidc-ui** — the React single-page application that renders the login, OTP/biometric/KBI, and consent screens the end user actually interacts with. Both are built on [**ThunderID**,](https://github.com/thunder-id/thunderid) a generic external OIDC/OAuth engine that supplies the protocol machinery: token issuance, PKCE/DPoP/PAR, JWKS signing, the flow-execution runtime, and the login/consent UI rendering surface. esignet-service and oidc-ui are the MOSIP-specific configuration, provider implementations, and theming layered on top of that engine — which is what keeps the MOSIP-specific codebase small and lets the underlying protocol engine be upgraded independently of MOSIP's own code. | Component | Technology | Responsibility | | ---------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | esignet-service | Go, ThunderID engine | OIDC/OAuth protocol endpoints (via the engine), client and consent management APIs, MOSIP-specific auth-flow providers, identity-backend plugins | | oidc-ui | React, ThunderID SDK | Login, OTP/biometric/KBI, and consent screens, theming, CAPTCHA, error/offline handling | | PostgreSQL | RDBMS | OAuth client registry, consent records and history, key material | | Redis | In-memory store | Shared runtime store: transient flow/session state, client cache, flow-definition cache | | Identity backend | MOSIP IDA / Sunbird RC / Mock | The actual identity verification: OTP dispatch, KYC-auth, biometric/KBI matching | ### How a Login Actually Flows

A relying party never talks to eSignet's backend directly for the login itself — everything runs through the user's own browser, front-channel: 1. The relying party redirects the user's browser to eSignet's `/authorize` endpoint. 2. The browser loads oidc-ui's sign-in screen. 3. oidc-ui drives the actual login — OTP, password, biometric, or KBI, followed by consent — by calling esignet-service's flow and auth APIs. Behind the scenes, esignet-service checks client and consent records in PostgreSQL, keeps flow and session state in Redis, and verifies the user's identity against whichever identity backend is configured (MOSIP IDA, Sunbird RC, or a mock provider for testing). 4. Once the flow completes, esignet-service tells oidc-ui where to send the browser next. 5. oidc-ui redirects the browser onward. 6. The browser lands back on the relying party's own callback URL, carrying an authorization code. 7. The relying party exchanges that code for tokens directly with esignet-service — a back-channel call, authenticated with `private_key_jwt` and PKCE, that never passes through the browser. 8. The relying party calls `/userinfo` with its access token to retrieve the user's claims. ### Why It's Built This Way * **Engine-and-plugin separation.** Protocol mechanics — token issuance, JWKS, PKCE/DPoP/PAR, the flow-execution runtime, the UI-rendering surface — live in the shared, external ThunderID engine. esignet-service and oidc-ui contribute only MOSIP-specific providers, screen theming, and identity-backend integrations, keeping the MOSIP-specific codebase small and letting the protocol core evolve independently. * **Flow-as-configuration.** Authentication and consent journeys are declarative configuration on the backend, rendered generically by a single component on the frontend. New login methods or screen orders can be introduced without new app routes or backend endpoints. * **Swappable identity backend.** MOSIP IDA, Sunbird RC, and a mock provider all satisfy the same authenticator interface, selected by a single setting — so the same UI and flow layer runs unchanged against production identity systems or a local mock for testing. * **Defence in depth on the API surface.** Client-management APIs are protected independently by scope-checked bearer tokens and request-time validation, in addition to the OIDC/OAuth security the engine enforces on the protocol endpoints themselves. * **A shared runtime store that scales horizontally.** A single Redis-backed store (or in-memory, for local development) backs client lookups, flow-definition caching, and the engine's own session state, with Redis required for any multi-replica deployment. * **Externalized, per-deployment theming.** Language packs, themes, layouts, and images are treated as deployable configuration rather than being compiled into either component, so one build can serve multiple branded deployments. ### Want the Full Technical Breakdown? The Architecture Deep Dive *(Link to be added)*. covers esignet-service's internal module structure, the flow engine's YAML/state-machine model, each pluggable identity provider, oidc-ui's component structure and build pipeline, the data model, and reference tables for endpoints and environment configuration. # eSignet Building Blocks Connecting secure components for seamless identity verification. esignet-service is composed of a small composition root, the external ThunderID engine it plugs into, and a set of MOSIP-specific modules underneath. The diagram below is the map — each piece is explained briefly underneath it, with a link through to the full detail in the [Architecture Deep Dive](https://claude.ai/cowork/architecture-deep-dive.md) for anything you need to go deeper on.

### cmd/esignet (Composition Root) `main.go` is where everything gets wired together at startup: it opens the Postgres and Redis connections, builds the client-management HTTP handler, and passes roughly twenty functional options into the ThunderID engine to plug in every MOSIP-specific piece below. See [esignet-service (Backend)](https://claude.ai/cowork/architecture-deep-dive.md#2-esignet-service-backend) for the full startup sequence. ### ThunderID Engine (External Module) The generic, external engine esignet-service builds on. It supplies the flow runtime, token issuance, JWKS/JWT handling, consent orchestration, and the OIDC/OAuth HTTP endpoints themselves — the protocol machinery that every MOSIP-specific module below plugs into. See Architecture for how this fits into the bigger picture. Please refer the [Thunder ID](https://thunderid.dev/) to explore it in details. ### internal/engine — MOSIP Provider Implementations The following six pieces are esignet-service's implementations of the ThunderID engine's provider interfaces — the part of the codebase that's actually MOSIP-specific. * **actor\_provider** — bridges the engine's generic client concept to eSignet's own OAuth client model. See Client Management. * **consent\_provider** — bridges the engine's authorization flow to eSignet's consent records, deciding when a user needs to be re-prompted for consent. See Consent Management. * **flow\_provider** — loads and parses the declarative YAML flow definitions (`flow-esignet.yaml`, `otp-flow.yaml`) that drive every login and consent screen. See Authentication Flow Engine. * **idsystem\_factory** — selects which identity backend — MOSIP IDA, Sunbird RC, or the mock provider — handles authentication at startup, based on a single environment variable. See Pluggable Identity-System Providers. * **executors** — the custom flow-step logic (like the eSignet OTP executor) invoked as a flow moves from node to node. See Authentication Flow Engine. * **design / i18n / OU / resource / attestation / captcha providers** — the remaining engine interfaces: screen layout, translations, organizational-unit context, static assets, device attestation, and CAPTCHA validation. See the Module Breakdown table for where each lives in the codebase. ### Domain Services * **clientmgmt** — registers, updates, and looks up OAuth/OIDC relying-party clients, backed by Postgres. See Client Management for the full endpoint list. * **consentmgmt** — captures and stores user consent decisions, keeping an append-only audit trail alongside the current decision. See Consent Management. ### Shared Infrastructure * **security** — enforces JWT scope checks and request-time validation on the client-management API surface, backed by a polling JWKS cache. See Security. * **httpmiddleware** — applies access logging and correlation IDs to every request that comes through esignet-service. * **runtimestores** — the shared runtime store (in-memory or Redis) backing the client cache, the flow-definition cache, and the engine's own session and flow state. See Configuration & Runtime Store. # Configure eSignet Once an eSignet instance is up and running, tuning its behavior happens across a small, well-defined set of places — environment variables, a service YAML file, declarative UI assets, and per-client fields. All of it is documented directly in the eSignet repository, verified against the actual implementation, rather than duplicated here — configuration changes with the code, and a copy in this doc site would drift out of date. This page gives you the crux of each reference file and points you to the real one. ### Where Configuration Lives * **Environment variables and `esignet-service/data/deployment.yaml`** — most service-level settings, resolved as `env var > deployment.yaml > compiled-in default`. * **Declarative UI assets** (`/{flows,layouts,themes,i18n}/*.yaml`) — where ACR and login-ID behavior actually live, since neither is a `deployment.yaml` property. * **Per-client rows** in the `client_detail` table, set via the `/client-mgmt/*` API — claims, ACR values, redirect URIs, and other per-application settings. * **`oidc-ui`'s own runtime config** (`window._env_`, `theme/config.json`) — build-time and runtime settings for the login/consent UI itself. ### The Reference Files #### Configuration: The Full Property Reference The full list of environment variables and `deployment.yaml` settings for `esignet-service` and `oidc-ui`. Refer to it whenever you need an exact variable name, default value, or precedence rule. See the full reference here *(Link TBA)* for every property and detail. #### ACR: Which Authentication Methods a Client Can Request Defines the fixed `mosip:idp:acr:*` values a client's `authContextRefs` can request, the ACR-to-AMR mapping advertised in discovery, and how each ACR value maps to an actual login screen (OTP, password, biometrics, KBI) in the flow YAML. See the full reference here *(Link TBA)* for every property and detail. #### Claims: What Personal Data a Client Can Receive Defines the two-plane claim model — a per-client claims allow-list and a deployment-wide scope-to-claims mapping, with a claim released only if it appears in both — plus how ID token and userinfo delivery (signed vs. encrypted) is configured per client. See the full reference here *(Link TBA)* for every property and detail. #### Login ID: What Identifiers Users Can Log In With Defines the shipped login-ID types — UIN/VID, mobile number, email, and NRC ID, plus a fifth KBI-only identifier — and each one's validation rule. Configured directly in the flow YAML, not `deployment.yaml`. See the full reference here *(Link TBA)* for every property and detail. # .well-known eSignet publishes a small set of standard OIDC/OAuth discovery documents so a client can auto-configure itself — endpoint URLs, supported scopes and claims, signing algorithms, and more — rather than having those values hardcoded or configured by hand. For a new integration, these are usually the first thing to check. As with [Configure eSignet](/home/esignet-2.0.0/develop/configuration), the full technical detail for each lives in the repository; this page gives you the crux of each and links to the real file. ### 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. ### What Drives All Three * **`issuer`** (env `MOSIP_ESIGNET_HOST`) — becomes the `issuer` field in every document. * **`server.public_url`** (env `MOSIP_ESIGNET_BASE_URL`, falls back to `issuer`) — prefixed onto every endpoint path to build the full endpoint URLs. * **CORS** — gated by `allowed_origin_regex`; unset means no `Access-Control-Allow-Origin` header on these endpoints. All three are covered in [Configure eSignet](/home/esignet-2.0.0/develop/configuration#where-configuration-lives)'s basic settings. ### The Three Endpoints #### jwks.json — The Public Keys Clients Use to Verify Tokens `GET /oauth2/jwks` publishes the currently active signing keys; `/.well-known/jwks.json` is just an nginx alias to the same route. Key rotation is reflected here automatically. Refer here for the further details #### OAuth Authorization Server — Discovery for Plain OAuth Clients `GET /.well-known/oauth-authorization-server` lets a plain OAuth client discover the token and authorization endpoints, and which grant types, client auth methods, and security features (PAR, DPoP, PKCE) are supported. Refer here for the further details #### OpenID Provider Configuration — Discovery for OIDC Clients `GET /.well-known/openid-configuration` carries everything the OAuth Authorization Server document does, plus OIDC-only fields — the userinfo endpoint, supported scopes and claims, subject and signing/encryption algorithm types, and supported ACR values. Refer here for the further details # jwks.json ## 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 Please refer below for more details. ```json { "keys": [ { "kty": "RSA", "x5t#S256": "VS8O8lB_M4-ge70X-GmRwVSkRyXyNjnsR0D-jYYpd90", "e": "AQAB", "use": "sig", "kid": "ui7Nf7dSQ3q71wHDz1PauQXna2ruMk9va47kne3cahY", "x5c": [ "MIIDvTCCAqWgAwIBAgIITYyS7rMLxKQwDQYJKoZIhvcNAQELBQAwdzELMAkGA1UEBhMCSU4xCzAJBgNVBAgMAktBMRIwEAYDVQQHDAlCQU5HQUxPUkUxDTALBgNVBAoMBElJVEIxGjAYBgNVBAsMEU1PU0lQLVRFQ0gtQ0VOVEVSMRwwGgYDVQQDDBN3d3cubW9zaXAuaW8gKFJPT1QpMB4XDTIzMDQyODA3MDMyM1oXDTI2MDQyNzA3MDMyM1owfzELMAkGA1UEBhMCSU4xCzAJBgNVBAgMAktBMRIwEAYDVQQHDAlCQU5HQUxPUkUxDTALBgNVBAoMBElJVEIxGjAYBgNVBAsMEU1PU0lQLVRFQ0gtQ0VOVEVSMSQwIgYDVQQDDBt3d3cubW9zaXAuaW8gKE9JRENfU0VSVklDRSkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp/7weNfvZ8bza+SKwQZ2fM7dGFCRSc7mCLgfntWU7/5H7XxBc6ATwLfL8PZrbOywkagbmn2tvVjcdfKv3ZwkvhbMGjCS/fhkveu8y0sZt/gSecO6Sp+qdc22ASGL0xUCZ6xMGPLFOTtym28I9qq9qRj+NtJMy0tYN9uQcljkDePleZWseTOJ87KpVjtEMbrZUlG5GX/6JIvBZbkPx/L3N8//lGrJ/Cg/W6qXsN+Uka2Kp8Y0tT67Q8PqWwFYts3B26ve+E1GnVc6OpNB8j/Yw3fOcu0u1UOJbjldk8ytwwDrpxkD8ROTT/RmvjsAyDkeYRGoQ27Q/4nf0zoM22E2rAgMBAAGjRTBDMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFIG/x4ajYbA0WYY/pPLKlOpz+FB4MA4GA1UdDwEB/wQEAwIChDANBgkqhkiG9w0BAQsFAAOCAQEAdfVSOlxtL+cYwpcbK0x3bX3WVvXnznV/rkEh/Dh/CFld1dDteT2bOUAi8y74wmZ/ev+8wPiLozgU2vfgM4lIETm2cf/tm9Xm/fC027tQMxbB9e6p90xzRwZd3InDrLJ+USKLv6ywy/yKiZ33jW39J5AzFnx5WlSLfh2AVCmJwhxF2UZLenUOP0D7miQcqCQ89NMX4PKcZa0gPKqTfWv2TB8/SbmA5RJeXb7Mo/c3WSDh4P+sdzy3azm53vWigLNSY5emaMN+i80CrO4C+25EUpbqEbvtGSV0YU5ZtotUDSuF9PG9e77Prj8yFK657MDkXiLkcb0mnx2Fkiu7zmFiSA==" ], "exp": "2026-04-27T07:03:23.761Z", "n": "qf-8HjX72fG82vkisEGdnzO3RhQkUnO5gi4H57VlO_-R-18QXOgE8C3y_D2a2zssJGoG5p9rb1Y3HXyr92cJL4WzBowkv34ZL3rvMtLGbf4EnnDukqfqnXNtgEhi9MVAmesTBjyxTk7cptvCPaqvakY_jbSTMtLWDfbkHJY5A3j5XmVrHkzifOyqVY7RDG62VJRuRl_-iSLwWW5D8fy9zfP_5RqyfwoP1uql7DflJGtiqfGNLU-u0PD6lsBWLbNwdur3vhNRp1XOjqTQfI_2MN3znLtLtVDiW45XZPMrcMA66cZA_ETk0_0Zr47AMg5HmERqENu0P-J39M6DNthNqw" }, { "kty": "RSA", "x5t#S256": "r4kXB_agNjON1ffULvvQxMn7D1trZkl3_BSPPmxJ6t8", "e": "AQAB", "use": "sig", "kid": "hrLG-Zbo-KD4c1mJjSBlWbSO5LZYHsoCDl-Wy6yRfXI", "x5c": [ "MIIDrTCCApWgAwIBAgIIllIPUoxNBHswDQYJKoZIhvcNAQELBQAwcDELMAkGA1UEBhMCSU4xCzAJBgNVBAgMAktBMRIwEAYDVQQHDAlCQU5HQUxPUkUxDTALBgNVBAoMBElJVEIxGjAYBgNVBAsMEU1PU0lQLVRFQ0gtQ0VOVEVSMRUwEwYDVQQDDAx3d3cubW9zaXAuaW8wHhcNMjIwOTMwMDkzNDA4WhcNMjUwOTI5MDkzNDA4WjB2MQswCQYDVQQGEwJJTjELMAkGA1UECAwCS0ExEjAQBgNVBAcMCUJBTkdBTE9SRTENMAsGA1UECgwESUlUQjEgMB4GA1UECwwXTU9TSVAtVEVDSC1DRU5URVIgKElEQSkxFTATBgNVBAMMDHd3dy5tb3NpcC5pbzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzxiKwpUd66wQwsEHngQTx5mpqhAI58eo4plfeOLsutwuMrbktPXhsol6TXOKm3XcjNg/7dhF6HED3uU0YyC/CYhZ8SdThokQmPb3mE0G4gnOj94SgSV19xFZWsm4tQcXcca1i5Qzlrb8iotmuTUVcJfd5PgK1xxEgILtmbkHFMtDK42Fif0aDoOa5222/vFeFq9g3+lO7PPbysHRZl12FUtl4FvoB0dlqcJ2zpFl9lycb/8ru1S2+86UJ72yHFoFWo+tkR8Iw/lf0RvRtmc0KTY6l3813MT8uu2IDA//aPrK3CIR0dgyzNMK8e3vqrBXaxYQ8onWSBix2P/KRXlTMCAwEAAaNFMEMwEgYDVR0TAQH/BAgwBgEB/wIBATAdBgNVHQ4EFgQU93hx7ghwaK6OfoQzw5UdljX5NPowDgYDVR0PAQH/BAQDAgKEMA0GCSqGSIb3DQEBCwUAA4IBAQAjwztvdggtsx+cckVziuVl1M7bCBxJTBfmBr3bB7l3exfp5i4VsxQoxIKyPJq4ZUEylxPhO88cMr7p27PV8e4Z3q43j2Qz2ORo1CxIG/MaIIPuattRMm+5WvJTqf/T53Tt049N34aoNP6XqEF9OKoDfnOP/r1I3twX0nN4s6uurM7y6lHhhz94GM4SQ1+bbnSSs9mMNe29qYkEw46aGEJKWSQ96d43/PIJP9A2NQdf1ioeJmXHr1ZSmazf08dtI25tTDk+HwLI4x9K3elX91tItefp6q09RmRtPq7DwGvsXxVMTd6VoGHsSSeI61o37qvOe31+UldG/IpQuoxiFtER" ], "exp": "2025-09-29T09:34:08.732Z", "n": "3PGIrClR3rrBDCwQeeBBPHmamqEAjnx6jimV944uy63C4ytuS09eGyiXpNc4qbddyM2D_t2EXocQPe5TRjIL8JiFnxJ1OGiRCY9veYTQbiCc6P3hKBJXX3EVlaybi1BxdxxrWLlDOWtvyKi2a5NRVwl93k-ArXHESAgu2ZuQcUy0MrjYWJ_RoOg5rnbbb-8V4Wr2Df6U7s89vKwdFmXXYVS2XgW-gHR2WpwnbOkWX2XJxv_yu7VLb7zpQnvbIcWgVaj62RHwjD-V_RG9G2ZzQpNjqXfzXcxPy67YgMD_9o-srcIhHR2DLM0wrx7e-qsFdrFhDyidZIGLHY_8pFeVMw" } ] } ``` # OAuth Autorization Server Well-Known ## 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 ([RFC 8414](https://docs.esignet.io/home/esignet-2.0.0/develop/configuration/.well-known/pages/Tk3eiHfyOsvmzvqNZGRg#id-2.-supported-standards-and-rfcs)), 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. ## Oauth - Authorization server Configuration Please refer below for more details. ```json { "issuer": "https://esignet.es-dev1.mosip.net", "authorization_endpoint": "https://esignet.es-dev1.mosip.net/authorize", "token_endpoint": "https://esignet.es-dev1.mosip.net/v1/esignet/oauth/v2/token", "jwks_uri": "https://esignet.es-dev1.mosip.net/.well-known/jwks.json", "pushed_authorization_request_endpoint": "https://esignet.es-dev1.mosip.net/v1/esignet/oauth/par", "token_endpoint_auth_methods_supported": [ "private_key_jwt" ], "token_endpoint_auth_signing_alg_values_supported": [ "RS256", "PS256", "ES256" ], "scopes_supported": [ "openid", "profile", "email", "phone" ], "response_modes_supported": [ "query" ], "grant_types_supported": [ "authorization_code" ], "response_types_supported": [ "code" ], "authorization_response_iss_parameter_supported": true } ``` {% hint style="info" %} As per the FAPI 2.0 Security Profile, the OAuth Authorization Server now includes a new parameter: `authorization_response_iss_parameter_supported`. {% endhint %} ## Parameter Details and Descriptions * `issuer`: The base URL of the OpenID Connect provider. The value comes from the configuration property `mosip.esignet.discovery.issuer-id`. * `authorization_endpoint`: The URL where the authorization request can be initiated. * `token_endpoint`: The URL where the token exchange occurs to obtain an access token. * `token_endpoint_auth_methods_supported`: The supported authentication methods for the token endpoint. In this case, private\_key\_jwt is supported. * `token_endpoint_auth_signing_alg_values_supported`: The supported signing algorithms for the authentication of the token endpoint. In this case, RS256 (RSA with SHA-256) is supported. * `userinfo_endpoint`: The URL where additional user information can be requested. jwks\_uri: The URL where the JSON Web Key Set (JWKS) can be retrieved. The JWKS contains the public keys used to verify ID tokens and other JWTs. * `scopes_supported`: The supported scopes that can be requested during the authentication process. The value should come from the configuration property `mosip.esignet.supported.openid.scopes`. Common scopes include profile, email, and phone. * `response_types_supported`: The supported response types. In eSignet, we support only two values '`code`' and '`code token`', for the code flow and the code token flow. * `ui_locales_supported`: The supported user interface locales for localization. The value comes from the configuration property `mosip.esignet.supported.ui.locales`.\ Examples: en (English), fr (French), and ar (Arabic). * `authorization_response_iss_parameter_supported`: Indicates whether the authorization server includes the `iss` (issuer) parameter in the authorization response. In eSignet, this value is always set to `true` by default. # OpenID Provider Configuration Well-Known ## **Overview:** eSignet's `openid-configuration` well-known endpoint provides metadata in a standardized JSON format, following the [OpenID Connect specification](https://docs.esignet.io/home/esignet-2.0.0/develop/configuration/.well-known/pages/Tk3eiHfyOsvmzvqNZGRg#id-2.-supported-standards-and-rfcs). This endpoint exposes information such as authentication endpoints, supported flows, and capabilities, enabling relying parties to dynamically discover and integrate with eSignet securely. ## Open ID Provider Well Known Configuration Please refer below for more details. ```json { "issuer": "https://esignet.collab.mosip.net", "authorization_endpoint": "https://esignet.collab.mosip.net/authorize", "token_endpoint": "https://esignet.collab.mosip.net/v1/esignet/oauth/v2/token", "userinfo_endpoint": "https://esignet.collab.mosip.net/v1/esignet/oidc/userinfo", "jwks_uri": "https://esignet.collab.mosip.net/v1/esignet/oauth/.well-known/jwks.json", "scopes_supported": [ "profile", "email", "phone" ], "response_types_supported": [ "code" ], "acr_values_supported": [ "mosip:idp:acr:password", "mosip:idp:acr:generated-code", "mosip:idp:acr:linked-wallet", "mosip:idp:acr:biometrics" ], "userinfo_signing_alg_values_supported": [ "RS256" ], "userinfo_encryption_alg_values_supported": [ "RSAXXXXX" ], "response_modes_supported": [ "query" ], "token_endpoint_auth_methods_supported": [ "private_key_jwt" ], "token_endpoint_auth_signing_alg_values_supported": [ "RS256" ], "id_token_signing_alg_values_supported": [ "RS256" ], "claim_types_supported": [ "normal" ], "claims_supported": [ "name", "address", "gender", "birthdate", "picture", "email", "phone_number" ], "claims_locales_supported": [ "en" ], "display_values_supported": [ "page", "popup", "touch", "wap" ], "ui_locales_supported": [ "en" ], "claims_in_verified_claims_supported" : [ "name", "address", "gender", "birthdate", "picture", "email", "phone_number" ] } ``` ## Parameter Details and Descriptions * `issuer`: The base URL or identifier of the OpenID Connect provider. The value comes from the configuration property mosip.esignet.discovery.issuer-id. * `authorization_endpoint`: The URL where the authorization request can be initiated. * `token_endpoint`: The URL where the token exchange occurs to obtain an access token. * `userinfo_endpoint`: The URL where additional user information can be requested. * `introspection_endpoint`: The URL where the token introspection can be performed to validate token information. * `jwks_uri`: The URL where the JSON Web Key Set (JWKS) can be retrieved. The JWKS contains the public keys used to verify ID tokens and other JWTs. * `scopes_supported`: The supported scopes that can be requested during the authentication process. The value comes from the configuration property `mosip.esignet.supported.openid.scopes`. * `response_types_supported`: The supported response types for the authorization request. The value comes from the configuration property mosip.esignet.supported.response.types. * `response_modes_supported`: The supported response modes for the authorization request. The value is \["query"], indicating that only the query response mode is supported. * `token_endpoint_auth_methods_supported`: The supported authentication methods for the token endpoint. The value is based on the configuration property `mosip.esignet.supported.client.auth.methods`. * `token_endpoint_auth_signing_alg_values_supported`: The supported signing algorithms for the authentication of the token endpoint. In this case, the value is \["RS256"], indicating that only the RS256 (RSA with SHA-256) algorithm is supported. * `userinfo_signing_alg_values_supported`: The supported signing algorithms for the user information endpoint. The value is \["RS256"], indicating that only the RS256 algorithm is supported for signing user information. * `userinfo_encryption_alg_values_supported`: The supported encryption algorithms for the user information endpoint. The value is \["RSAXXXXX"], suggesting that a specific encryption algorithm (represented as "RSAXXXXX") is supported. The actual algorithm should be provided. * `userinfo_encryption_enc_values_supported`: The supported encryption methods for the user information endpoint. The value is \["A128GCM"], indicating that only the A128GCM encryption method is supported. * `id_token_signing_alg_values_supported`: The supported signing algorithms for ID tokens. The value is \["RS256"], indicating that only the RS256 algorithm is supported for signing ID tokens. * `claim_types_supported`: The supported claim types. The value is \["normal"], suggesting that only normal claims are supported. * `claims_parameter_supported`: Specifies whether the claims parameter is supported in authorization requests. The value is true, indicating that the claims parameter is supported. * `display_values_supported`: The supported display values for the user interface. The value is based on the configuration property mosip.esignet.supported.ui.displays. * `subject_types_supported`: The supported subject types. The value is \["pairwise"], indicating that only pairwise subject types are supported. * `claims_supported`: The supported claims that can be included in ID tokens and user info responses. The value is a list of claim names, such as "`iss`", "`sub`", "`acr`", "`name`", etc. * `acr_values_supported`: The supported authentication context class references (ACR). The value is an empty object {}, indicating that no specific ACR values are supported. * `request_parameter_supported`: Specifies whether the request parameter is supported in authorization requests. The value is false, indicating that the request parameter is not supported. * `ui_locales_supported`: The supported user interface locales. The value is an empty object {}, suggesting that no specific UI locales are supported. * `claims_in_verified_claims_supported:` Supported verified claim names. # Integration Guides - eSignet Explore seamless eSignet integration with guides on authentication, digital wallets, and more. ## Integration Guides eSignet is built as a core engine with a small number of deliberately pluggable extension points, rather than one monolithic system you have to fork to adapt. That separation — covered in [Architecture](/home/esignet-2.0.0/develop/architecture) — is what makes it possible to connect eSignet to a different identity backend, change how it logs activity, or let your own application use it for login, without touching the engine itself. This section assumes you already know what eSignet is and how its pieces fit together. It's for when you're ready to extend or connect to eSignet for your own use case, and it points you to the exact extension point and reference implementation to start from. There are three ways to integrate with eSignet: ### Connect eSignet to Your Identity System eSignet doesn't hardcode how a person's identity gets verified — that's handled by a pluggable `authnprovider` interface. If you want eSignet to authenticate people against your own identity system (a national ID registry, a credential store, an existing user directory), you implement this interface rather than modifying eSignet itself, the fastest way to see a real, working `authnprovider` before you write your own.

Cover image
Authnprovider.png	Authn Provider

### Add or Customize Audit Logging Every authentication and consent event eSignet handles can be captured for audit purposes — who logged in, when, and what was consented to. This is also implemented as a plugin, so you can route audit events wherever your organization needs them (a SIEM, a compliance data store, a log pipeline) instead of being limited to whatever eSignet logs by default.

Cover image
Audit Plugin.png	Audit Plugin

### Connect Your Application to eSignet If you're building an application — a website, a mobile app, a backend service — that should let people log in with eSignet, this is your path. It covers registering your application as a relying party, exchanging the result of a login for tokens, and retrieving the user's shared details.

Cover image
Relying Party Integration.png	Relying Party

### Which One Do I Need? | If you want to... | Go to | | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Plug eSignet into your own identity backend (ID registry, credential store, user directory) | [Authnprovider](/home/esignet-2.0.0/develop/integration/authenticator) | | Capture or export logs of authentication and consent activity | [Audit Plugin](/home/esignet-2.0.0/develop/integration/audit) | | Let users of your application log in with eSignet | [Relying Party Integration](/home/esignet-2.0.0/develop/integration/relying-party) | # Authn Provider ### What an Authn Provider Does An Authn Provider is the bridge between eSignet and an identity system. eSignet itself never talks to your identity system directly — it delegates that entirely to the Authn Provider, and limits its own responsibility to the parts that are the same for every deployment: OAuth2/OIDC/FAPI protocol compliance, consent capture and enforcement, and token issuance (ID token, access token) plus JWKS publishing. The Authn Provider, in turn, is responsible for: * Authenticating the user against the identity system * Resolving a stable, provider-specific identifier for the authenticated user * Fetching verified user attributes (KYC data) for whichever claims the user consented to share * Returning all of that to eSignet in an agreed structure Because the boundary between the two is a Go interface rather than a network protocol, the identity system behind an Authn Provider can be anything — a single database table for local testing, or a full national identity registry. eSignet only depends on the interface being implemented correctly, never on how the identity system itself is built. This is what replaces the Java version's separate "Authenticator Plugin" concept — same role in the integration, now expressed as a single Go interface. ### Who Should Implement This Any organization — public or private — that wants to connect its own identity system to eSignet implements this interface. ### How It Works The engine makes, at most, four calls into an Authn Provider during a login, always in this order — `SendOTP` only fires for OTP-based factors, and each `Get*` call only fires when the corresponding token from `Authenticate` is non-nil: ``` SendOTP → Authenticate → GetEntityReference → GetAttributes (send-otp screen) (kyc-auth: verify (resolve/cache the (kyc-exchange: fetch the entered OTP/ "sub" claim for only the consented password/biometric) consent + token claims, after consent) issuance) ``` `Authenticate` can return either an opaque token (for `GetEntityReference` or `GetAttributes` to resolve later) or the resolved value directly — if you return the value directly, the engine skips the corresponding `Get*` call entirely. *TBA - Sequence Diagram* ### The Interface A provider is a Go package implementing `shared.ConsolidatedAuthnProvider`, which embeds the engine-level `providers.AuthnProviderInterface` and adds two eSignet-specific methods: ```go type ConsolidatedAuthnProvider interface { providers.AuthnProviderInterface SendOTP(ctx context.Context, identifiers map[string]interface{}, metadata *providers.AuthnMetadata) (*SendOTPResult, *common.ServiceError) GetSigningCertificates(ctx context.Context) ([]CertificateData, *common.ServiceError) } ``` Including the embedded interface, a full implementation has eight methods in total. Three of them (`InitiateAuthentication`, `InitiateEnrollment`, `Enroll`) exist only for the engine's built-in passkey/WebAuthn executor, which none of eSignet's shipped flows currently use — you can safely stub these out unless you add a flow that exercises that path. The full method signatures, supporting types, and error-handling conventions are in the deep dive. ### A Reference Implementation * **Mock** — talks to a mock identity system over HTTP; supports OTP, password, PIN, biometrics, and arbitrary KBI, with no cryptographic envelope on the payload. It's what Quickstart's Local Setup runs against, so it's the easiest place to see a real, working Authn Provider without standing up a production identity system. `internal/engine/mock` * **MOSIP IDA** and **SunbirdRC** — the other two reference implementations, adding request encryption/signing and registry-search behavior respectively. Full detail in the deep dive. `internal/engine/mosip` · `internal/engine/sunbird` ### How to Register a New Provider Providers are compiled into the binary at build time — there's no dynamic loading, no `.so` files, no registry. To add one: 1. Create a new package under `esignet-service/internal/engine//`, following the existing file layout (`authenticator.go`, `config.go`, `init.go`, `model.go`). 2. Implement `shared.ConsolidatedAuthnProvider` on a type in `authenticator.go`. 3. Add an `Init(...)` function that also returns an audit sink — your own, or `shared.NewNoopAuditor()` if you don't have one (see [Audit Plugin](/home/esignet-2.0.0/develop/integration/audit)). 4. Add a `case "":` branch to the provider factory's switch statement. 5. Rebuild. Which provider actually runs at startup is chosen by the `MOSIP_ESIGNET_AUTHN_PROVIDER` environment variable (default `mock`). ### Further Details The Authn Provider Deep Dive *(Link TBA)* has the full interface and supporting-type definitions, the error-handling conventions, the exact `identifiers`/`credentials` field split per auth factor, configuration conventions, and the full reference-implementation comparison table for Mock, MOSIP IDA, and SunbirdRC. # Audit Plugin ### What the Audit Plugin Does As eSignet's flow engine runs an authentication or consent flow, it emits a stream of lifecycle events — a flow starting, a step completing or failing, a flow finishing. The audit plugin (called an *observability provider* internally) receives every one of those events and decides what happens to them next: forward them to your organization's SIEM, write them to a compliance data store, or simply log them locally. eSignet doesn't generate these events from application code you'd need to instrument yourself — they come directly from the flow engine, so a correctly wired audit plugin captures a complete, consistent trail of authentication activity by default. ### How It's Wired There's no separate registration step for the audit plugin. It's returned alongside your Authn Provider from the same `Init(...)` function for your identity backend (see [Authn Provider](/home/esignet-2.0.0/develop/integration/authenticator)): ```go func Init(...) (shared.ConsolidatedAuthnProvider, providers.ObservabilityProvider, error) ``` Whatever you return as the second value becomes the engine's audit sink for the lifetime of the process. If you're building a new identity backend integration and don't need custom audit logging, you can return eSignet's built-in no-op logger instead of writing your own: ```go return authnProvider, shared.NewNoopAuditor(), nil ``` ### The Interface A provider implements two methods: ```go type ObservabilityProvider interface { // PublishEvent publishes an event to the observability system. PublishEvent(ctx context.Context, evt *Event) // IsEnabled returns true if observability is enabled and operational. IsEnabled() bool } ``` `PublishEvent` is called once per lifecycle event; `IsEnabled` lets the engine skip building an event entirely when observability isn't active. Each `Event` carries a trace ID (for correlating related events), a type such as `FLOW_STARTED` or `FLOW_COMPLETED`, a status, and a set of event-specific fields — the full list of event types and fields is in the deep dive. ### A Reference Implementations * **No-Op / Logging Auditor *****(Link TBA)*** — `shared.NewNoopAuditor()`: no external dependency, just logs each event's fields through the application logger; always enabled. A complete, minimal starting point to copy from. `noop_auditor.go` * **MOSIP Audit-Manager Auditor *****(Link TBA)*** — `mosip.NewAuditor(...)`: maps each event onto a MOSIP audit-manager record and posts it asynchronously over HTTP. Full field mapping and config are in the deep dive. `auditor.go` ### How to Implement Your Own 1. Define an `Event → ` mapping for whatever fields your audit system needs. You don't have to use every field on `Event`, and you can enrich your record with values pulled out of `Data`. 2. Implement `PublishEvent` as fire-and-forget — a goroutine, or a buffered channel to a background worker — so a slow or unavailable audit sink never blocks or fails the authentication flow that generated the event. Derive the goroutine's context from `context.Background()`, not the request context, for the same reason, but carry the trace ID forward for correlated logging. 3. Implement `IsEnabled` to report whether your sink is currently configured and reachable; return `true` unconditionally if that distinction doesn't apply to your implementation. 4. Return your type from your provider package's `Init(...)` function as the second return value. ### Further Details The [Audit Plugin Deep Dive](https://claude.ai/cowork/audit-plugin-deep-dive.md) has the full event payload and field reference, the complete list of event types the flow engine emits, and the full MOSIP reference implementation. # Relying Party 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:

Cover image	Cover image
	Discovery Endpoints.png	Integration Options and Discovery Endpoints
	Pre-Requisites.png	Onboarding Pre-requisites
Principles	Onboarding Form.png	Onboarding Form
	Integration and Development.png	Development and Integration with eSignet

# Integration Options and Discovery Endpoints Reference information to help relying parties select the appropriate ID system and proceed with integration. eSignet supports integration with both [**Mock ID**](#id-1.-mock-id-integration) and [**MOSIP ID**](#id-2.-mosip-id-integration) 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. {% hint style="info" %} Note: The two options listed here — **Mock ID** and **MOSIP ID** — are provided **only for testing and proof-of-concept (POC)** purposes within the [**MOSIP Collab environment**](https://collab.mosip.net/). {% endhint %} {% hint style="info" %} In real-world deployments, eSignet can be configured to work with **national ID systems or other identity providers** as per the country’s implementation and integration requirements. {% endhint %}

Understanding Discovery Endpoints

A **discovery endpoint** is a standard part of the **OpenID Connect (OIDC)** specification.\ It provides a **metadata document** (commonly located at `/.well-known/openid-configuration`) that allows relying parties (RPs) to automatically discover key configuration details for integrating with the identity provider (IdP). **Each discovery document mainly includes:** 1. Authorization, Token, and UserInfo endpoint URLs 2. Supported scopes, claims, and grant types 3. Public keys for token signature validation 4. Supported authentication methods and response types **For more details refer** [**here**](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata)**.**

Why Discovery Endpoints Matter for Relying Parties

For developers and integrators, discovery endpoints simplify setup by: 1. **Automating configuration:** No need to hardcode or manually maintain endpoint URLs. 2. **Ensuring consistency:** RPs always use up-to-date endpoint details published by eSignet. 3. **Reducing errors:** Helps avoid misconfigurations in authorization or token flows.

### **Discovery Endpoints for Mock ID and MOSIP ID Integration** #### **1. Mock ID Integration** Use this option to integrate with a **Mock ID system**, which is designed to **simulate a real ID system** for **testing and development purposes**. Please refer [here](https://esignet-mock.collab.mosip.net/) for the Mock ID discovery endpoints.
**Purpose:** 1. Enables developers to test authentication flows safely. 2. Returns claims and responses similar to production with mock user data. 3. Ideal for validating OIDC client configuration and redirect flows. #### **2. MOSIP ID Integration** Use this option if you want to use a **MOSIP ID** for your **use case demonstrations or integration testing**. Please refer [here](https://esignet-mosipid.collab.mosip.net/) for the MOSIP ID discovery endpoints.
**Purpose:** 1. Connects to the live MOSIP identity system for real user authentication. 2. Returns genuine user claims and ID tokens after successful login. 3. Suitable for end-to-end verification before deployment. To get started with integration. and onboard your client to eSignet please refer to this [page](/home/esignet-2.0.0/develop/integration/relying-party/relying-party-onboarding) # Onboarding Pre-requisites ## Onboarding Pre-requisites Before you request registration through the [Onboarding Form](/home/esignet-2.0.0/develop/integration/relying-party/integrate-with-e-signet), there are a handful of things worth having ready on your side — your development stack, a way to handle the tokens eSignet returns, a key pair, and a callback endpoint that knows what to do with the result. Getting these in place first means the registration step itself is just filling in details you already have, rather than something that blocks you halfway through. ### 1. Prepare Your Development Environment Pick the technology stack you'll build your integration in — PHP, Python, Java, Node, Kotlin, Swift, or whatever your team already works in — and choose an OpenID Connect client library for it. *(Refer to the library list here) \* ### 2. Plan for UserInfo JWT Handling eSignet returns its UserInfo response as a signed, or signed-and-encrypted, JWT rather than plain JSON. Choose a JWT library or plugin compatible with your stack that can decrypt, verify, and parse it before your application reads the claims inside. ### 3. Generate and Manage Cryptographic Keys eSignet supports only confidential clients, authenticated using the `private_key_jwt` method — your application proves its identity with a JWT it signs using its own private key, rather than a shared secret sent over the wire. That means a key pair is something you'll need before you can register at all: * Generate a key pair, and store the **private key** securely — password-protected, hardened storage such as a vault or HSM, never checked into code or shared over email. * Share the **public key** with eSignet in JWK (JSON Web Key) format. This is the key eSignet uses to verify the digital signature on your authorization requests, and to encrypt the `user_info` response it sends back to you. * Use **different key pairs for development, test, and production** — never reuse a key pair across environments. * **Rotate keys every 6–12 months**, or immediately if a key is ever compromised. * The generated key pair must default to **"signing"** usage. > **Note:** Only RSA key format is currently supported; additional formats are planned. #### What Is JWK Format? JWK (JSON Web Key) is a JSON data structure representing a set of public keys, using either the Elliptic Curve or RSA family of algorithms. It's the format eSignet expects when you share your public key during registration. [Learn more about JWK](https://claude.ai/cowork/TODO-link). #### Converting a Public Key to JWK If you already have a public key as a `.PEM` file, here's the quickest way to convert it to JWK for testing: 1. Visit this [site](https://russelldavies.github.io/jwk-creator/). 2. Select **Public Key Use** as **Signing**. 3. Select **Algorithm** as **RS256**. 4. Select **Key ID** as an alpha-numeric random string. 5. Paste your public key's PEM-encoded content into **PEM encoded key**. 6. Click **Convert**. ### 4. Design Your Callback API Your callback API is the endpoint eSignet redirects the user's browser back to once authentication finishes — successfully or not. It's worth designing this endpoint's behavior deliberately, since it's the last hop before control returns to your application: * The endpoint should render a user interface promptly, so the user isn't left staring at a blank screen while your backend processes the result. * On **successful authentication**, the user is redirected back with an **authorization code**. * On **failure**, the user is redirected without a code, but with an **error code** instead. * Your application should handle both cases explicitly before letting the user proceed any further. The exact URL patterns you're allowed to register for this endpoint are covered in the [Onboarding Form](/home/esignet-2.0.0/develop/integration/relying-party/integrate-with-e-signet), once you're ready to submit them. *** # Onboarding Form Once you've worked through [Onboarding Pre-requisites](/home/esignet-2.0.0/develop/integration/relying-party/relying-party-onboarding) and have your keys and callback endpoint ready, you can request registration as a relying party by completing the [onboarding form](https://docs.google.com/forms/d/e/1FAIpQLSerko7k1wiy1sjgfRSfRU5Bjkb7cKc0t2z0FmKt6mSLBqJGXQ/viewform). This is what lets us set up your application as a recognized OIDC client, and get you a seamless integration on the [MOSIP collab environment.](https://collab.mosip.net/) ### What You'll Provide | Field | What It's For | | -------------------------------- | ------------------------------------------------------------------------- | | Public Key | Verifies your requests and lets eSignet encrypt data sent back to you | | Client / Application Name | Shown to users on eSignet's authentication and consent screens | | Claims Required | The user attributes your application needs, and whether each is mandatory | | Application & Organization Logos | Shown to users on eSignet's authentication and consent screens | | Callback URLs (Redirect URIs) | Where eSignet sends the user back after authentication | The sections below walk through each of these in more detail. ### 1. Public Key Provide the same JWK-format public key you generated in [Onboarding Pre-requisites](/home/esignet-2.0.0/develop/integration/relying-party/relying-party-onboarding). This is what establishes trust between your application and eSignet and lets you use `private_key_jwt` authentication. ### 2. Client / Application Name This name is displayed to users on eSignet's authentication and consent screens — it's how your users will recognize your application while completing login. ### 3. Claims (Attributes) Required Specify the list of user attributes your application needs. For each claim: * Clearly indicate whether it's **mandatory** or **optional**. * Claim values and formats can be referenced from eSignet's `.well-known` configuration endpoint. ### 4. Application Branding Submit your **application logo** and **organization logo**. Both appear on the eSignet authentication and consent pages during login, so users can recognize who they're signing in to. ### 5. Callback URLs (Redirect URIs) Specify the redirect URIs eSignet should use to send authentication responses back to your application. **Supported for development and QA:** | Pattern | Notes | | ---------------------------------------- | ---------------------------------- | | `http://localhost:/*` | | | `http://127.0.0.1:/*` | | | `http://:/*` | | | `my.phone.app://oauth/*` | For mobile apps using deep linking | Wildcard patterns (`*`) are acceptable for development, but **should be avoided in production** due to the security risk of an overly broad match. **Unsupported patterns:** | Pattern | Why | | ----------------- | ---------------------- | | `\\*` | Invalid wildcard usage | | `http*` | Invalid wildcard usage | | `https://*` | Invalid wildcard usage | | `https://domain*` | Invalid wildcard usage | | `residentapp://*` | Invalid wildcard usage | > **Note:** Redirect URIs can be either fully qualified URLs or partial URLs with wildcards. Wildcards give you flexibility to use multiple URLs by changing only certain paths or query parameters, without updating your client configuration every time. However, the redirect URI used in the authorize API call and the token API call must be a fully qualified URL, and must be identical in both calls — if they differ, you'll get an "invalid assertion" error. If the redirect URI doesn't match any of your registered URIs at all, the request fails with an "invalid redirect URI" error instead. ### 6. Await Your Client ID Once you've submitted the required information, eSignet processes your registration and issues a **Client ID**. This ID uniquely identifies your application in every authentication request from here on. *** Once you receive your eSignet credentials at the email address provided on the form, head to [Development and Integration with eSignet](/home/esignet-2.0.0/develop/integration/relying-party/development-and-integration-with-esignet) to complete your integration. # Development and Integration with eSignet ## Development and Integration with eSignet This page explains what it actually takes to connect an application to eSignet as a relying party — what has to be built, who builds it (frontend team, backend team, or nobody, since eSignet handles it), and how the pieces fit together. It's meant to give a clear picture of the integration effort at a glance, whether you're the one writing the code or just need to know what to plan for. For exact parameters, error codes, and the full API specification, see the [Development and Integration Deep Dive](https://claude.ai/cowork/development-and-integration-deep-dive.md). > **Migrating from the Java-based eSignet?** Several endpoint paths and behaviors have changed in the Go version — see [Changes from the Java Implementation](https://claude.ai/cowork/development-and-integration-deep-dive.md#changes-from-the-java-implementation) in the Deep Dive. ### Before You Start You should already have a registered `client_id` from [Onboarding Form](https://claude.ai/cowork/onboarding-form.md), a private key on your backend for `private_key_jwt` authentication, a registered redirect URI, and a decided set of scopes and claims — all covered in [Onboarding Pre-requisites](https://claude.ai/cowork/onboarding-prerequisites.md). Everything below assumes that's done. ### The Integration at a Glance Connecting to eSignet comes down to six steps. Only three of them require your team to write code — eSignet handles the rest. | Step | Who Builds It | What It Involves | | ----------------------------------------------------- | ---------------------------------------- | --------------------------------------------------------------------------- | | 1. Add a "Sign in with eSignet" button | Relying Party | A button that sends the user to eSignet, using eSignet's ready-made package | | 2. User logs in and gives consent | **eSignet - Standard step of OIDC flow** | Happens entirely on eSignet's own screens | | 3. Receive the user back in your app | Relying Party | Read the result eSignet sends back and hand it to your backend | | 4. Exchange that result for access tokens | Relying Party | Your backend calls eSignet, proving its identity with a private key | | 5. Confirm the tokens are genuine and start a session | Relying Party | Verify the tokens, then keep the user signed in securely | | 6. (Optional) Retrieve the user's shared details | Relying Party | Call eSignet again if your application needs the user's profile data | The sections below walk through each step in a bit more detail. ### Step 1: Add a "Sign in with eSignet" Button Add a sign-in button or link to your login page that sends the user to eSignet. eSignet provides a ready-made package, `@mosip/sign-in-with-esignet`, that renders this button for you with the recommended branding — your frontend team doesn't need to hand-build the button or the redirect logic behind it. If your application requires eSignet's stricter security options (PAR and/or DPoP), the same package handles those automatically; your team only needs to turn them on. ### Step 2: User Logs In and Gives Consent Once the user clicks the button, eSignet takes over completely: it shows its own login screen (OTP, biometrics, wallet, or whichever method is enabled), and — if your application is requesting personal details — a consent screen where the user chooses what to share. Your application has no screens to design or build here, and isn't involved again until the user is sent back to you. ### Step 3: Receive the User Back in Your App After the user finishes on eSignet's screens, they land back on a web address you registered in advance, carrying either a success result or a failure result. Your team needs to handle both cases: on success, pass the result along to your backend for the next step; on failure, show the user a reasonable message instead of a raw error. ### Step 4: Exchange That Result for Access Tokens Your backend takes the result from Step 3 and calls eSignet directly to receive access tokens — this is the point at which your application actually gets proof of who the user is. This call must happen on your server, never in the browser or a mobile app, because it requires a private key that must never be exposed to end users. ### Step 5: Confirm the Tokens Are Genuine and Start a Session Before trusting the tokens from Step 4, your backend checks that they're genuine and haven't been tampered with, and confirms the request matches one your application actually made. Once confirmed, your backend keeps the user signed in through its own secure session — the tokens themselves should stay on the server, not be handed to the browser. ### Step 6: Retrieve the User's Shared Details If your application needs the user's personal details (for example, identity verification data), your backend makes one more call to eSignet using the access token from Step 4 to retrieve exactly what the user consented to share. Please refer the link here *(Link to be added)* to deep dive into the development details. # API This page is the entry point for eSignet's full API surface — every endpoint eSignet exposes, with exact request and response schemas, parameters, and status codes. If you're looking for a conceptual walkthrough of connecting a relying party instead, start with Development and Integration with eSignet; come back here once you need the precise contract for a specific call. ### OpenAPI Specification The authoritative, machine-readable definition of every endpoint eSignet exposes — request and response schemas, required parameters, authentication requirements, and error responses — maintained directly in the eSignet repository alongside the code it describes. Refer to it whenever you need the exact contract for a specific endpoint. [eSignet OpenAPI Specification](https://github.com/mosip/esignet/blob/master/docs/esignet-openapi.yaml) ### Postman Collection A ready-to-import Postman collection covering eSignet's API surface, useful for exploring endpoints interactively or trying calls against a running instance without writing any client code first. [eSignet Postman Collection](https://github.com/mosip/esignet/tree/master/postman-collection) {% hint style="info" %} **Note:** Both resources are versioned alongside the eSignet codebase. Use the version of each that matches the eSignet release you're integrating against. {% endhint %} # Interoperability Seamlessly integrate with MOSIP, Inji, OpenCRVS and DHIS2 for enhanced digital services. 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:

		Cover image
	MOSIP	MOSIP.png
	Broken link	Inji.png
	OpenCRVS	OpenCRVS.png
	DHIS2	DHIS2 Card.png

# MOSIP **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 [MOSIP](https://docs.mosip.io/1.2.0/integrations/e-signet). To try it out yourself in our sandbox [Collab](https://collab.mosip.net/) environment, click [here ](/home/esignet-2.0.0/local-deployment/try-it-out)to access the eSignet Try It Out section. # OpenCRVS 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 [OpenCRVS](https://docs.mosip.io/1.2.0/interoperability/integrations/mosip-crvs-integration). # DHIS2 [**DHIS2** (District Health Information Software 2)](https://dhis2.org/) is an open-source, web-based platform developed at the University of Oslo, deployed in more than 80 countries for health, logistics, and education data management. This document provides an overview of how eSignet integrates with DHIS2 powered ANC (Ante Natal Care) ecosystem across three portals: the [**PHM-Assisted DHIS2 Registration Portal**](https://mosip.integration.dhis2.org/dhis-web-login/#/), the **Doctor-Assisted VOG Portal**, and the **Self-Service Health Portal**. ## Purpose This document outlines the integration of eSignet (a digital identity verification system) with DHIS2 healthcare portals to streamline maternal health record management across three user-facing applications. **eSignet's Role**: eSignet serves as the primary identity verification and authentication backbone, enabling secure National ID-based authentication across all portals. It verifies patient identity, fetches verified demographic details from the identity system, and manages user consent for data access—ensuring that every interaction within the healthcare ecosystem is tied to a verified identity. ### Use Cases This use case outlines an end-to-end **ANC (Ante Natal Care)** patient journey, integrating identity verification with healthcare systems using eSignet. The solution is implemented across three distinct portals, each serving a specific role in the patient lifecycle: * **PHM (Public Health Midwife)-Assisted DHIS2 Registration Portal**: For initial patient registration and new PHN issuance * **Doctor-Assisted VOG Portal**: For accessing and updating patient medical records * **Self-Service Health Portal**: For patients to view their own medical records and appointments Across all portals, eSignet-based authentication using National ID is used to ensure secure access and accurate identification of the patient. The system also integrates with backend systems such as: * **FHIR (Fast Healthcare Interoperability Resources)** server for storing and exchanging health data across multiple portals - only this point we can keep ### eSignet-DHIS2 ANC Use Case Flow This diagram shows the end-to-end ANC journey across registration, consultation, and self-service portals, with eSignet-based identity verification and consent.

eSignet-DHIS2 ANC use case flow — **Figure:** eSignet-DHIS2 ANC Use Case Flow

## Portal Workflows and User Journeys ### 1. PHM-Assisted DHIS2 Registration Portal **Purpose**: To register the pregnant mother in the health registry system and issue a Patient Health Number (PHN). **User Journey**: * The pregnant mother visits the PHM center. * The Public Health Midwife (PHM) accesses the DHIS2 Registration Portal and logs in using National ID. * The PHM initiates the registration process by selecting the **New Registration** option. **Identity Verification using eSignet**: * The PHM enters the patient’s National ID. * eSignet triggers an OTP to the mobile number linked with the National ID. * The patient provides the OTP and is authenticated successfully. * The PHM obtains explicit consent from the patient and submits it on her behalf. **Fetch userinfo**: * Upon successful authentication, demographic details of patient such as **name, date of birth, and address** are fetched from the identity system **via eSignet** and auto-populated in the registration form. * The PHM completes the remaining health-related information manually and submits the form. **PHN Handling**: * **If the patient already has a PHN**: * The patient registration form includes a field for **Existing PHN**. * If the patient has a PHN, the Public Health Midwife (PHM) enters it in this field to fetch demographic details from the PHN system. * The PHM then performs a **manual verification** by comparing the data retrieved from the PHN system with the demographic details obtained from the National ID system via eSignet. * If the information matches, the PHM proceeds with the registration. * **If the patient does not have a PHN**: * The PHM completes the registration. * A new PHN is generated and assigned to the patient. * The captured data is then pushed to the FHIR server. ### 2. Doctor-Assisted VOG Portal **Purpose**: To allow doctors to access and review patient medical history for diagnosis and treatment. **User Journey**: * The pregnant mother visits the maternal health (MH) center. * The doctor logs into the VOG portal using their National ID. * The doctor initiates a search by entering the patient’s PHN and selects **Search Record**. * The patient’s health records are fetched from the FHIR server and become accessible to the doctor * The doctor reviews the medical history, updates relevant information, and provides treatment. * All updates made by the doctor are pushed to the FHIR server. ### 3. Self-Service Health Portal **Purpose**: To enable patients to access their own ANC records and upcoming appointments. **User Journey**: * The pregnant mother accesses the DHIS2 Self-Service Health Portal. **Identity Verification using eSignet**: * The patient enters her National ID. * An OTP is sent to the registered mobile number. * The patient enters the OTP and is authenticated successfully. **Post Authentication**: * The portal displays: * Patient medical records * ANC visit history * Upcoming appointments ## How does eSignet integrate * eSignet is used as the primary authentication mechanism during patient registration in the DHIS2 patient registration portal. * Upon successful authentication using the National ID, the fetched user information is used to pre-populate PII fields in the registration form. * eSignet is also used in the Patient Self-Service Portal, allowing patients to log in and access their medical records. * eSignet manages user consent for data access and sharing across systems. ## Benefits * **Secure Identity Verification**: Ensures that all access to health records is tied to a verified National ID. * **Improved Data Accuracy**: Reduces manual data entry errors through auto-population from the identity system. * **Streamlined Patient Journey**: Enables seamless transitions across registration, treatment, and self-service access. * **Interoperability**: Integration with FHIR server allows standardized data exchange across systems. * **Reduced Duplication**: PHN verification prevents duplicate patient records. * **Enhanced Accessibility**: Patients can access their health data independently through the self-service portal. ## High-Level Architecture Refer to a [comprehensive article](https://developers.dhis2.org/blog/2026/02/mosip-integration-demo/) detailing the architecture and outlining this integration. This article illustrates the overall system architecture, including: * Integration between DHIS2 portals and eSignet * Interaction with the identity system * Data flow to and from the PHN system * Storage and exchange of health records via the FHIR server ## Integration Demo A recording of the demonstration conducted for this use case is available below: {% embed url="" %} ### Abbreviations | Abbreviation | Full Form | | ------------ | ------------------------------------------ | | ANC | Ante Natal Care | | FHIR | Fast Healthcare Interoperability Resources | | MH | Maternal Health | | NeHR | National e-Health Registry | | PHM | Public Health Midwife | | PHN | Patient Health Number | {% hint style="success" %} **Want to see this in action first?** eSignet is already running in [MOSIP's collaboration](https://collab.mosip.net/) environment - a shared sandbox you can use to experience this without installing or configuring anything yourself. Try this use use case yourself by following the [end user guide](/home/esignet-2.0.0/local-deployment/try-it-out/end-user-guide/patient-registration-portal). {% endhint %} # Deploy Effortlessly deploy and configure eSignet with comprehensive guides, architecture insights, and mock environments. This section is about taking eSignet beyond your own machine — deploying and configuring it for a real environment, where it needs to be sized, secured, and set up to match your organization's own requirements. eSignet supports two deployment paths: brought up locally with Docker Compose for evaluation and development, or deployed on-premise with full flexibility to configure it around your infrastructure and use case. If you're looking to run eSignet locally to try it out or develop against it, see [Quickstart's Local Setup](/home/esignet-2.0.0/local-deployment/local-setup) instead — that's the Docker Compose–based path for a single developer's machine, and it's covered there rather than here. This section is for planning and carrying out an actual deployment. ### In This Section * [**Deployment Architecture**](/home/esignet-2.0.0/build-and-deploy/deployment-arch) — how eSignet's components are typically laid out in a real deployment, and the infrastructure and sizing considerations that come with it. *(page to be added)* * [**On-Prem Deployment Guide**](/home/esignet-2.0.0/build-and-deploy/on-prem-deployment-guide) — step-by-step guidance for deploying and configuring eSignet on your own infrastructure, tailored to your organization's requirements. *(page to be added)* ### Which Codebase to Deploy The latest stable, deployable codebase is always on the `master` branch of the [eSignet repository](https://github.com/mosip/esignet). Feature development and bug fixes happen on separate feature or development branches first and are merged into `master` once ready — so `master` is the branch to deploy from, not a feature branch. {% hint style="info" icon="github" %} Note: For deployment and testing, it is recommended to use either the master branch or the official released tags. {% endhint %} # Deployment Architecture ### Architecture Overview The below diagram illustrates the deployment architecture of the **eSignet service** with secure, scalable, and monitored infrastructure components.

## Firewall A firewall is a network security device that monitors and filters incoming and outgoing network traffic based on an organization's established security policies. It protects against outside cyberattacks by shielding the network from malicious or unnecessary network traffic. All incoming traffic from the internet is routed through the firewall. ## Load Balancer A load balancer is a network device or service that evenly distributes incoming network traffic across multiple servers or resources. It operates based on predetermined rules or algorithms and helps optimize the use of these resources. The primary purpose of a load balancer is to ensure that no single server becomes overwhelmed with traffic, thereby improving performance, availability, and reliability for users accessing a particular service or application. Additionally, we use it in the following cases: 1. SSL termination 2. Proxy pass 3. TCP communication 4. UDP communication 5. Reverse Proxy ## IAM Wireguard is used as a trusted network extension to provide secure access to control and monitoring panels for operational team members, making sure that restricted APIs are not publically accessible. The internal IAM system is used to manage access control for the operation team and client management API calls from client management systems ## Deployment Layers Deployment layers can be sectioned into the below three sections. ### Application Cluster eSignet application services are deployed in the form of pods in the Kubernetes cluster. **OIDC UI** This pod will expose all the UI component files that are requested from the browser once the eSignet portal is accessed. **eSignet Service** This is the actual backend service that exposes all the RESTful API endpoints, which includes all endpoints related to OIDC, VCI, UI, and client management. This service has a plugin-based mechanism to integrate with the ID system for actual user verification. It also connects to the below cluster for various needs. **PostgreSQL DB Cluster** All the data related to client policies, consent, etc. are stored in this cluster. It should be a highly available cluster with necessary replication levels using solutions like Citus. **Redis Cache Cluster** All transactional caching needs are taken care of by the Redis cluster. **HSM Cluster** This cluster provides the necessary security to the cryptographic keys used in the application. Access to this cluster should be allowed only from a few selected nodes to control access and improve security. {% hint style="info" %} **Note*****:*** Below additional Kubernetes-compatible tools are also configured into the Kubernetes cluster to take care of security and routing needs. {% endhint %} **Ingress Gateway** An ingress Gateway is a load balancer operating at the edge of the mesh that receives incoming HTTP/TCP connections. It configures exposed ports, protocols, etc. **Istio Service Mesh** This is a service mesh used as an ingress gateway in the k8 cluster. Istio is used to manage the request routing in service-to-service communication. It can also help with service discovery, load balancing, failure recovery, metrics, and monitoring. **Docker Registry** Local docker registry is used to improve restart timings of containers where the images are configured to be pulled every time to the running node. It also helps with reducing the usage of internal bandwidth since images are caching within the setup. **Kubernetes Secrets** Kubernetes Secret is used for storing and managing sensitive information like DB passwords, keycloak secrets, etc.. that is required by application pods. It gives us more control over how sensitive information is used and reduces the risk of accidental exposure. ### Control Panel Tools in the Control Panel will be used by operations team members to manage the deployment and maintain the uptime in the Kubernetes cluster **Rancher** Rancher is a complete stack for managing containers. It addresses the operational and security challenges of managing multiple Kubernetes clusters while providing DevOps teams with integrated tools for running containerized workloads. Rancher is integrated with IAM for the authentication of users. **Helm Chart** Helm chart is a package manager for Kubernetes-based Objects. For each module, multiple related components are grouped and their deployment scripts are packaged as hosted helm charts, so each module can be installed and upgraded independently. ### Monitoring Panel Monitoring Panel will be used by operations team members to observe the health of various application pods and debug specific issues using application logs. Application logs and metrics are collected by Fluentbit and dumped into Elastic Search and Prometheus respectively. The application log data stored in elastic search is configured as reports using Kibana and can be used for searching logs when debugging application issues. The metric data stored in Prometheus are configured as charts in Grafana to continuously monitor the health of the environment and containers. Explicit notifications can be configured as alerts when the metrics reach a particular threshold. # On Prem Deployment Guide This guide walks through deploying and configuring eSignet on a Kubernetes-based infrastructure. It assumes you already have Kubernetes infrastructure in place and the tools needed to integrate eSignet with an identity system (MOSIP, Sunbird RC, or a mock system for testing). ## eSignet Deployment and Integration Scenarios eSignet supports a range of use cases — secure digital signatures for online transactions, national ID authentication, e-government services, and identity verification for financial, healthcare, or educational platforms. This guide focuses specifically on deploying eSignet and integrating it with an identity system; the deployment flow and integration steps vary depending on which one you choose. {% hint style="info" %} The scenario is chosen during [Deploy eSignet Services](#deploy-esignet-services), where you're asked which plugin to use for identity management. {% endhint %} How eSignet can work with different ID systems: * **eSignet + Mock** — deploys eSignet with a mock identity provider, letting you simulate authentication and authorization flows without integrating a real ID system. Ideal for development, testing, and demonstrations, with no external dependencies or onboarding steps required. * **eSignet + MOSIP** — integrates eSignet with an existing (or planned) MOSIP identity system, using MOSIP as the identity provider for authentication and digital-signature workflows based on MOSIP-managed identities. * **eSignet + Sunbird RC** — integrates eSignet with an existing Sunbird RC identity system, using Sunbird RC for identity management and enabling secure authentication and digital-signature processes on top of it. ## Prerequisites The prerequisites are split into three parts: * **Developer Workstation Profile** — tools and utilities to install on your own machine to create/manage the Kubernetes cluster and deploy eSignet on it. * **Development Environment Setup** — the specific configuration your local environment needs to work effectively with eSignet. * **Cloud Environment Profile** — the hardware/software/network requirements for the Kubernetes-based server infrastructure eSignet will run on. ### Developer Workstation Profile #### Operating Systems eSignet can be deployed from a workstation running any of the following, though this guide assumes a Linux machine running Ubuntu 22.04 LTS: * **Linux** (Ubuntu 22.04 LTS — recommended for production deployments) * **Windows** * **macOS (OSX)** #### Development Environment Setup Install the following on the local machine you'll use to run `kubectl`, connect to the Kubernetes cluster, and manage the deployment: * [Ansible](https://docs.ansible.com/ansible/latest/installation_guide/installation_distros.html) — version > 2.12.4 * Command line utilities: * [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) — version 2.12.4 or higher * [helm](https://helm.sh/docs/intro/install/) — any client version above 3.0.0, plus these repos: ```sh helm repo add bitnami https://charts.bitnami.com/bitnami helm repo add mosip https://mosip.github.io/mosip-helm ``` * [rke](https://rancher.com/docs/rke/latest/en/installation/) — version [1.3.10](https://github.com/rancher/rke/releases/tag/v1.3.10) * [Istioctl](https://istio.io/latest/docs/setup/getting-started/#download) — version 1.15.0 * A WireGuard client — see the Wireguard client setup guide *(link to be added)*. ### Cloud Environment Profile A Kubernetes-based server infrastructure is required to deploy eSignet. It can either already have the identity system (such as MOSIP) deployed on it, or you can deploy eSignet alongside the identity system. ## Deploy eSignet The subsections below cover deploying eSignet with or without an existing identity system (such as MOSIP). {% stepper %} {% step %} ### Get access to the deployment environment Ask your system administrator for access to the Kubernetes cluster and namespaces where you'll deploy eSignet. This typically includes: * Access to the Kubernetes cluster (a kubeconfig file). * Access to the relevant namespaces (e.g. `mosip`, `esignet`). * Permission to create resources in those namespaces. * Access to any required secrets or configuration files. {% endstep %} {% step %} ### Request the following from your DevOps team * A kubeconfig file for the cluster (this also carries namespace permissions). * Confirmation that MOSIP is running and healthy. * `kubectl` access, set up as follows: ```sh # Set the KUBECONFIG environment variable export KUBECONFIG=/path/to/your/kubeconfig # OR copy it to the default location cp kubeconfig ~/.kube/config # Confirm you're operating in the correct cluster context kubectl config get-contexts kubectl config use-context ``` {% hint style="info" %} The `KUBECONFIG` variable set here is used throughout the rest of the installation, as you move between directories to run the install scripts. {% endhint %} {% endstep %} {% step %} ### Verify the existing ID system If you're deploying eSignet alongside an existing identity system (such as MOSIP), validate that it's healthy before proceeding. This guide uses MOSIP as its example: ```sh # Test cluster connectivity kubectl get nodes # Check MOSIP deployment status kubectl get pods -n kubectl get svc -n # Verify key MOSIP services are running kubectl get pods -n mosip | grep -E "(ida|pms|kernel|postgres|keycloak|redis)" ``` {% endstep %} {% step %} ### Clone the eSignet repository ```sh git clone https://github.com/mosip/esignet.git cd esignet/deploy ``` {% hint style="info" %} Before cloning, make sure `kubectl` is configured for your target cluster and that you have the necessary namespace permissions. Once connectivity is verified, run the deployment scripts below (`install-prereq.sh`, `initialise-prereq.sh`, `install.sh`) from your local machine. {% endhint %} {% endstep %} {% endstepper %} ## Deploy eSignet Services Once the steps above are complete, proceed with the deployment scripts below. ### Install Prerequisites Installing prerequisites gets the environment ready for eSignet's core services and plugins. {% hint style="info" %} If you already have some of these dependencies — for example Postgres or Keycloak from an existing MOSIP setup — you can skip that component's prompt and move to the next one when running the script. {% endhint %} The install script prompts you for each component and configuration in turn; some prompts are chained, so answering one may trigger another. Review the prompts below and decide your answers in advance for a smoother run. #### What Gets Installed * **PostgreSQL** — database backend for eSignet services. * **Keycloak** — identity and access management service. * **Redis** — in-memory data store for caching and session management. * **HSM** — software-based key management, or a Hardware Security Module, for secure key storage and cryptographic operations. * **apiaccesscontrol** — service for API access management and authorization. * **ConfigMaps and Secrets** — configuration values, domain details, and sensitive credentials (e.g. the `esignet-global` configmap, `keycloak-client-secrets`). * **Supporting scripts** — `install-prereq.sh` and `initialise-prereq.sh`. {% stepper %} {% step %} #### Prepare `esignet-global` Prepare the `esignet-global` configmap, which holds environment-specific configuration for eSignet. Copy the sample configmap file: ```sh cp esignet-global-cm.yaml.sample esignet-global-cm.yaml ``` Edit `esignet-global-cm.yaml`: * Update domain names and other configuration values to match your deployment environment. * Set up Google reCAPTCHA v2 by generating site and secret keys for your domain at the [reCAPTCHA admin console](https://www.google.com/recaptcha/about/), and add them to the configmap. * If you're using an external IAM, copy the required secrets and create a Kubernetes secret named `keycloak-client-secrets` in the `esignet` namespace. {% hint style="info" %} The `esignet-global-cm.yaml` file typically holds domain names, API endpoints, and other environment-specific parameters. The `esignet` namespace is also created here if it doesn't already exist. {% endhint %} {% endstep %} {% step %} #### Run `install-prereq.sh` Run the script from the `deploy` folder to install PostgreSQL, Keycloak, Redis, and API access control. You'll be prompted for configuration details based on your environment. ```sh ./install-prereq.sh ``` **apiaccesscontrol** — you'll be asked whether to access-control eSignet's client management APIs (answer `n` if you don't need this; press Enter for the default, `y`): * `n` — internal APIs run without access control. * `y` — Keycloak is initialized for API access control. You're then asked for the IAM server URL (press Enter to install the default Keycloak instance), and, if you choose to initialize Keycloak, an admin username and password. **Redis** — you'll be asked whether to deploy Redis in the `redis` namespace (answer `n` if you already have a Redis instance; press Enter for the default, `y`): * `y` — installs Redis for you. * `n` — you're then asked a follow-up, "Do you want to configure Redis?" Answer `y` to supply the hostname, port, and password for your existing Redis server below, or `n` to skip supplying them here. * `redishostname` — the hostname for your Redis server. * `redisport` — the port number for your Redis server. * `redispassword` — the password for your Redis server. {% hint style="info" %} If you're deploying Redis in the same cluster, you don't need to provide a hostname, port, or password — only supply these if Redis is running on a separate cluster. {% endhint %} PostgreSQL and captcha validation are auto-deployed by this script with no interactive prompt. Prerequisite installation is complete once these prompts are answered. {% endstep %} {% step %} #### Initialize prerequisites Run the script from the `deploy` folder to initialize the eSignet database and Keycloak. You'll be prompted for configuration details such as database credentials, IAM scope, and service endpoints — update the relevant values files before running it. ```sh ./initialise-prereq.sh ``` If the eSignet database isn't already present at the Postgres server URL you provided, the script creates and initializes it. {% hint style="warning" %} If you customize the Postgres init values, you must keep a second file in sync, or the eSignet service will fail to connect. {% endhint %} * Update the Postgres init values at `postgres/init_values.yaml`. If you're creating a new database, set the name, user, and connection details as needed: ```yaml dbName: mosip_esignet # customize, e.g. mosip_esignet02 dbUser: esignetuser # customize, e.g. esignetuser02 host: "postgres-postgresql.postgres" port: 5432 ``` * If the default database name works for you, no edits are needed — proceed with the script as-is. * **Important:** If you edit `init_values.yaml` (e.g. changing `dbName` or `dbUser`), also update the matching values in `postgres-config.yaml` in the same `postgres` directory. Otherwise eSignet won't be able to connect to the correct database or user. {% endstep %} {% endstepper %} ### eSignet Services Installation Once prerequisites are installed and initialized, install the eSignet services themselves. Before running the install script, decide which plugin — which identity system — you want to integrate with: 1. **eSignet Mock Plugin** — simulates an identity provider for testing and development; no real identity system required. 2. **MOSIP Identity Plugin** — integrates eSignet with an existing MOSIP identity system. 3. **Sunbird RC Plugin** — connects eSignet to an existing Sunbird RC identity registry. #### Compatibility matrix | Identity System | eSignet Version | Plugin Version | Status | Integration Guide | | --------------- | --------------- | -------------- | ------ | --------------------------------------------------------------------------------------- | | MOSIP 1.2.x | 1.7.0 | 1.3.x | Stable | [MOSIP Integration](https://docs.mosip.io/1.2.0/interoperability/integrations/e-signet) | | MOSIP 1.1.x | 1.5.x | 1.2.x | Legacy | Legacy MOSIP | | Sunbird RC 2.x | 1.7.0 | 1.0.x | Stable | Sunbird Integration | | Custom API | 1.7.0 | Custom | Custom | [Plugin Development](broken://pages/1aa0f8fdc037c33a84204a6aa52eec4ae59b02ab) | To install eSignet with plugins, navigate to the `esignet` folder inside `deploy` and run: ```sh ./install.sh ``` {% hint style="info" %} A top-level wrapper is also available — `./install-esignet.sh`, run directly from the `deploy` folder. It prompts once for "with plugins" vs. "without plugins," moves into the `esignet` folder for you, and always installs the OIDC UI in the same run. This is a shortcut over the step-by-step process below, not a different mechanism. {% endhint %} The script asks you to choose a plugin: 1. `esignet-mock-plugin` 2. `mosip-identity-plugin` 3. `sunbird-rc-plugin` Answer with the option number — `1`, `2`, or `3`. #### `esignet-mock-plugin` Choosing the mock plugin needs no further chained prompts — installation completes automatically, giving you eSignet with a mock identity provider integration, primarily for testing and demonstration: simulating authentication and authorization flows without connecting to a real identity system. During installation, the script also prompts you to configure the key manager. You can accept the defaults or provide custom values. {% hint style="info" %} PKCS#12 is the file-based key management option (as opposed to SoftHSM or an external hardware HSM) — your signing keys live in a keystore file mounted into the pod, rather than in a separate HSM service. It's the simplest option to get running, since it needs no extra service to deploy: a default 100 MB volume and a working keystore at `/home/mosip/config/local.p12` are provisioned automatically. At the `KEYMANAGER_PKCS12_FILE_PATH` prompt, press Enter to accept this default; only provide a custom path if you already have your own PKCS#12 keystore file to mount instead. {% endhint %} * **Volume size**: 100 MB by default. * **Configuration path**: `/home/mosip/config`, via the MOSIP ConfigMap. * **PKCS#12 file**: defaults to `/home/mosip/config/local.p12`, or provide a custom path when prompted: ```sh Provide KEYMANAGER_PKCS12_FILE_PATH [default: /home/mosip/config/local.p12]: ``` **Key points:** * The mock plugin provides sample endpoints and data that mimic real-world identity operations. * Use the mock relying party and OIDC UI to test the complete eSignet flow. * No onboarding with MOSIP or Sunbird RC is required. * Not recommended for production, but useful for development, testing, and API validation. After installation, test eSignet using the mock relying party tools and the provided Postman collections. #### `mosip-identity-plugin` Choosing the MOSIP identity plugin prompts you for the following, each with a default in-cluster URL you can override: 1. `mosip.esignet.authenticator.ida.cert-url` 2. `mosip.esignet.authenticator.ida.kyc-auth-url` 3. `mosip.esignet.authenticator.ida.kyc-exchange-url` 4. `mosip.esignet.authenticator.ida.send-otp-url` 5. `mosip.esignet.binder.ida.key-binding-url` 6. `mosip.esignet.authenticator.ida.get-certificates-url` 7. `mosip.esignet.authenticator.ida.auth-token-url` 8. `mosip.esignet.authenticator.ida.audit-manager-url` 9. `mosip.esignet.authenticator.ida.otp-channels` (defaults to `email,phone`) {% hint style="info" %} We recommend accepting the script's defaults for all nine prompts above rather than overriding them individually. Each of these URLs is itself built from an underlying `*.domain` property (e.g. `mosip.esignet.ida.auth.domain`, `mosip.esignet.authmanager.domain`) that falls back to an in-cluster short hostname such as `http://ida-auth.ida` or `http://authmanager.kernel`. There's a simpler way to point all nine at your real MOSIP IDA environment at once, rather than overriding each individually. Once the plugin is deployed, add a **new** environment variable to the eSignet deployment. `MOSIP_API_INTERNAL_HOST` doesn't exist in the chart's `values.yaml` by default (its `extraEnvVars` block ships fully commented out), so this is an addition rather than a value to change: ```yaml extraEnvVars: | - name: MOSIP_API_INTERNAL_HOST value: https://api-internal.sandbox.xyz.net # replace with your environment's real internal API host ``` Setting this one property overrides every `*.domain` fallback at once — `ida.auth.domain`, `ida.otp.domain`, `ida.internal.domain`, `authmanager.domain`, and so on — replacing all the in-cluster short hostnames with your real host in a single change. After the deployment picks this up, update the `idaclientsecret` field (`MOSIP_IDA_CLIENT_SECRET`, sourced from the `mosip_ida_client_secret` key in the `keycloak-client-secrets` Kubernetes secret) with the real value for your environment. {% endhint %} **HSM** After the IDA URL prompts, the same install script asks which HSM backend the plugin should use for key management. If you've deployed eSignet before, note that this is a change: HSM selection used to happen earlier, as part of `install-prereq.sh`; it now happens here, as part of installing the plugin itself. You're offered two choices: 1. **SoftHSM** — software-based, installed via Helm. This is the only path the script currently supports. 2. **Hardware HSM** — choosing this exits the script immediately with a message to contact the platform team. There's no option to connect an existing hardware HSM through this prompt; that has to be arranged separately. #### `sunbird-rc-plugin` Choosing the Sunbird RC plugin prompts you for: 1. `mosip.esignet.sunbird-rc.registry-get-url` — the URL for the Sunbird registry `get` API. **HSM** The same install script then asks which HSM backend to use for key management, with the same two choices and the same caveat as above: **SoftHSM** is the only supported path today, and **Hardware HSM** exits the script with a message to contact the platform team. Once these decisions are made, eSignet installation should complete successfully. If an error occurs, delete the existing chart and retry, or resolve the underlying issue first. #### OIDC UI Installation Once eSignet installation completes, you're prompted for the OIDC UI deployment: 1. `esignetthemes` — choose `blue` or `orange` for the default eSignet theme (press Enter for the default), or provide a URL for a custom theme. 2. `defaultlang` — the default language for eSignet (press Enter for `en`). 3. `idprovidername` — the name to display in place of "eSignet" on the login page and elsewhere. {% hint style="info" %} If you use the `./install-esignet.sh` wrapper mentioned earlier, OIDC UI installation isn't a separate phase you trigger — it's bundled into the same run automatically, alongside whichever plugin module you chose. {% endhint %} ### Multi-Plugin Deployment (Same Cluster) {% hint style="info" %} If you're deploying a single plugin in a cluster, none of this section applies. {% endhint %} Deploying multiple plugins in the same cluster requires a few manual changes to the deployment scripts: * Create a new database for the plugin from the `db_scripts` directory: * Update `dbName`, `dbUser`, `host`, and `port` in `init_values.yaml` (in `db_scripts`) for the plugin being deployed. * Run `./init_db.sh` from the `db_scripts` directory to create the database. * Update the namespace and `mosip-esignet-host` domain in `esignet-global.yaml` for the plugin being deployed. * Update the namespace, eSignet service name, and SoftHSM name in the `esignet` directory's `install.sh` script for the plugin being deployed. * Update the namespace and service name in the `oidc-ui` directory's `install.sh` script for the plugin being deployed. * If these values change for the MOSIP identity plugin, update the namespace and eSignet service name in the `partner-onboarder` install script too. #### Example: Sunbird plugin deployment * Namespace: `esignet-sunbird` * `mosip-esignet-host`: `esignet-sunbird.sandbox.mosip.net` * eSignet service name: `esignet-sunbird` * OIDC service name: `oidc-ui-sunbird` ### Onboarding If you installed eSignet with the MOSIP identity plugin, MISP onboarding must be completed next. If you're using the mock plugin, no MISP onboarding is required — skip this step. #### Onboarding eSignet as a MISP Partner (MOSIP ID Plugin) The partner-onboarder exchanges certificates for the eSignet MISP partner. It wraps the `mosip/partner-onboarder` Helm chart and interactively collects configuration before running the onboarding job. **This is a manual step you run yourself** — it isn't triggered automatically by `install-esignet.sh` or any other script. **Prerequisites** * **Report storage** (the install script asks which one you want): * **S3** — have ready: S3 host, region, bucket name, access key, secret key. * **NFS** — on your NFS server: ```sh mkdir -p /srv/nfs/mosip//onboarder/ chmod 777 /srv/nfs/mosip//onboarder ``` Add to `/etc/exports`: ``` /srv/nfs/mosip//onboarder *(rw,sync,no_root_squash,no_all_squash,insecure,subtree_check) ``` Then apply and restart: ```sh sudo exportfs -rav sudo systemctl restart nfs-kernel-server ``` Have the NFS server IP and path ready for the script prompt. * **Keycloak** (choose one): * **External** — have ready: Keycloak URL, admin username/password, PMS domain (e.g. `api-internal.sandbox.mosip.net`), and PMS client secret. * **Internal** — the script automatically copies `keycloak-env-vars`, `keycloak`, and `keycloak-client-secrets` from the `keycloak` namespace into `esignet`. This requires `../deploy/copy_cm_func.sh` to exist and the source configmaps/secrets to already be present in the `keycloak` namespace. * **SSL/domain status** — you'll be asked whether you have a public domain with a valid SSL certificate. Answering "no" enables insecure mode for endpoints without valid certificates. **`values.yaml` — key fields to set** ```yaml onboarding: modules: - name: esignet enabled: true propertiesOverride: esignet: POLICY_NAME: mpolicy-default-esignet POLICY_GROUP_NAME: mpolicygroup-default-esignet PARTNER_KC_USERNAME: mpartner-default-esignet PARTNER_ORGANIZATION_NAME: IIITB PARTNER_TYPE: Misp_Partner PARTNER_DOMAIN: MISP PARTNER_MANAGER_USERNAME: esignet-kc-mockusername PARTNER_MANAGER_PASSWORD: esignet-kc-mockpassword EXTERNAL_URL: https://esignet.sandbox.mosip.net ``` Replace the partner identity fields (`PARTNER_ORGANIZATION_NAME`, `PARTNER_TYPE`, `PARTNER_DOMAIN`, `PARTNER_MANAGER_USERNAME`/`PASSWORD`) and `EXTERNAL_URL` with values for your environment. For S3 or NFS report storage, uncomment the corresponding block in `values.yaml`. **Run it** ```sh ./install.sh [kubeconfig] ``` You'll be walked through, in order: 1. Public domain/SSL validation (answer `Y` or `n` — an empty answer fails with `'flag' was not provided`). 2. `values.yaml` confirmation. 3. Report storage selection (complete S3 **or** complete NFS details, not a partial mix of both). 4. Keycloak setup (external credentials, or internal auto-copy). Under the hood, the script creates the `esignet` namespace, disables Istio sidecar injection, updates Helm repos, installs the `mosip/partner-onboarder` chart, waits for the job to complete, restarts the `esignet` deployment, and cleans up temporary configmaps. **Troubleshooting** | Issue | Resolution | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | `KER-ATH-401: Authentication Failed` | Provide the correct `mosip-deployment-client` secret key. | | Certificate validity error | Ask an admin to add a grace period in the configuration. | | `ida-cred` certificate upload error | Expected on a second run — safe to ignore if the certificate already exists. | | `'flag' was not provided` | Answer the SSL prompt with a non-empty `Y` or `n`. | | Script exits after the storage prompt | Provide complete S3 **or** complete NFS details, not a partial mix. | | `copy_cm_func.sh` errors | Verify the script exists at `../deploy/` and the source configmaps/secrets exist in the `keycloak` namespace. | Reference: [`partner-onboarder`](https://github.com/mosip/esignet/tree/release-2.0.x/partner-onboarder) on the `release-2.0.x` branch. #### Onboarding Relying Parties The onboarder script described here works against PMS (Partner Management Service) **1.3.0-beta5 and above**. If your deployment runs an earlier PMS version, use [Manually Onboarding Relying Parties for PMS 1.2.2.x and Below](#manually-onboarding-relying-parties-for-pms-122x-and-below) instead. See [Onboarding Pre-requisites](broken://pages/0ccd7887c0a848daf4bd719806adb034f51ce0b8) for detailed onboarding steps. {% hint style="info" %} **Prerequisites:** make sure the mock relying party services are deployed and running before starting. Deploying the mock relying party portal is optional if you already have your own relying party portal — see [mosip/esignet-mock-services](https://github.com/mosip/esignet-mock-services) for the default implementation. Download and import `eSignet-with-mock.postman_environment.json` and `eSignet.postman_collection.json` from the `postman-collection` folder in the repo. {% endhint %} {% stepper %} {% step %} ### Fetch the Authentication Token Go to "OIDC Client Mgmt" → "Mock" → "Get Auth Token." Update `client_secret` (from `keycloak-client-secrets`) and `iam_url` (the Keycloak URL, from the `keycloak-host` → `keycloak-external-url` configmap entry) in the request body. {% endstep %} {% step %} ### Fetch the CSRF Token Go to "OIDC Client Mgmt" → "Mock" → "Get CSRF Token," updating the `url` field as needed. {% endstep %} {% step %} ### Update the Request Fields for OIDC Client Creation Before running "Create OIDC Client," update `url`, `logo-uri`, `redirect-uri`, `client-name`, and `client-id`. {% endstep %} {% step %} ### Update the Client ID in the Deployment Once the client is created and activated, update `clientId` in the mock-relying-party-ui deployment. {% endstep %} {% step %} ### Update the Client Private Key Retrieve `client-private-key` from the eSignet-with-mock Postman environment, base64-encode it, and update it in the mock-relying-party service secret. {% endstep %} {% endstepper %} {% hint style="info" %} This workaround is based on a walkthrough with the DevOps team rather than official onboarder documentation — validate it end-to-end in your own environment before relying on it. Revisit it once PMS 1.2.2.x support is no longer needed. {% endhint %} #### Manually Onboarding Relying Parties for PMS 1.2.2.x and Below On PMS (Partner Management Service) version 1.2.2.x or earlier, the standard onboarder run won't complete cleanly on its own: the `create-oidc-client` step fails with an HTTP 404, because it calls a PMS API path that doesn't exist yet on 1.2.2.x. Every other step succeeds normally — only OIDC client creation needs to be finished manually, against the older PMS path. {% stepper %} {% step %} ### Run the onboarder as normal Expect it to fail specifically at the `create-oidc-client` step with a 404 — on PMS 1.2.2.x and below, this is expected, not a sign that something else went wrong. {% endstep %} {% step %} ### Retrieve the run's report or logs These contain the failed request: * From MinIO: `s3/onboarder/reports/MOCK_RP_OIDC//mock-rp-oidc.html` * Or from the onboarder job's pod logs, if you don't have MinIO access. {% endstep %} {% step %} ### Extract the request body and the auth token Extract the request body and the auth token used in the failed `create-oidc-client` call, from that report or log. {% endstep %} {% step %} ### Manually resend the request Manually resend the same request — same body, same token — to the legacy PMS endpoint instead: ``` POST /v1/partnermanager/oauth/client ``` {% endstep %} {% step %} ### Update the mock relying party UI Point the mock relying party UI at the new client ID returned by that manual call: ```sh kubectl set env deploy/mock-relying-party-ui CLIENT_ID= ``` {% endstep %} {% endstepper %} ### Verify Deployment Check the status of eSignet pods after deployment: ```sh kubectl get pods -n esignet ``` ### eSignet API Test Rig Installation `esignet-apitestrig` tests the APIs and the end-to-end functional flow of the eSignet modules — see [esignet-apitestrig](https://github.com/mosip/esignet/tree/release-2.0.x/deploy/esignet-apitestrig). ### Uninstalling eSignet To completely remove eSignet from your Kubernetes environment: ```sh ./delete-all.sh ``` ## Documentation * [Onboarding Pre-requisites](/home/esignet-2.0.0/develop/integration/relying-party/relying-party-onboarding) — before you request registration as a relying party. * [Onboarding Form](/home/esignet-2.0.0/develop/integration/relying-party/integrate-with-e-signet) — requesting registration as a relying party. * [Integration and Discovery Endpoint](/home/esignet-2.0.0/develop/integration/relying-party/integration-options-and-discovery-endpoints) *(page to be added)* * [Development and Integration with eSignet](/home/esignet-2.0.0/develop/integration/relying-party/development-and-integration-with-esignet) — what it takes to connect your application as a relying party. {% hint style="info" %} Having the mock relying party portal installed is helpful for verifying the complete eSignet flow end to end. {% endhint %} # Community Join the eSignet community! 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. * Design and architecture reviews. * Bug identification and fixes. * Technology evaluation support. * UI/UX design improvements. * Documentation. #### How do I contribute? For code contributions, refer [here](/home/esignet-2.0.0/contribution/code-contribution). To engage with us on our community forum and connect with fellow contributors visit [here](https://community.mosip.io/c/e-signet/15). # Code Contribution ## Overview The below recommended Github workflow allows developers to submit code and documentation contributions to eSignet open-source repositories. ### Repositories {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} ## Setup your development machine 1. Fork repository of interest. 2. Clone the fork to your local machine. E.g.: ``` $ git clone https://github.com//esignet.git ``` 3. Set the upstream project as the original from where you forked. E.g.: ``` $ cd esignet $ git remote add upstream https://github.com/mosip/esignet.git ``` 4. Make sure you never directly push upstream. ``` $ git remote set-url --push upstream no_push ``` 5. Confirm the origin and upstream. ``` $ git remote -v ``` ## Code changes 1. Create a new issue in GitHub. 1. Follow the issue template provided. 2. Please provide as much information as possible. 3. If you want to develop a new feature, please elaborate on the idea and discuss the design before starting development. 2. In your local repository, fetch the upstream. ``` $ git fetch upstream ``` 3\. On your local repo, switch to a branch if you are working on an older release (like the 1.0.0 branch) or stay in `main/develop` the branch. ``` $ git checkout upstream/ ``` {% hint style="info" %} You will get a warning from git. Don't worry, our next step will take care of this warning. {% endhint %} 4\. Create a new issue branch with the name of the issue. ``` $ git switch -c issue- ``` 5\. Make sure you are up-to-date with the upstream repo. ``` $ git pull upstream ``` {% hint style="info" %} You should do this quite often to ensure you are up to date. {% endhint %} 6\. Now feel free to make the change in the code or documentation. Reach out to [our community](https://community.mosip.io) for any queries. Once done with the work, commit your changes by referring to the Issue ID in the commit message. Eg: ``` $ git commit -m "[#1234] Adding new upload feature in eSignet service" ``` 7\. Once again, ensure you are up-to-date with the upstream repo as it may have moved forward. ``` $ git pull upstream ``` 8\. Build and test your code. Make sure to follow the coding guidelines. Provide unit test cases for the changes you have built. 9\. Push to your forked repo (origin). ``` $ git push --set-upstream origin issue- ``` 10\. On your forked remote repository from GitHub, create a pull request using the Contribute button. Direct the pull-request to `main` or any specific branch upstream. {% hint style="info" %} Most often it's the same branch in the upstream (as in Step 3). {% endhint %} 11\. Make sure the automatic tests on GitHub for your pull request pass. 12\. Reviewers shall review the pull request. Reach out to the [community](https://community.mosip.io) for a faster response. # Code of Conduct ## Preamble eSignet was created to foster an open, innovative, and inclusive community around open source and open standards. To clarify expected behaviour in our communities, we have adopted the Contributor Covenant. This code of conduct has been adopted by many other open-source communities, and we feel it expresses our values well. ## Our Pledge We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, colour, religion, or sexual identity and orientation. We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. ## Our Standards Examples of behaviour that contributes to a positive environment for our community include: * Demonstrating empathy and kindness toward other people * Being respectful of differing opinions, viewpoints, and experiences * Giving and gracefully accepting constructive feedback * Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience * Focusing on what is best, not just for us as individuals, but for the overall community Examples of unacceptable behaviour include: * The use of sexualized language or imagery, and sexual attention or advances of any kind * Trolling, insulting or derogatory comments, and personal or political attacks * Public or private harassment * Publishing others' private information, such as a physical or email address, without their explicit permission * Other conduct which could reasonably be considered inappropriate in a professional setting ## Enforcement Responsibilities Community leaders are responsible for clarifying and enforcing our standards of acceptable behaviour and will take appropriate and fair corrective action in response to any behaviour that they deem inappropriate, threatening, offensive, or harmful. Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct and will communicate reasons for moderation decisions when appropriate. ## Scope This Code of Conduct applies within all community spaces and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behaviour may be reported to the community leaders responsible for enforcement at [MOSIP](mailto:info@mosip.io). All complaints will be reviewed and investigated promptly and fairly. All community leaders are obligated to respect the privacy and security of the reporter of any incident. ## Enforcement Guidelines Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct: ### 1. Correction **Community Impact**: Use of inappropriate language or other behaviour deemed unprofessional or unwelcome in the community. **Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behaviour was inappropriate. A public apology may be requested. ### 2. Warning **Community Impact**: A violation through a single incident or series of actions. **Consequence**: A warning with consequences for continued behaviour. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban. ### 3. Temporary Ban **Community Impact**: A serious violation of community standards, including sustained inappropriate behaviour. **Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban. ### 4. Permanent Ban **Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behaviour, harassment of an individual, or aggression toward or disparagement of classes of individuals. **Consequence**: A permanent ban from any sort of public interaction within the community. ## Attribution This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1, available at . Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity). For answers to common questions about this code of conduct, see the FAQ at . Translations are available at . # General Explore eSignet’s key Resources, FAQs, and Glossary. # Resources Dive into eSignet with interactive workshops and webinars. ### **The Need for ID Verification & eSignet in Action** Discover why digital ID verification matters and see eSignet in action. ### **📊 What You'll Learn:** * **Concept & Need for ID Verification:** Why secure and trusted digital identity is essential. * **Functional Overview of eSignet & Sign-up:** How the modules work and support identity assurance. * **Live Demos:** Walkthrough of both **eSignet** and **Sign-up** modules in action. Watch the video below for more insights.🚀 {% embed url="" %} ### ### # FAQs Below are some frequently asked questions (FAQs) about eSignet. ## About eSignet

What is eSignet?

**eSignet** is a digital identity verification tool that simplifies access to online services. It allows users to identify themselves using various [authentication methods](/home/esignet-2.0.0/readme/features#supported-authentication-methods) and supports multiple forms of IDs as handles (e.g. National ID, Phone Number, Email ID, etc.). In today's era of digital transformation, there has been a global shift towards moving most services online. To facilitate personalized access to these online services, a secure and trusted digital identity is crucial. eSignet strives to provide a user-friendly and effective method for individuals to authenticate themselves and utilize online services while also having the option to share their profile information. Moreover, eSignet supports multiple modes of identity verification to ensure inclusivity and broaden access, thereby reducing potential digital barriers. To know more eSignet please refer [here](/home/esignet-2.0.0).

How can I use eSignet?

You can integrate with eSignet based on the type of entity, such as an ID system, a relying party, or a digital wallet. For more details, please go through our [integration guides](/home/esignet-2.0.0/develop/integration). If you are interested in trying out eSignet right away, you can use our sandbox for testing. Please go through our [Try it out ](/home/esignet-2.0.0/local-deployment/try-it-out)section for more details.

What are the various modes of authentication that eSignet supports?

eSignet provides multiple authentication methods, as listed below: * OTP Authentication * Biometric Authentication * Password-based Authentication * Knowledge-Based Identification (KBI) For a full list of supported authentication methods, refer to the [eSignet features](/home/esignet-2.0.0/readme/features). {% hint style="info" icon="wallet" %} **Note:** Wallet-based authentication is not supported in eSignet v2.0.0. It will be added in an upcoming release to bring the Go version to feature parity with eSignet (Java). {% endhint %}

Who are the intended users of eSignet?

The intended users of eSignet include: * Government ID Agencies that need secure verification mechanisms to deliver services to their residents. * Individuals or residents accessing online services. * Businesses and/or Service Providers that require streamlined methods to authenticate beneficiaries and provide services.

How scalable is eSignet? Can it handle a significant increase in user volume?

eSignet is simple, lightweight, and powerful. The Go-based implementation compiles to a single binary with a minimal memory footprint, making horizontal scaling straightforward. It uses [Redis](https://redis.io/) as a shared OIDC transaction and flow state store, enabling stateless multi-instance deployments behind a load balancer. It can scale effortlessly to handle large user volumes while acting as a middle layer for identity verification. For capacity planning, refer to the [latest performance report](/home/esignet-2.0.0/roadmap-and-releases/versions/v2.0.0/performance-report). It ships JMeter scripts and a TPS thread-setting calculator to estimate the required threads and sustainable throughput for a target TPS. Published resource calculator is available [here](https://github.com/mosip/esignet/blob/release-2.0.x/performance-test/resource_calculator_eSignet_2.0.0.xlsx).

How does eSignet ensure the security and privacy of user data?

eSignet applies several data-minimization and data-protection controls to limit exposure of personal information: * **Data minimization:** eSignet issues access tokens tied to user identifiers and releases only the claims explicitly requested and consented to by the user. Authentication inputs (OTP, biometric, KBI fields) are processed in-flight and are not persisted by eSignet. * **Consent:** The login process occurs exclusively on the eSignet platform. A built-in consent flow requires users to explicitly grant or withhold access to each requested claim before any information is shared with a relying party. Consent decisions are recorded with an expiry and can be withdrawn. * **Protected data flow:** The Go implementation enforces JWE-encrypted ID tokens and userinfo responses (configured per client), DPoP-bound access tokens when enabled per client via `additionalConfig.dpop_bound_access_tokens` (preventing token replay by a different client), and JTI replay prevention on incoming signed assertions. All signing and encryption keys are managed by the embedded Go keymanager, configured via `KEYMANAGER_*` environment variables, with optional HSM (PKCS#11) backing.

What technologies are used in the development of eSignet?

For a complete breakdown of the technology stack used in the Go-based eSignet implementation, refer to the [Technology Stack](/home/esignet-2.0.0/readme/technology) document.

Why should an entity adopt eSignet?

eSignet is an open-source, flexible solution that follows standard protocols ([OAuth 2.1](https://oauth.net/2.1/), [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html), [FAPI 2.0](https://openid.net/specs/fapi-security-profile-2_0.html)) for easy integration and high security, ensuring no vendor lock-in. As a MOSIP product, it integrates with any trusted ID system and offers a secure, adaptable identity verification solution.

## Features and Functionality

What unique features does eSignet offer?

* **Standards-based security:** [OAuth 2.1](https://oauth.net/2.1/), [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html), [FAPI 2.0](https://openid.net/specs/fapi-security-profile-2_0.html) (PAR + DPoP + `private_key_jwt`), PKCE, JWE-encrypted responses. * **Declarative authentication flows:** Authentication logic is defined as YAML flow graphs (`data/flows/*.yaml`) and interpreted at runtime, no code changes required to modify the login flow. * **Multiple pluggable identity backends:** MOSIP IDA (OTP + KYC), [SunbirdRC](https://github.com/Sunbird-RC/sunbird-rc-core) KBI, and a mock backend for development/testing. * **Embedded key manager:** On every startup the keymanager idempotently provisions a full key hierarchy: a `ROOT` CA; `OIDC_SERVICE` component master key (`RSA_2048`), EC signing key (`EC_SECP256R1_SIGN`), and cache encryption key (`CACHE_ENCRYPT`); and `OIDC_PARTNER` component master key (`RSA_2048`). `KEYMANAGER_KEYSTORE_TYPE` selects the PKCS#11 (HSM) or PKCS#12 (file) backend at runtime. * **User centricity:** Single identity credential access across services, mandatory user consent, and multiple authentication methods. * **Flexible CAPTCHA support:** [Google reCAPTCHA](https://www.google.com/recaptcha/), [Cloudflare Turnstile](https://www.cloudflare.com/products/turnstile/), and [hCaptcha](https://www.hcaptcha.com/) are all supported. Refer [here](/home/esignet-2.0.0/readme/features) to know more about features of eSignet.

What standards does eSignet follows?

eSignet implements the following standards: * [**OAuth 2.1**](https://oauth.net/2.1/) and [**OpenID Connect Core 1.0**](https://openid.net/specs/openid-connect-core-1_0.html) * [**FAPI 2.0**](https://openid.net/specs/fapi-security-profile-2_0.html) (Financial-grade API Security Profile) * [**RFC 9126**](https://www.rfc-editor.org/rfc/rfc9126) — Pushed Authorization Requests (PAR) * [**RFC 9449**](https://www.rfc-editor.org/rfc/rfc9449) — DPoP (Demonstrating Proof of Possession) * [**Secure Biometric Interface (SBI)**](https://standards.ieee.org/ieee/3167/10925/) for biometric device compatibility * [**JWE**](https://www.rfc-editor.org/rfc/rfc7516) **/** [**JWS**](https://www.rfc-editor.org/rfc/rfc7515) (RFC 7516, 7515) for encrypted and signed token responses * To know more about eSignet standards, please refer [here](/home/esignet-2.0.0/readme/standards).

How many types of authentication methods does eSignet support today?

The types of authentication methods supported by eSignet are [available here](/home/esignet-2.0.0/readme/features).

## Partner Integrations

Can you provide examples of successful integrations with potential partners?

eSignet will be deployed across various platforms, focusing on secure authentication. The solution actively explores integration opportunities with new partners and countries, with proof of concept (POC) completed in multiple countries. Below are some examples of eSignet integrations: * **Health Management**: The POC for eSignet integration with the Health Management portal is complete, enabling OTP and biometric-based authentication for seamless access to health services, with user verification against migrated ID data. * **SuperApp Integration:** eSignet will be integrated into a multi-service SuperApp for basic registration, login, and enhanced eKYC. Development is underway, and completion is expected soon. * **Insurance Portal**: Integration of eSignet with a health insurance portal is underway, using migrated ID data for secure authentication and quick access to insurance services. * **University Authentication**: eSignet is being implemented for face authentication of students and staff, verified against university ID data for access to services like exams, hostel assignments, and meal identification. * **Government and Private Services**: A brownfield implementation of MOSIP is in progress, with eSignet integration planned to authenticate users with National ID data across government and private services. * **Self-Service Portal for Benefits Delivery**: The POC for eSignet integration with OpenG2P is complete, allowing residents to authenticate via National ID data and register for Benefits Delivery.

What is ThunderID and how does it relate to eSignet?

[ThunderID](https://github.com/thunder-id/thunderid) is an open-source Go-based OAuth 2.1 / OpenID Connect engine that eSignet embeds as a Go module dependency. It handles all protocol endpoints (authorize, token, JWKS, discovery, introspect, userinfo, PAR, DPoP, etc.) and the flow execution engine. eSignet acts as a MOSIP-specific embedder: it injects MOSIP-aware providers (identity authentication, key management, consent storage, client registry) into the ThunderID engine via functional options, and registers its own client management API on top. This means eSignet benefits from ThunderID's protocol correctness and standards coverage while retaining full control over identity verification logic.

Does eSignet support FAPI 2.0?

Yes. The Go implementation supports the [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-security-profile-2_0.html). FAPI 2.0 requirements are enforced per-client via the `additionalConfig` object in the `POST /client-mgmt/client` registration payload: ``` { "additionalConfig": { "require_pushed_authorization_requests": true, "dpop_bound_access_tokens": true, "require_pkce": true } } ``` * `require_pushed_authorization_requests: true` — forces the client to POST authorization parameters to `POST /oauth2/par` first and use the returned `request_uri` in the subsequent `GET /oauth2/authorize` redirect. * `dpop_bound_access_tokens: true` — rejects any token request from this client that does not include a valid `DPoP` proof header. * `clientAuthMethods: ["private_key_jwt"]` — the client authenticates at the token endpoint using a signed JWT rather than a shared secret. Refer to the [Postman collection](https://github.com/mosip/esignet/tree/master/postman-collection) (folder "FAPI 2.0") in the repository for a working example.

Does eSignet support JWE-encrypted token responses?

Yes. Per-client JWE ([RFC 7516](https://www.rfc-editor.org/rfc/rfc7516)) encryption is configured in two steps: 1. **Set the response type** in the `additionalConfig` object when registering via `POST /client-mgmt/client`: ``` { "additionalConfig": { "userinfo_response_type": "JWE", "id_token_response_type": "JWE" } } ``` 2. **Register the encryption public key** via `PATCH /client-mgmt/client/{client_id}` using the `encPublicKey` field. Both RSA (`RSA-OAEP-256`, `RSA-OAEP`) and EC (`ECDH-ES`, `ECDH-ES+A128KW`, etc.) keys are supported. Setting `encPublicKey` to `null` clears the key. The signing public key (`publicKey`) set at registration cannot be changed; if it is compromised, create a new client. When JWE is active, the RP must possess the corresponding private key to decrypt the `id_token` and userinfo response.

## Architecture

How is the Go-based eSignet structured?

For a detailed breakdown of the project structure, refer to the [esignet-service README](https://github.com/Infosys/esignet/blob/master/esignet-service/README.md). The [ThunderID](https://github.com/thunder-id/thunderid) engine is embedded as a Go module; `main.go` calls `thunderidengine.New(mux, ...options)` and all standard protocol endpoints are registered automatically.

What changed from the Java version to the Go version?

| Dimension | Java eSignet | Go eSignet | | ------------------- | ---------------------------------------- | ------------------------------------------------------------------------ | | Language / runtime | Java 11 / Spring Boot | Go 1.26, single binary | | Protocol logic | Internal Java services | Delegated to [ThunderID](https://github.com/thunder-id/thunderid) engine | | Key management | MOSIP keymanager (Java microservice) | Embedded Go keymanager (`KEYMANAGER_*` env vars) | | Configuration | `application.properties` / Spring Config | `data/deployment.yaml` + environment variables | | Authentication flow | Hard-coded Java controllers | Declarative YAML flow graphs | | Database access | Spring Data JPA / Hibernate | Raw SQL via `pgx/v5` + `sqlc` | | Metrics | Spring Actuator / Micrometer | [Prometheus](https://prometheus.io/) endpoint | | Transaction store | Redis or in-memory | Redis or in-memory |

How does key management work in the Go version?

The Go version ships an **embedded Go keymanager** — no separate Java microservice is required. It is configured exclusively via `KEYMANAGER_*` environment variables and automatically provisions a two-level key hierarchy on first startup: * `OIDC_SERVICE` — the signing key for ID tokens and JWKS * `OIDC_PARTNER` — per-partner signing/encryption keys Two backends are supported, selected at runtime via `KEYMANAGER_KEYSTORE_TYPE`: * **PKCS#11** (production builds with CGO enabled): uses a hardware HSM or [SoftHSM2](https://www.opendnssec.org/softhsm/). Requires a CGO-enabled binary and the PKCS#11 shared library. * **PKCS#12** (default dev builds, CGO disabled): keys are stored in an encrypted `.p12` file on disk. No native dependencies required. Certificate upload/download is available at `/system-info/certificate` and `/system-info/uploadCertificate`.

How are authentication flows defined in the Go version?

Authentication logic is expressed as declarative YAML flow graphs stored in `data/flows/`. The main flow file is `flow-esignet.yaml`. Each flow is a directed graph of named nodes; each node calls a registered executor. eSignet registers two custom executors in addition to the 30+ built-in [ThunderID](https://github.com/thunder-id/thunderid) executors: | Executor | Purpose | | --------------------- | -------------------------------------------------------------------- | | `eSignetOtpExecutor` | Dispatches OTP via the selected IDA backend (MOSIP, SunbirdRC, mock) | | `ClearInputsExecutor` | Clears sensitive user inputs between authentication retries | The YAML flow supports branching (OTP, password, biometric, KBI sub-flows), looping (re-prompting on failed consent), and convergence before the final authorization assertion.

## Configuration and Setup

Which version of eSignet can be used?

Always use the latest GA (Generally Available) release of eSignet for the best security, features, and performance. Refer to the [GitHub releases page](https://github.com/mosip/esignet/releases) for the latest versioned release. If you are an existing eSignet user, use the upgrade scripts provided in the repository to migrate to a newer version.

Where can I access the source code?

You can access the source code from the [eSignet GitHub repository](https://github.com/mosip/esignet). The `esignet-service/` directory contains the Go backend; `oidc-ui/` contains the React frontend.

Is there documentation available for setting up eSignet locally?

Yes. A `docker-compose/` directory is provided with a `docker-compose.yaml` that spins up PostgreSQL and Redis. Refer to the [README](https://github.com/mosip/esignet/blob/master/docker-compose/README.md) at the repository root for step-by-step local setup instructions.

How is eSignet configured in the Go version?

Runtime configuration spans several sources: * **`esignet-service/data/deployment.yaml`** — core server, database, Redis, OAuth, and issuer settings. Environment variables are expanded inline using `${ENV_VAR_NAME}` syntax. * **`data/flows/*.yaml`** — declarative authentication flow graphs (e.g. `flow-esignet.yaml`), which define login logic and executor sequences. * **`KEYMANAGER_*` environment variables** — keystore backend selection (`KEYMANAGER_KEYSTORE_TYPE`), PKCS#11 module path/PIN, or PKCS#12 file path/password. * **CAPTCHA variables** (e.g. `MOSIP_ESIGNET_CAPTCHA_VALIDATOR_URL`) — endpoint and credentials for server-side CAPTCHA token validation. * **`oidc-ui` configuration** — frontend environment variables with the `VITE_` prefix, set during the `oidc-ui` build or via its deployment configuration. Key sections in `deployment.yaml` include: ``` server: port: 8088 issuer: "https://esignet.example.org" oauth: token: accessTokenExpiry: 3600 idTokenExpiry: 3600 refreshTokenExpiry: 86400 db: host: "${DB_HOST}" port: "${DB_PORT}" name: "${DB_NAME}" username: "${DB_USERNAME}" password: "${DB_PASSWORD}" redis: host: "${REDIS_HOST}" port: "${REDIS_PORT}" ``` Environment variable overrides apply only to values declared with `${ENV_VAR_NAME}` placeholders in the YAML (e.g. `host: "${REDIS_HOST}"`). Literal values such as `server.port`, `issuer`, and token expiries must be changed directly in the YAML file or via a Helm values override.

How is a relying party onboarded to eSignet - integrated with MOSIP

Relying parties are considered Auth partners in MOSIP and must complete [authentication partner onboarding](https://docs.mosip.io/1.2.0/id-lifecycle-management/support-systems/partner-management-services/functional-overview/end-user-guide) before registering a client: * **Self-service onboarding:** Partners self-register on the [MOSIP PMS portal](https://docs.mosip.io/1.2.0/id-lifecycle-management/support-systems/partner-management-services/functional-overview/collab-pmp-guide). * **Onboarder script:** Partners are provisioned using the [partner-onboarder](https://github.com/mosip/esignet/tree/develop-go/partner-onboarder) script bundled in the repository. * **Assisted Onboarding** Alternatively, partners can also initiate the onboarding process by filling out the form [here](https://docs.google.com/forms/d/e/1FAIpQLSerko7k1wiy1sjgfRSfRU5Bjkb7cKc0t2z0FmKt6mSLBqJGXQ/viewform). Once submitted, partners will receive their credentials via email shortly. When onboarding through MOSIP PMS, PMS invokes the `/client-mgmt/client` endpoint directly as part of the partner and policy configuration — partners do not call it themselves. In standalone (non-MOSIP) deployments, the client is registered by calling the `/client-mgmt/client` API (or the profile-specific `/client-mgmt/oidc-client` for backward compatibility) with a bearer token scoped to `client_mgmt_write`.

How to configure password authentication in eSignet?

Two conditions must be satisfied: 1. **Register the password ACR on the client:** include the ACR value `mosip:idp:acr:password` in the `authContextRefs` array when creating or updating a client via the `/client-mgmt/client` API. 2. **The integrated ID system must support password-based authentication:** the configured identity backend (MOSIP IDA, SunbirdRC, or mock) must be able to verify the resident's password credential. No separate ACR-AMR mapping file is required — the mapping is handled within the YAML flow graph (`flow-esignet.yaml`). Refer to the [eSignet API documentation](/home/esignet-2.0.0/develop/api) for the full client registration payload schema.

How to add a new language in eSignet?

Localization strings live in the eSignet service data directory at [`esignet-service/data/i18n/`](https://github.com/mosip/esignet/tree/develop-go/esignet-service/data/i18n), with one YAML file per language named using its [ISO 639-1](https://www.iso.org/iso-639-language-codes.html) code (e.g. `en.yaml`, `fr.yaml`). The service auto-discovers the available languages by scanning this folder, so there is no separate registration file. To add a new language: 1. Go to `esignet-service/data/i18n/` (the folder resolved from `DATA_DIR`). 2. Copy `en.yaml` and rename it with the ISO 639-1 language code (e.g. `fr.yaml` for French). 3. Translate the values in the new file, keeping the top-level namespace keys unchanged. 4. Restart or redeploy the eSignet service so the new file is picked up. Requests then resolve via BCP47 matching (for example, `fr-FR` falls back to `fr`), with `en` as the final fallback.

How to remove a language from the eSignet default setup?

1. Delete the language's YAML file (e.g. `fr.yaml`) from [`esignet-service/data/i18n/`](https://github.com/mosip/esignet/tree/develop-go/esignet-service/data/i18n). 2. Restart or redeploy the eSignet service so the language is no longer listed.

How to configure the expected quality score, timeouts, and number of biometric attributes to be captured in eSignet?

These SBI capture parameters are passed to the [`@mosip/secure-biometric-interface-integrator`](https://www.npmjs.com/package/@mosip/secure-biometric-interface-integrator) widget by the `oidc-ui` React app. They are currently defined as the `DEFAULT_SBI_ENV` defaults in [`oidc-ui/src/components/SbiComponent/SbiComponent.tsx`](https://github.com/mosip/esignet/blob/develop-go/oidc-ui/src/components/SbiComponent/SbiComponent.tsx) and are **not** overridable via environment variables: ``` const DEFAULT_SBI_ENV = { env: "Staging", captureTimeout: 30, faceCaptureCount: 1, faceCaptureScore: 80, fingerCaptureCount: 1, fingerCaptureScore: 80, irisCaptureCount: 1, irisCaptureScore: 80, portRange: "4501-4600", discTimeout: 15, dinfoTimeout: 30, // ... }; ``` To change the quality-score thresholds (0–100), capture counts, or timeouts (in seconds), edit this object and rebuild/redeploy the `oidc-ui` container.

How to enable or disable the captcha in eSignet UI?

CAPTCHA is wired into the authentication flow, not `deployment.yaml`. The `captcha` block lives in the flow definition [`esignet-service/data/flows/flow-esignet.yaml`](https://github.com/mosip/esignet/blob/develop-go/esignet-service/data/flows/flow-esignet.yaml), and its values are supplied through environment variables (see [`.env.example`](https://github.com/mosip/esignet/blob/develop-go/esignet-service/.env.example)): ``` # Provider shown by the UI and its public site key MOSIP_ESIGNET_CAPTCHA_SITE_PROVIDER=hcaptcha # e.g. recaptcha | turnstile | hcaptcha MOSIP_ESIGNET_CAPTCHA_SITE_KEY= # Server-side token validation (skipped when the URL is unset) MOSIP_ESIGNET_CAPTCHA_VALIDATOR_URL=https:///v1/captcha/validatecaptcha # Use http:// only for isolated local development (no outbound HTTPS available) MOSIP_ESIGNET_CAPTCHA_MODULE_NAME=esignet MOSIP_ESIGNET_CAPTCHA_TIMEOUT_SECS=10 ``` To disable CAPTCHA entirely, remove the `CAPTCHA_BOX` node reference from the relevant steps in `flow-esignet.yaml`. Do **not** leave `MOSIP_ESIGNET_CAPTCHA_VALIDATOR_URL` unset in production — omitting it causes CAPTCHA tokens to be accepted without server-side verification, which defeats bot protection. Leaving the URL unset is only acceptable for isolated local development where no CAPTCHA service is reachable. The providers selectable via `MOSIP_ESIGNET_CAPTCHA_SITE_PROVIDER` are: * **`recaptcha`** — [Google reCAPTCHA](https://www.google.com/recaptcha/) * **`turnstile`** — [Cloudflare Turnstile](https://www.cloudflare.com/products/turnstile/) * **`hcaptcha`** — [hCaptcha](https://www.hcaptcha.com/)

How to configure Redis for OIDC transaction storage?

[Redis](https://redis.io/) is used as the shared OIDC transaction and flow state store and is required for multi-instance deployments. Configure it in `deployment.yaml`: ``` redis: host: "${REDIS_HOST}" port: "${REDIS_PORT}" password: "${REDIS_PASSWORD}" db: 0 tls: true # set to false only for isolated local development; always true for production ``` Redis is selected by setting `MOSIP_ESIGNET_CACHE_TYPE=redis`. For single-instance development setups, use the in-memory runtime store instead by setting `MOSIP_ESIGNET_CACHE_TYPE=inmemory` (any value other than `redis` selects the in-memory store). This is not suitable for production as state is lost on restart.

How to configure PKCS#11 / HSM key storage?

Keystore selection is a **runtime** setting driven by `KEYMANAGER_*` environment variables (read by the keymanager at startup), not a `deployment.yaml` block. The PKCS#11 backend additionally requires a CGO-enabled binary, since it links a native PKCS#11 module. To use a hardware HSM or [SoftHSM2](https://www.opendnssec.org/softhsm/) in production, build with CGO enabled (see `make.sh`) and set: ``` # PKCS#11 requires a CGO_ENABLED=1 build KEYMANAGER_KEYSTORE_TYPE=PKCS11 KEYMANAGER_PKCS11_MODULE_PATH=/usr/lib/softhsm/libsofthsm2.so KEYMANAGER_PKCS11_TOKEN_LABEL=esignet KEYMANAGER_PKCS11_SLOT_ID= KEYMANAGER_PKCS11_PIN=${HSM_PIN} ``` For development without an HSM, use the file-based PKCS#12 backend (the only backend available in the default `CGO_ENABLED=0` build): ``` KEYMANAGER_KEYSTORE_TYPE=PKCS12 KEYMANAGER_PKCS12_FILE_PATH=/opt/mosip/keystore.p12 KEYMANAGER_PKCS12_PASSWORD=${KEYSTORE_PASSWORD} KEYMANAGER_PKCS12_ALLOW_INSECURE_SOFTWARE_KEYSTORE=true ``` On first startup, the two-level key hierarchy (`OIDC_SERVICE`, `OIDC_PARTNER`) is provisioned automatically.

How to register or create a client ID in eSignet?

In order to utilize eSignet for authenticating users and obtaining their information, relying parties are required to: 1. Register as a client in the eSignet system using one of the client management endpoints below. All endpoints require a bearer token (`Authorization: Bearer `) carrying the appropriate scope. 2. Integrate with eSignet APIs, following the guidelines provided by [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html), on their web or mobile applications. The Go implementation exposes three registration profiles: | Method | Endpoint | Profile | Scope required | | ------- | --------------------------------------- | ---------------------------------------------- | ------------------- | | `POST` | `/client-mgmt/client` | Generic — **recommended for new integrations** | `client_mgmt_write` | | `PUT` | `/client-mgmt/client/{client_id}` | Generic — full update | `client_mgmt_write` | | `PATCH` | `/client-mgmt/client/{client_id}` | Generic — partial update | `client_mgmt_write` | | `GET` | `/client-mgmt/client/{client_id}` | Generic — fetch | `client_mgmt_read` | | `POST` | `/client-mgmt/oidc-client` | OIDC profile (legacy compat) | `client_mgmt_write` | | `PUT` | `/client-mgmt/oidc-client/{client_id}` | OIDC profile — full update | `client_mgmt_write` | | `POST` | `/client-mgmt/oauth-client` | OAuth profile | `client_mgmt_write` | | `PUT` | `/client-mgmt/oauth-client/{client_id}` | OAuth profile — full update | `client_mgmt_write` | Use `/client-mgmt/client` for all new integrations. The `/client-mgmt/oidc-client` endpoint is retained for backward compatibility with existing Java-era integrations. Refer to the [API documentation](/home/esignet-2.0.0/develop/api) for the full registration payload schema. For MOSIP-integrated environments, relying parties are Auth partners and must complete partner onboarding on the MOSIP PMS portal before calling the client management API. Refer the [guide here](https://docs.mosip.io/1.2.0/id-lifecycle-management/support-systems/partner-management-services/functional-overview/end-user-guide) for auth partner oanboarding steps.

How to configure Knowledge-Based Identification (KBI) with SunbirdRC?

The [SunbirdRC](https://github.com/Sunbird-RC/sunbird-rc-core) KBI authenticator (`internal/engine/sunbird/`) identifies users by matching fields from the KBI form against records in a SunbirdRC registry. The fields displayed in the KBI form are driven by the registry schema. If more than one registry entry matches the provided details, authentication is denied. Configure the SunbirdRC backend through [environment variables](https://github.com/mosip/esignet/blob/develop-go/esignet-service/.env.example).\ \ The current compatible Sunbird RC version is v2.0.0-rc3.

Where can I find Prometheus metrics for eSignet?

The Go binary exposes a [Prometheus](https://prometheus.io/)-compatible metrics endpoint on a **separate private listener** — not the main application port and not routed through the public gateway/ingress. It is only reachable within the cluster (for example, by Prometheus). The listener defaults to port `9090` and is configurable via the `METRICS_PORT` environment variable (or `metrics_port` in `deployment.yaml`): ``` GET http://:9090/metrics ``` Key metrics include active OIDC transactions, token issuance counts, authentication attempt counts by method and outcome, and key manager operation latencies. Configure scraping in your Prometheus `prometheus.yml` or via a Kubernetes `ServiceMonitor`. For a reference Kubernetes setup, see the [Helm charts](https://github.com/mosip/esignet/tree/develop-go/helm) in the repository.

# Glossary Your go-to guide for understanding eSignet terminologies.

Term	Description
Digital ID Wallet	A digital ID wallet is a tool 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.
Good ID	Good ID refers to secure, inclusive, and privacy-respecting digital identity systems that prioritize user control, interoperability, open standards, and long-term sustainability. It ensures ethical and trustworthy identity management while protecting individuals’ data.
Identity Systems	In the context of digital identity and access management, it refers to the infrastructure and technologies used to manage and verify digital identities, ensuring secure access to online services.
Identity Verification	Identity verification is the important process of ensuring that a person is who they claim to be to avail of various government and private sector services.
Biometric Verification	Passwordless and based on SBI standards, enabling secure authentication beyond personal devices.
OTP	Passwordless but requires phone access, serving as a fallback for biometric rejections.
Self-Authentication	Users verify themselves, commonly used online.
QR Code	Uses a smartphone selfie and a private key for secure authentication.
Relying Party	A relying party is a service provider that relies on an identity provider for authentication and identity verification, allowing users to securely and conveniently access their services. Typically, these are online services, websites, or applications that require user identity verification for access control, personalization, or other reasons. The identity provider often utilizes protocols like OpenID Connect.

# Contact Us Have a question or feedback? We are here for you! Reach out to us through the channel that best fits your purpose, as outlined below. **Community Forum**\ Join the conversation at [community.mosip.io](https://community.mosip.io) to ask questions, share ideas, and explore discussions about MOSIP and its solutions. *** **Feedback**\ We truly value your input. Every suggestion counts in shaping our products and processes.\ Click [here](https://docs.google.com/forms/d/e/1FAIpQLSfY0_QWR01q9eP_AwC9gLNVfoKi0q7tfqxywxf153coVQHl0g/viewform) to share your feedback and help us make eSignet better. *** **Other Queries**\ For anything more specific or direct, feel free to write to us at **** — we’re happy to connect! *** # eSignet A Modern and Inclusive Digital Identity Authentication Solution ## Overview Digital identity is rapidly becoming the standard means of citizen identification across both government platforms and private service portals. As access to services increasingly relies on digital channels, secure user authentication has become a critical requirement. To ensure privacy, security, and inclusivity, authentication mechanisms must adhere to established standards that protect data and foster 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**: 1. [eSignet Authentication](/home/esignet/esignet-authentication) 2. [Signup](/home/esignet/esignet-signup) #### What is eSignet Authentication? [**eSignet** authentication](/home/esignet/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 [Signup](/home/esignet/esignet-signup) 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 [**eKYC Verification**](/home/esignet/esignet-signup/features#identity-assurance-flow-ekyc-verification), 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 [variety of authentication methods](/home/esignet/esignet-authentication/features#on-demand-selection-of-authentication-factors) 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. * **Integration with Multiple Registries** Provides the capability to connect with various identity registries to facilitate comprehensive user verification. * **Simple Integration with Relying Parties (Service Providers)** Streamlines the onboarding process for service providers requiring robust identity verification and facilitate [integration with eSignet](/home/esignet/esignet-authentication/develop/integration/relying-party). * **User Consent Management** Incorporates a built-in mechanism to obtain explicit [user consent for data access and usage](/home/esignet/esignet-authentication/features#consent-management). * **Protection Against Unwanted Profiling** Safeguards personal data by preventing unauthorized tracking or profiling of users. * **Multiple Assurance Levels** Supports varying levels of identity assurance, depending on the authentication method employed. * **Digital Wallet Integration** Enables secure, device-based authentication through [integration with digital wallets](/home/esignet/esignet-authentication/develop/integration/wallet). * **Verified Claims Support:** eSignet now includes [*verified claims* ](https://docs.esignet.io/home/esignet/pages/Tk3eiHfyOsvmzvqNZGRg#id-2.-interoperability)in its identity response, enabling relying parties to consume high-assurance user attributes. * **KYC-Verified Signup:** eSignet’s [Signup module](/home/esignet/esignet-signup) allows user registration with *Video eKYC*, enabling identities to be onboarded with verified claims from the start. * **FAPI 2.0 Compliance:** eSignet now complies with the FAPI 2.0 Security Profile, offering higher security and improved interoperability. ### **What Differentiates eSignet** #### 1. **Enhancing Authentication Methods Through Secure Standards** * **Standards-Based Architecture** utilizes [OpenID Connect flows built on the OAuth 2.0 framework](/home/esignet/readme/standards), 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 [Secure Biometric Interface (SBI)](/home/esignet/readme/standards#1-security) to enable secure biometric data collection for identity verification. * **Advanced Security Features** Supports secure OpenID Connect options such as the authorization code flow and includes enhanced fraud prevention measures. #### 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. * **Credential Security** Ensures that user authentication is handled exclusively on the eSignet platform, preventing unauthorized data sharing with third parties unless consented by the user. #### 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. * **Effortless Integration for Service Providers** Adheres to open standards, significantly reducing time-to-market for deploying identity services. * **Bridging the Digital Divide** Offers flexible verification modes to cater to users across the digital access spectrum. ### **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. #### [**Verification Modalities**](/home/esignet/esignet-authentication/features#supported-authentication-methods) * **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. * **Developers and System Integrators** Provides a comprehensive set of tools and standards to enable seamless integration of digital ID authentication and eKYC functionalities. ### **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:** Facilitates simplified tax filing and accurate taxpayer identification. * **Voting Systems:** Ensures secure and reliable voter authentication during elections. * **Banking:** Supports secure customer onboarding and transaction verification. * **Insurance:** Verified KYC data with high assurance levels enables faster, compliant onboarding, promoting financial inclusion. * **Border Control:** Enhances national security by verifying the identity of travelers and supporting secure cross-border movement. 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.

Cover image	Cover image
Principles	Principles Card.png	Principles
	S&S Card.png	Standards & Security
	License Card.png	License
	Technology card.png	Technology

# Principles Core principles that define eSignet. 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 the data modification APIs (Client management end points) are protected using **OAuth 2.0**, ensuring secure access control. All state-changing APIs are protected with OAuth 2.0, enforcing authenticated and authorized access. # Standards & Security Building on the most trusted security protocols. eSignet is built on industry-leading security standards, ensuring robust privacy and data protection. It implements [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0-final.html) and [OAuth 2.0](https://oauth.net/2/), 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)**](https://standards.ieee.org/ieee/3167/10925/) 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 * [React SBI Library](https://github.com/mosip/mosip-sdk/tree/master/react-secure-biometric-interface-integrator) * [JS SBI Library](https://github.com/mosip/mosip-sdk/tree/master/secure-biometric-interface-integrator) * [Supported Devices](https://docs.mosip.io/1.2.0/id-lifecycle-management/supporting-components/biometrics/biometric-devices) - 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 [**Identity Assurance**](/home/esignet/esignet-authentication/features#identity-assurance-flow-ekyc-verification) **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. | **Name** | **URL Paths** | | -------------------- | --------------------------------------- | | OpenID Configuration | /.well-known/openid-configuration | | Jwks Json | /.well-known/jwks.json | | Authorization Server | /.well-known/oauth-authorization-server | #### 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:** * [OAuth 2.0 RFC 6749](https://www.rfc-editor.org/rfc/rfc6749) - Authorization code flow support * [OAuth 2.0 RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) - Authorization Framework: Bearer Token Usage * [OAuth 2.0 RFC 7523](https://www.rfc-editor.org/rfc/rfc7523) - JWT profile for client authentication * [OAuth 2.0 RFC 7636 ](https://datatracker.ietf.org/doc/html/rfc7636)- PKCE security extension * [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0-final.html) * [Open ID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html) **b. Token and Discovery Standards:** * [RFC 7515](https://www.rfc-editor.org/rfc/rfc7515.html) - JSON Web Signature * [RFC 7516](https://www.rfc-editor.org/rfc/rfc7516.html) - Userinfo as JWE * [RFC 7517](https://datatracker.ietf.org/doc/html/rfc7517) - JSON Web Keys * [RFC-9068](https://www.rfc-editor.org/rfc/rfc9068.html) - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens * [RFC 7519](https://www.rfc-editor.org/rfc/rfc7519) - ID token and access token as JWT * [OAuth 2.0 RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414) - Authorization Server Metadata * [RFC 5785 ](https://www.rfc-editor.org/rfc/rfc5785)- Followed for both openid and oauth well-knowns **c. Identity Proofing and security:** * [Identity Assurance 1.0](https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html) * [IEEE SA P3167 SBI 2.0](https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html) **d. FAPI 2.0 Security Profile:** eSignet adopts key OpenID [**FAPI 2.0 security profile**](https://openid.net/specs/fapi-security-profile-2_0-final.html#section-5.3) 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. * [RFC-9126](https://datatracker.ietf.org/doc/html/rfc9126) - Pushed Authorization Request (PAR) * [RFC-9449](https://datatracker.ietf.org/doc/html/rfc9449) - Demonstrate Proof of Possession (Dpop) * [RFC-9207](https://www.rfc-editor.org/rfc/rfc9207) - 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: | **Standards** | **Flow** | **Client Authentication** | | ---------------------- | ---------------------------- | ------------------------- | | OAuth 2.0 | Authorization Code with PKCE | private-key-jwt | | OIDC | Authorization Code with PKCE | private-key-jwt | | Identity Assurance 1.0 | Authorization Code with PKCE | private-key-jwt | **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 [PKCE ](https://www.rfc-editor.org/rfc/rfc7636)(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. *** # License Empowering users through transparent licensing. The documentation is licensed under a Creative Commons Attribution 4.0 International License.

Tool/Technology	Version	Description	License
Java SE 21	OpenJDK 21	Java is a high-level, class-based, object-oriented programming language that is designed to have as few implementation dependencies as possible.	Oracle Binary Code License
Spring Framework	3.2.3	Spring Framework provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform.	Apache License 2.0
Lombok	1.18.42	Project Lombok is a Java library that automatically plugs into your editor and build tools, spicing up your java.	Lombok License
Logback	1.2.3	Logback is a logging framework that provides a fast, reliable, and highly configurable solution for generating logs in Java applications.	Logback License
openapi	2.6.0	The OpenAPI Specification is a specification language for HTTP APIs that provides a standardized means to define your API to others.	Apache License 2.0
kernel-keymanager-service (MOSIP)	1.3.0	The Key Manager Service provides secure storage, provisioning and management of secret data. It provides all the cryptographic operations like encryption/decryption and digital signature/verification making one trust store for all partner trust path validation.	Mozilla Public License 2.0
React JS	18.2v	React lets you build user interfaces out of individual pieces called components.	MIT License

#### Storage

Tool/Technology	Version	Description	License
Postgres	15	PostgreSQL also known as Postgres, is a free and open-source relational database management system (RDBMS) emphasizing extensibility and SQL compliance.	OpenSource License
Redis	6.0	Redis is a open source, in-memory data store used by millions of developers as a database, cache, streaming engine, and message broker. Redis can be replaced with any cache compatible with spring-cache.	BSD License
Kafka		Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.	Apache License 2.0

### Deployment Insert blockBlock controls

Tool/Technology	Version	Description	License
Maven	3.6	Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.	Apache License 2.0
Docker	20.4 and above	Docker is a set of platform as a service (PaaS) products that use OS-level virtualization to deliver software in packages called containers.	OpenSource License
npm		npm is the package manager for the Node JavaScript platform. It puts modules in place so that node can find them, and manages dependency conflicts intelligently.	Artistic License 2.0
kattu (MOSIP)	master and master-java21 branch	All workflows necessary to build the project is kept here
Helm Chart (MOSIP)	depends on eSignet version	Helm helps you manage Kubernetes applications - helps define, install, and upgrade even the most complex Kubernetes application. Charts are easy to create, version, share, and publish — so start using Helm and stop the copy-and-paste.

### Testing

Tool/Technology	Version	Description	License
JUnit	5	JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development and is one of a family of unit testing frameworks which is collectively known as xUnit that originated with SUnit.	Eclipse Public License 1.0
Newman		Newman is a command-line tool that allows you to run Postman collections and automate API tests. It is ideal for integrating API testing into CI/CD pipelines and provides detailed test reports for automated workflows.	Apache License 2.0

# Technology Stack eSignet is built using the below tools and technologies. ## Services and Rest Endpoints eSignet leverages a combination of backend technologies to ensure secure identity management and seamless service delivery.

Tool/Technology	Version	Description	License
Java SE 11	OpenJDK 11	Java is a high-level, class-based, object-oriented programming language that is designed to have as few implementation dependencies as possible.	Oracle Binary Code License
Spring Framework	2.3.6	Spring Framework provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform.	Apache License 2.0
Lombok	1.18.24	Project Lombok is a java library that automatically plugs into your editor and build tools, spicing up your java.	Lombok License
Logback	1.2.3	Logback is a logging framework that provides a fast, reliable, and highly configurable solution for generating logs in Java applications.	Logback License
openapi	1.6.9	The OpenAPI Specification is a specification language for HTTP APIs that provides a standardized means to define your API to others.	Apache License 2.0
kernel-keymanager-service (MOSIP)	1.2.1.0	The Key Manager Service provides secure storage, provisioning and management of secret data. It provides all the cryptographic operations like encryption/decryption and digital signature/verification making one trust store for all partner trust path validation.	Mozilla Public License 2.0
React JS	18.2v	React lets you build user interfaces out of individual pieces called components.	MIT License

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

Tool/Technology	Version	Description	License
Postgres	15	PostgreSQL also known as Postgres, is a free and open-source relational database management system (RDBMS) emphasizing extensibility and SQL compliance.	OpenSource License
Redis	17.3.14	Redis is a open source, in-memory data store used by millions of developers as a database, cache, streaming engine, and message broker. Redis can be replaced with any cache compatible with spring-cache.	BSD License
Kafka	18.3.1	Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.	Apache License 2.0

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

Tool/Technology	Version	Description	License
Maven	3.6	Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.	Apache License 2.0
Docker	20.4 and above	Docker is a set of platform as a service (PaaS) products that use OS-level virtualization to deliver software in packages called containers.	OpenSource License
npm	18-alpine	npm is the package manager for the Node JavaScript platform. It puts modules in place so that node can find them, and manages dependency conflicts intelligently.	Artistic License 2.0
kattu (MOSIP)	master branch	All workflows necessary to build the project is kept here
Helm Chart (MOSIP)	depends on eSignet version	Helm helps you manage Kubernetes applications - helps define, install, and upgrade even the most complex Kubernetes application. Charts are easy to create, version, share, and publish — so start using Helm and stop the copy-and-paste.

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

Tool/Technology	Description	License
JUnit	JUnit is a unit testing framework for the Java programming language.JUnit has been important in the development of test-driven development, and is one of a family of unit testing frameworks which is collectively known as xUnit that originated with SUnit.	Eclipse Public License 1.0
Newman	Newman is a command-line tool that allows you to run Postman collections and automate API tests. It is ideal for integrating API testing into CI/CD pipelines and provides detailed test reports for automated workflows.	Apache License 2.0
Postman	Postman is an API platform that simplifies the API lifecycle and streamlines collaboration. You can browse the largest network of public APIs, create and share your own workspaces, and access governance rules for API quality.	Apache License 2.0

# Roadmap and Releases Explore the eSignet Roadmap & Releases to stay updated on key milestones, new features, and major updates.

Cover image
Releases Card.png	Releases
Roadmap Card.png	Roadmap

# Roadmap Explore eSignet roadmap for key milestones, objectives, and highlights every year. # Roadmap 2026 & Beyond Here we present the eSignet product roadmap for 2026 and our strategic horizon forward. This roadmap outlines the planned features, progress, and release details for eSignet. > **Annual product cycle** of eSignet commences in **January** and concludes in **December**.

Vision

In 2026, eSignet will focus on strengthening its foundation and expanding advanced authentication capabilities. The year begins with a full migration from Java 11 to Java 21 across all eSignet components, improving performance, security, and long-term maintainability. eSignet will introduce Face Authentication to support on-the-go, high-assurance user verification, followed by Single Sign-On (SSO) to enable seamless access across services. The Signup module will evolve into a standalone identity verification portal, and the year will conclude with the addition of CIBA support, enabling secure and user-friendly decoupled authentication. Continuous performance and stability improvements will run throughout the year to ensure eSignet remains production-ready at scale.

Priority 🗓️	Features 🛠️	Details📝	Status 📊	Release 📌
P1	eSignet Go Version (GA) Deliver a stable release of eSignet for production deployments.	Milestone	🟠 In Progress	v2.0.0
P1	Java 21 Migration: Upgrade all eSignet repositories from Java 11 to Java 21 to improve performance, security, and long-term maintainability.	2763	🟢 Completed	v1.8.0
P1	eSignet Performance Improvements (v1.7.x with MOSIP ID): Optimise eSignet service performance and stability when integrated with MOSIP ID for high-volume identity transactions.	2829	🟢 Completed	v1.8.0
P1	UserInfo as Encrypted JWE: Support returning UserInfo as encrypted JWE, passing signed JWTs securely to relying parties.	2744	🟢 Completed	v1.8.0
P1	Signup Form Enhancements – Multiple Input Types: Enhance Signup forms to support diverse input types for better usability and extensibility.	2699	🟢 Completed	v1.8.0
P1	Face Authentication with eSignet: Introduce face authentication as a high-assurance, on-the-go authentication factor in eSignet.	TBA	🔵 Planned
P1	Wallet-based login using OpenID4VP Standard way to request specific credentials from a wallet and receive verified presentation	TBA	🔵 Planned
P1	Passkey Authentication Support Enable passkeys for passwordless, phishing-resistant authentication.	TBA	🔵 Planned
P1	CIBA Support in eSignet	TBA	🔵 Planned
P3	MFA Support – User Level: Allow users to manage and use multiple authentication factors during login.	TBA	🔵 Planned
P2	Single Sign-On (SSO) Super App Support: Enable SSO capabilities to support super apps and seamless cross-application login experiences.	TBA	🔵 Planned

*** **Acronyms and Legends**: TBA - 'Github Issues Link - To Be Added' # Roadmap 2025 This roadmap outlines the planned features, progress, and release details for eSignet throughout the calendar year 2025. Here we present the product roadmap for eSignet for the calendar year 2025. Annual product cycle of eSignet commences in January and concludes in December. {% hint style="warning" %} **Prioritization**: Through this roadmap the startegic or adaptive prioritization, if there is, has been indicated as below: * Add \[ ^**➕** ]: Added new. * Strategic priortization \[ ^**↑** ] : Brought ahead in schedule. * Adaptive reschedule \[ ^**↓** ]: Is moved to approaching quarters. {% endhint %}

Vision

* **Q1 2025:** Starting the year with major fixes, along with enhancements to IDA kyc-auth and kyc auth-exchange API’s. * **Q2 2025:** Introducing prefix postfix support for multiple login handles, customizable eSignet UI, and enhancing client management endpoint. * **Q3 2025:** Adding FAPI 2.0 security compliance and SSO feature along with dynamic sign-up form. These upgrades enhance security, improve interoperability, and offer more flexibility in user onboarding. **Q4 2025:** Java platform migration from Java 11 to Java 21, and advanced consent management features including support for obtaining consent from external parties, and consent handling for child and deceased users. **2025 and Beyond:** Focus on implementing identity brokering for seamless integration with external identity providers, ensuring secure user authentication. Transforming eSignet into an advanced eKYC verifier by leveraging plugins for ID verification with OIDC providers through web or mobile wallets, helping businesses comply with regulatory standards, and improving onboarding. .

Quarter 🗓️	Features 🛠️	Details📝	Status 📊	Release 📌	Note 📖
Q1	Critical bug fixes for 1.5.0	Bug fixes	🟢 Completed	1.5.1
Q2	Performance fixes for the eSignet service using Mock IDA	Performance enhancement	🟢 Completed	1.6.1
Q2	Resource calculator for eSignet service with Mock IDA	Hardware and software resource calculator for eSignet Module	🟢 Completed	1.6.1
Q2	Add support for prefix and postfix customization for multiple handles in the eSignet UI	Added support for users to log in with their preferred login ID	🟢 Completed	1.6.1
Q2	Client management endpoint enhancement	Enhancement of the existing client management endpoint gives more flexibility to the replying part to customize eSignet as needed	🟢 Completed	1.6.1
Q2	Configurable consent screen	Added as part of client management endpoint enhancement	🟢 Completed	1.6.1
Q2	eSignet UI Dynamic Page Title	RP can configure the eSignet UI to have the desired page title & subtitle as per requirement.	🟢 Completed	1.6.1
Q3 ^↑	eKYC verification support in eSignet with MOSIP IDA	KYC-auth and KYC-exchange API enhancement in Authenticator Plugin	🟢 Completed	1.6.2	Moved from: Q2 to Q3
Q4 ^↓	Dynamic sign up UI	Dynamic sign up UI based on a predefined UI schema	🟢 Completed	1.7.0	Moved from: Q3 to Q4
Q4 ^↓	KBI form update: - Configuring labels Multiple input type support Multi lingual support	Enhancing the KBI form in eSignet UI to support multiple input type	🟢 Completed	1.7.0	Moved from: Q3 to Q4
Q4 ^➕	FAPI 2.0 Security Profile Compliance	Adding support in eSignet for: PAR Sender Constraint Token using Dpop Authorization Server Issuer Identification	🟢 Completed	1.7.0	Added New to roadmap
2026	Performance fixes for eSignet service with MOSIP ID	Performance enhancement	Moved to 2026	1.7.0
2026	Resource calculator eSignet with MOSIP ID	Software and hardware required for eSignet module	Moved to 2026	1.7.0
2026	eSignet Conformance Fixes	Fixes for the making eSignet adhere to Open ID standards & FAPI specification.	Moved to 2026	1.8.0
2026	Java 21 Migration	Mock Identity Service Sign up eSignet Service Plugins	Moved to 2026	1.8.0/2.0.0
2026	Face auth with eSignet	Support for face auth in eSignet using device camera	Moved to 2026
2026	Performance benchmarking of sign up with MOSIP ID repo using Mock ekyc verifier	eSignet performance benchmarking for eKYC based sign up flow	Moved to 2026
2026^↓	SSO Super App Support	Single Sign on support in eSignet for smooth integration with super apps	Moved to 2026
2026	Support for multi-factor authentication (MFA)	Enable multi-factor authentication (MFA) for enhanced security	Moved to 2026
2026	Access token/session management	Manage sessions to ensure secure and efficient user authentication	Moved to 2026
2026	CIBA Support	TBA	Moved to 2026
2026	eSignet Sign up - Timeout management in eKYC flow	TBA	Moved to 2026
2026^➕	Support OpenG2P to fetch user accounts from SPAR. Support for "resource" parameter in the authorization request Support for token exchange to give out PSUT to different clients	Support OpenG2P to fetch user accounts from SPAR.	Depriortized
2026	Consent Handling in eSignet for Child and Deceased	Support to Identify who is registering with RP and how to handle the auth for child and deceased	Depriortized
2026	Getting consent from an external party	Flexibility to seek consent from external party, if consent is disabled	Depriortized
2026	Support for multiple identity plugins	Support for multiple identity plugins in the eSignet module	Depriortized
2026	Identity Brokering / Federation Identity	Securely link a user's electronic identity across multiple identity management systems	Depriortized
2026	eSignet as ekYC verifier OIDC Provider verification Wallet based verification - Web wallet/phone wallet OIDC Provider based seeding Wallet based seeding - Web wallet/phone wallet	To be implemented with a federated identity feature	Depriortized
2026	Support for digital signatures using eSignet	Enable eSignet securely sign documents electronically	Depriortized
2026	Adding Passkey support for authentication	TBA	Depriortized
2026	Support the expired claims identification and initiate eKYC	TBA	Depriortized
2026	QR code Standardization	TBA	Depriortized

# Roadmap 2024 Q1: Jan'24 - Mar'24 Q2: Apr'24 - Jun'24 Q3: Jul'24 - Sep'24 Q4: Oct'24 - Dec'24 ## eSignet

Quarter	Feature	Status	Feature Details	Release Details
Q1	Password based authentication	Completed	Password based authentication	v1.3.0
Q1	Unified Login Portal, Inclusion of custom handle - Phone number	Completed	Unified-login-portal	v1.3.0
Q2	Support for Sunbird Integration Knowledge based Identification	Completed	Sunbird RC Integration	v1.4.0
Q2	Configuration capability for Knowledge based Identification Authenticator plugin Implementation for KBI and VC issuance plugin implementation Regex validations implementation for KBI	Completed	KBI Configuration	v1.4.1
Q3	Profile Management Conduct e-KYC on registered users, capability to confirm user identity through additional details.	Completed	L2 User flow - Enable user to complete e-KYC	v1.5.0
Q3 - Q4	eSignet Java 21 migration changes	Moved to 2025	Java 21 migration changes for eSignet	v1.4.3
Q3 - Q4	L1 performance fixes eSignet deployment fixes	Moved to 2025	L1 performance fixes	v1.4.2
Q4	Support for identity brokering It is capable of integrating with multiple ID providers for unified user authentication.	Moved to 2025	Support for identity brokering	v1.6.0
Q1-Q4	Re-consent Renew user consent for updates and modifications.	Moved to 2025	Re-Consent in MOSIP
Q1-Q4	UI enhancements Dynamic UI pages tailored to specific use cases- Verify / Link / Login.	Moved to 2025	eSignet UI change based on different use cases
Q1-Q4	Revamped QR code / wallet-based login using OpenID4VP & SIOP v2 for a secure and streamlined authentication experience.	Moved to 2025	Revamp the QR code / wallet based login using OpenID4VP or SIOP v2
Q1-Q4	Revocation of VC New ability to invalidate and manage credentials for security purposes.	Moved to 2025	Revocation of VC
Q1-Q4	Support for Key Manager - EDD and EC signature.	Moved to 2025	Key Manager - EDD and EC Signature
Q1-Q4	Verifiable Credential issuance Support for Verifiable Credential issuance formats like Self-Issued JWT (SDJWT), JSON Web Token (JWT), CBOR Web Token (CWT), JavaScript Object Notation (JSON), Credential Handler API (CHAPI), JSON Linked Data (JSONLD)	Moved to 2025	Support for multiple Verifiable Credential issuance formats
Q1-Q4	Support for pre-authorized code flow in OID4VCI Integrating pre-authorized code flow in OID4VCI framework to securely obtain and exchange Verifiable Credentials.	Moved to 2025	Support for pre-authorized code flow in OID4VCI
Q1-Q4	eSignet UI: FAPI 2.0 compliance analysis Capabilities to adapt to Financial-grade API (FAPI) 2.0 standards for enhanced security.	Moved to 2025	eSignet-UI: FAPI 2.0 compliance analysis
Q1-Q4	Consent Management End user can view, manage, and edit consented user information.	Moved to 2025	User Consent Management by end user
Q1-Q4	Support for Client-Initiated Backchannel Authentication (CIBA).	Moved to 2025	Additional authentication factor: CIBA
Q1-Q4	Support for WebAuthN API.	Moved to 2025	Additional authentication factor: WebAuthN
Q1-Q4	Support for 2-Factor authentication (2FA).	Moved to 2025	Additional authentication factor: TOTP using authenticator app
Q1-Q4	Support for Token Introspection.	Moved to 2025	Introspect Endpoint

# Releases Please refer below for all the latest release details ✨ ## Version: 1.8.0 * **Name**: eSignet * **Date:** 19th May, 2026 * [**Release Notes**](/home/esignet/roadmap-and-releases/versions/v1.8.0) ## Version: 1.7.0 * **Name**: eSignet * **Date:** 2nd December, 2025 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.7.0) ## Version: 1.6.2 * **Name**: v1.6.2 (Patch) * **Date:** 28th August, 2025 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.6.2) ## Version: 1.6.1 * **Name:** eSignet(Patch) * **Date:** 29th July, 2025 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.6.1) ## Version: 1.5.1 * **Name:** eSignet(Patch) * **Date:** 24th Feb, 2025 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.5.1) ## Version: 1.5.0 * **Name:** eSignet * **Date:** 23rd Jan, 2025 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.5.0) ## Version: 1.4.2 * **Name:** eSignet(Patch) * **Date:** 22nd Nov, 2024 * [**Release Notes**](/home/esignet/roadmap-and-releases/versions/v1.4.2) ## Version: 1.4.1 * **Name:** eSignet(Patch) * **Date:** 15th July, 2024 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.4.1) ## Version: 1.4.0 * **Name:** eSignet * **Date:** 23rd April, 2024 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.4.0) ## Version: 1.3.0 * **Name:** eSignet (Password based authentication) * **Date:** 23rd February, 2024 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.3.0) ## Version: 1.2.0 * **Name:** eSignet (VCI) * **Date:** 11th December, 2023 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.2.0) ## Version: 1.1.0 * **Name:** eSignet (consent registry) * **Date:** 22nd September, 2023 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.1.0) ## Version: 1.0.0 * **Name:** eSignet * **Date:** 14th April, 2023 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.0.0) ## Version: 0.9.0 * **Name:** IdP * **Date:** 8th January, 2023 * [**Release Notes**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v0.9.0) # v1.8.0 **Release Number:** v1.8.0 **Release Date:** 19th May, 2026 ### **Overview** eSignet v1.8.0 introduces significant infrastructure modernization and enhanced data privacy. This release upgrades the entire eSignet ecosystem from **Java 11 to** **Java 21** , delivering improved performance, better resource management via virtual threads, and long-term support. Additionally, the implementation of **RFC 7516** adds support for encrypted UserInfo responses, ensuring robust protection of sensitive user data in compliance with OIDC standards. ### **Major Highlights** #### **1. Migration to Java 21** We have upgraded eSignet and its core modules from Java 11 to Java 21. This upgrade applies to the following repositories: * [**eSignet**](https://github.com/mosip/esignet) * [**eSignet-Signup**](https://github.com/mosip/esignet-signup) * [**eSignet-mock-services**](https://github.com/mosip/esignet-mock-services) * [**eSignet-Plugin**](https://github.com/mosip/esignet-plugins) #### **2. Encrypted UserInfo Support (RFC 7516)** To further secure PII (Personally Identifiable Information), eSignet now supports returning the [**UserInfo response as an encrypted JSON (JWE)**.](https://docs.esignet.io/home/esignet/roadmap-and-releases/versions/pages/Tk3eiHfyOsvmzvqNZGRg#id-2.-supported-standards-and-rfcs) * **Enhanced Privacy:** Ensures that user attributes are only readable by the intended client application. * **Standard Compliance:** Implements **RFC 7516 (JSON Web Encryption)**, aligning eSignet with global security best practices for OpenID Connect (OIDC) providers. #### **Story Development** The following functional requirements and stories were completed in this release:

ID	Summary
ES-2744	eSignet: Encrypt UserInfo Response Using JWE (RFC 7516)
ES-2699	eSignet - Signup - Enhancement of Dynamic Sign-Up Form to Support Additional Input Field Types & Upload Capabilities
ES-2661	eSignet-signup - Java 11 to Java 21 Migration
ES-2316	eSignet Plugins- Java 11 to Java 21 Migration
ES-2315	eSignet Service - Java 11 to Java 21 Migration
ES-2068	esignet-mock-service - Java 11 to Java 21 Migration

#### **Bug Fixes** Several known issues from the previous release have been addressed to improve platform stability and performance. Please refer to the [link here](https://mosip.atlassian.net/issues?jql=%22Release%20Number%5BLabels%5D%22%20%3D%20eSignet_v1.8.0%20and%20issuetype%20%3D%20Bug) for the complete list of resolved issues.

ID	Summary
ES-2891	eSignet Signup (Docker Compose) – Authorization/OAuth Details Fails with “Unable to Connect to Redis”
ES-2887	eSignet Signup – Client Creation Fails Due to DB Schema Mismatch (additional_config jsonb Error)
ES-2800	eSignet-Sunbird: DOB value is altered during challenge validation, preventing user login to KBI
ES-2716	In Ui schema when email is marked as optional field by default its taking as mandatory field

#### **Known Issues** For a full list of identified issues currently being tracked, please refer to this [link](https://github.com/mosip/esignet/issues?q=label%3Aknown_issue_eSignet_1-8-0).

ID	Summary
ES-2914	Hardcoded khm language during verify-challenge in reset-password (signup-ui).
ES-2911	eSignet & Plugin Pods Failing to Start – KER-KMA-001 PKCS11 Initialization Error (ProgressDeadlineExceeded)
ES-2905	eSignet Mock Services – Deployment Fails Due to Missing active_profile_env Property
ES-2877	eSignet-MOSIP & MOCK: User Login Fails When Global OpenID Profile is Set to FAPI 2.0 Due to Mandatory PKCE Requirement
ES-2874	Sunbird KBI Login – CAPTCHA Not Displayed and Login Fails with invalid_transaction Error
ES-2873	eSignet Signup – Registration Fails Even When UI Renders Correctly as Per Updated Schema
ES-2836	eSignet: JWE automation fails when client encryption public key is missing or invalid

### **Repositories Released** | Repository | Version/Tag | | --------------------- | ---------------------------------------------------------------------- | | eSignet | [v1.8.0](https://github.com/mosip/esignet/tree/v1.8.0) | | eSignet-Signup | [v1.4.0](https://github.com/mosip/esignet-signup/tree/v1.4.0) | | eSignet-mock-services | [v0.13.0](https://github.com/mosip/esignet-mock-services/tree/v0.13.0) | | eSignet-Plugin | [v1.4.0](https://github.com/mosip/esignet-plugins/tree/v1.4.0) | | mosip-sdk | [0.10.2](https://github.com/mosip/mosip-sdk/tree/v0.10.2) | | mosip-onboarding | [v1.3.1](https://github.com/mosip/mosip-onboarding/tree/v1.3.1) | ### **Compatible Modules** **eSignet compatibility with MOSIP** | Module/Repo | Compatible Version | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------- | | PMS | [1.2.2.3](https://github.com/mosip/partner-management-services/tree/v1.2.2.3) | | IDA |

1.2.1.0
1.3.x (for identity assurance 1.0 support)

| **eSignet compatibility with Sunbird** | Module/Repo | Compatible Version | | ----------- | --------------------------------------------------------------------------- | | Sunbird | [v2.0.0-rc3](https://github.com/Sunbird-RC/sunbird-rc-core/tree/v2.0.0-rc3) | **eSignet Signup compatibility with MOSIP** | Module/Repo | Compatible Version | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | ID Repository |

1.2.1.0

1.3.x (for identity assurance 1.0 support)

| | otpmanager | [1.2.0.1](https://github.com/mosip/otp-manager/tree/v1.2.0.1) | | kernel-notification-service | [1.2.0.1](https://github.com/mosip/commons/tree/v1.2.0.1/kernel/kernel-notification-service) | | auditmanager | [1.2.0.1](https://github.com/mosip/audit-manager/tree/v1.2.0.1) | ### **Database Changes** **eSignet** * Please [refer here](https://github.com/mosip/esignet/blob/master/db_upgrade_script/mosip_esignet/sql/1.7.1_to_1.8.0_upgrade.sql) for DB upgrade script * Please [refer here](https://github.com/mosip/esignet/blob/master/db_upgrade_script/mosip_esignet/sql/1.7.1_to_1.8.0_rollback.sql) for DB rollback script **eSignet-mock-services** * Please [refer here](https://github.com/mosip/esignet-mock-services/blob/master/db_upgrade_script/mosip_mockidentitysystem/sql/0.12.0_to_0.13.0_upgrade.sql) for DB upgrade script * Please [refer here](https://github.com/mosip/esignet-mock-services/blob/master/db_upgrade_script/mosip_mockidentitysystem/sql/0.12.0_to_0.13.0_rollback.sql) for DB rollback script ### **Configuration Changes** **eSignet** * The properties listed below are newly added to the eSignet default configuration: * `mosip.esignet.public-key-hash.fields={ 'RSA': { 'n' }, 'EC': { 'x', 'y' } } ## which fields to hash for uniqueness` * The property names are updated as listed below: | Deprecated Property Name | Updated Property Name | | ------------------------ | ---------------------------- | | `spring.redis.host` | `spring.data.redis.host` | | `spring.redis.port` | `spring.data.redis.port` | | `spring.redis.password` | `spring.data.redis.password` | For a comprehensive view of all configuration properties in eSignet, please [refer here](https://github.com/mosip/esignet/blob/v1.8.0/esignet-service/src/main/resources/application-default.properties). ### Documentation **API Documentation** * [**eSignet API (v1.8.0)**](https://github.com/mosip/esignet/blob/master/docs/esignet-openapi.yaml) * [**Signup API (v1.4.0)**](https://github.com/mosip/esignet-signup/blob/master/docs/esignet-signup-openapi.yaml) **Integration Guides** * [**eSignet Integration Guide**](https://docs.esignet.io/esignet-authentication/develop/integration) * [**Signup Integration Guide**](https://docs.esignet.io/esignet-signup/develop/integration-guide-signup-portal) **End User Guides** * [**eSignet End User Guide**](https://docs.esignet.io/esignet-authentication/test/end-user-guide) * [**Signup End User Guide**](https://docs.esignet.io/esignet-signup/test/end-user-guide) [**QA Report**](/home/esignet/roadmap-and-releases/versions/v1.8.0/test-report) # Test Report ## Introduction The eSignet testing scope includes the validation of authentication, authorization, identity verification, consent management, token generation, OpenID Connect (OIDC) flows, partner integration, and user onboarding workflows across supported authentication methods and external identity systems. eSignet is a modular and standards-based digital identity authentication solution that supports secure and configurable login journeys using OTP, biometrics, wallet-based authentication, and trusted identity providers. ### Overview and Scope The scope of testing defines the boundaries, functionalities, and features that will be tested for the eSignet platform. This ensures comprehensive validation of critical authentication, authorization, consent, and identity verification workflows while clearly identifying what is included and excluded from testing. Functional Features: Signup Portal with Mock Plugin, MOSIP ID – QABASE, and MOSIP ID – CRE, Login with OTP using Phone Number, UIN/VID, and Email, Login with Password Authentication, Forgot Password Functionality, Login with Biometrics Authentication, Login with KBI (Knowledge-Based Identification), Identity Verification Process for L1 and L2 Flows, Sunbird Plugin Integration, DPoP (Demonstration of Proof-of-Possession) Validation, PAR (Pushed Authorization Request) Validation, Dynamic Signup Schema Validation, Deployment Testing for eSignet and Signup Modules, FAPI 2.0 Compliance Validation, Docker Compose Compatibility Testing across Windows, macOS, and Linux Operating Systems, OIDC Authorization Flow with PKCE, Token Generation & Validation, Consent Management, Claims Management, User info API Validation, Session Management, API Security Validation, Logout Flow, Audit Logging, Verified Claims Support, and Multi-factor Authentication workflows. ### Cross-Platform Support * Multilingual: eSignet with 6 languages (English/Khmer/Hindi/Kannada/Arabic/Tamil) * Multilingual: Signup with 2 languages (English/Khmer) * Multi-Browser: Edge, Firefox, Chrome * Devices: Windows, Mac, Tablet, Mobile * Testing Types: Sanity, Regression Testing and Integration Testing * Cross-browser and cross-device compatibility testing ### Test Approach The scope of testing is to verify fitment to the specification from the perspective of * Functionality * Combination * UI Automation * API Automation * Library verification ## Test Organization **Table**: Test Organization

Name	Functional Role	Responsibilities
Ragini Krishnamurthy	Manager	Defining test strategy, managing QA activities, and ensuring overall product quality.
Chandra Sekhar	Lead	Leading the test team, planning and executing tests, and ensuring timely delivery of quality results.
Prathmesh Jadhav Rohith Goud	Test engineers	Designing and executing test cases, performing functional and regression testing, validating eSignet authentication and signup workflows, verifying login and identity verification functionalities, logging and tracking defects, validating fixes, and ensuring overall application quality, security, and compliance standards.

Name

Functional Role

Responsibilities

Ragini Krishnamurthy

Manager

Defining test strategy, managing QA activities, and ensuring overall product quality.

Chandra Sekhar

Lead

Leading the test team, planning and executing tests, and ensuring timely delivery of quality results.

Prathmesh Jadhav
Rohith Goud

Test engineers

Designing and executing test cases, performing functional and regression testing, validating eSignet authentication and signup workflows, verifying login and identity verification functionalities, logging and tracking defects, validating fixes, and ensuring overall application quality, security, and compliance standards.

### Test Planning This Test Plan outlines the testing approach, scope, resources, and schedule for the eSignet platform and Signup modules. The objective is to ensure that all functional, integration, security, and non-functional requirements are validated with high quality before release. * Validate end-to-end functionality of eSignet authentication, authorization, and signup workflows. * Ensure system stability across supported browsers, operating systems, plugins, and environments. * Verify integrations with dependent systems, identity providers, and authentication services. * Validate OIDC, DPoP, PAR, and FAPI 2.0 compliance workflows. * Identify and mitigate risks early through functional, regression, integration, and deployment testing. * Ensure compatibility of Docker Compose setup across Windows, macOS, and Linux operating systems. * Validate identity verification workflows for L1 and L2 authentication flows. * Verify secure login mechanisms including OTP, Password, Biometrics, and KBI authentication methods. ### Sanity Scenarios Verified Sanity testing will be performed to ensure basic application stability before detailed test execution. The following high-level sanity scenarios will be verified: * Application accessibility and successful login across supported authentication methods and environments. * Signup portal accessibility and successful user registration using Mock plugin and MOSIP ID integrations. * Login validation using OTP (Phone Number, UIN/VID, and Email). * Login validation using Password authentication. * Forgot Password workflow validation. * Basic biometric authentication validation using Mock ID and MOSIP ID. * KBI (Knowledge-Based Identification) login validation. * Identity verification workflow validation for L1 and L2 flows. Only upon successful completion of sanity testing will the build be accepted for full regression and integration testing. ### Test Environment * [https://healthservices.esqa2.mosip.net](https://healthservices.esqa2.mosip.net/) – mock environment * (qa11new)- mosipid-qabase environment. * - mosipid-CRE environment. * - Sunbird environment. **Table**: Test Environment -images


Tested with Components on esqa2 env
docker.io/mosipqa/apitest-esignet-signup:1.4.x
docker.io/mosipqa/apitest-esignet:1.8.x
docker.io/mosipqa/esignet-with-plugins:1.8.x
docker.io/mosipqa/mock-identity-system:0.13.x
docker.io/mosipqa/mock-relying-party-service:0.13.x
docker.io/mosipid/captcha-validation-service:0.1.0-beta.1
docker.io/mosipid/config-server:1.1.2
docker.io/mosipid/kafka:3.2.1-debian-11-r9
docker.io/mosipid/keycloak-init:1.2.0.2
docker.io/mosipid/kibana:7.17.2-debian-10-r0
docker.io/mosipid/minio-client-util
docker.io/mosipid/minio-client-util:latest
docker.io/mosipid/minio:2022.2.7-debian-10-r0
docker.io/mosipid/mock-smtp:1.0.0
docker.io/mosipid/mosip-artemis-keycloak:1.2.0.1
docker.io/mosipid/os-shell:12-debian-12-r46
docker.io/mosipid/partner-management-service:1.2.2.3
docker.io/mosipid/policy-management-service:1.2.2.3
docker.io/mosipid/postgres-init:1.2.0.1
docker.io/mosipid/postgresql:14.2.0-debian-10-r70
docker.io/mosipid/redis:7.0.5-debian-11-r25
docker.io/mosipid/softhsm:v2
docker.io/mosipid/zookeeper:3.8.0-debian-11-r30
docker.io/mosipint/elasticsearch:7.17.2-debian-10-r4
docker.io/mosipqa/mock-relying-party-ui:0.13.x
docker.io/mosipqa/oidc-ui:1.8.x
docker.io/mosipqa/partner-onboarder:1.3.x-beta.2
docker.io/mosipqa/postgres-init:develop
docker.io/mosipqa/signup-ui:1.4.x
docker.io/mosipqa/signup-with-plugins:1.4.x
docker.io/mosipqa/uitest-signup:1.4.x
docker.io/mosipqa/uitest-signup:release-1.4.x
mosipid/config-server:1.1.2
mosipid/keycloak-init:1.2.0.2
mosipid/postgres-init:1.2.0.1
mosipid/softhsm:v2
mosipqa/apitest-esignet-signup:1.4.x
mosipqa/apitest-esignet:1.8.x
mosipqa/postgres-init:develop

### Test Execution Report Below are the test metrics by performing functional testing. 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. ### Test case execution summary The Test Case Execution Summary section provides a detailed overview of the total test cases executed across platforms, including pass, fail, and skip counts. It includes a table summarizing results and observations on execution pass rates. **Table**: Test Case - UI based verification

Total	Passed	Failed	Skipped (N/A)
1341	1320	21	0
Test Rate: 100% with Pass Rate: 98.43%

**Table**: Test Case – API based verification (API):

Total	Passed	Failed	Skipped (N/A)
2215	2140	18	57
Test Rate: 97.43% with Pass Rate: 99.17%

{% hint style="info" %} Note: NA - 57 Test Cases which are descoped scenarios/not developed feature {% endhint %} ### Automation Results This section provides a summary of the automated test execution. It shows the pass, fail, and known issues from the automated test suite. **Table**: Automation Execution Result -API Testrig – mockid environment

Module	Total	Passed	Failed	Skipped (N/A)	Ignored
eSignet	1339	791	0	0	548	0
Signup	670	640	0	0	30	0
Test Rate: 100% with Pass Rate: 100%

{% hint style="info" %} Note: 548 test cases in esignet and 30 test cases in signup related to the MOSIP ID plug-in are currently being ignored. {% endhint %} **Table**: Automation Execution Result -API Testrig – mosipid-qabase environment

Module	Total	Passed	Failed	Skipped (N/A)	Ignored
eSignet	1339	1098	0	0	171	21
Signup	670	653	0	0	17	0
Test Rate: 100% with Pass Rate: 100%

{% hint style="info" %} Note: 171 test cases in esignet and 17 test cases in signup related to the mock plug-in are currently being ignored. {% endhint %} **Table**: Automation Execution Result -API Testrig – mosipid-CRE environment

Module	Total	Passed	Failed	Skipped (N/A)	Ignored
eSignet	1339	1098	32	10	171	21
Signup	670	398	60	195	17	0
Test Rate: 89.80% with Pass Rate: 94.2%

{% hint style="info" %} Note: Failures in esignet and signup are due to L2 flow is not supported in esignet and signup and some test cases are failing due to credential movement is taking longer time. {% endhint %} {% hint style="info" %} Note- API flow is tested through automation for both positive and negative scenarios, while test cases that are not automated are tested manually. {% endhint %} **Table**: Automation Execution Result - UI Automation

Total	Passed	Failed	Skipped (N/A)	Ignored	Known issues
17	9	0	0	0	8
Test Rate: 100% with Pass Rate: 100%

### 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 failed test cases. (Number of failed tests / Total number of test cases executed) x 100 ## Test Execution Report Verification is performed on various configurations as mentioned below * Default configuration with verified configuration for 3 Lang (English/Arabic/French) ## Browser compatibility evaluations **Table**: Browser versions tested on desktop/laptop

Sl.No	Browser	Versions
1	Chrome	Version 147.0.7727.138
2	Firefox	Version 150.0.2 (64-bit)
3	Edge	Version 147.0.3912.72
4	Safari	Version 18.6 (20621.3.11.11.3

## Feature Health

### Known Issues Metrics This section focuses on a separate category of issues that are known but not addressed in the current release. It provides a count and severity distribution for these defects across releases. **Table**: Defect Metrics for the known issues
Blocker: 2 deployment bugs to be tested in v1.8.1 deployment (v1.8.0 testing is already completed). Critical: 1 critical bug will be coming up as story in 1.8.1 release. ## Sonar Report * **esignet**:

* **esignet-signup**:

* **esignet-mock-service**:

* **esignet-plugins(mock)**:

* **esignet-plugins(mosipid)**:

* **esignet-plugins(sunbird)**:

### Conclusion The eSignet application has been successfully validated in the esqa2 environment, with all critical functionalities performing as expected. Sanity, regression, and integration testing were completed within the defined scope. * Based on the successful test execution and results, QA approves the build for release. ### QA Approval The build has met all the defined exit criteria and is recommended for release based on the following: * Test Case Execution: All planned test cases have been executed successfully. * Story and Defect Closure: All user stories are completed, and no critical or high-severity defects remain open. * Automation Reports: API-Testrig and UI automation execution reports have been reviewed and approved. * Documentation Sign-off: All required test and release documentation has been reviewed and signed off. * Test Environment Stability: The test environment remained stable throughout the testing cycle. **Table**: Report is signed off details | Name | Functional Role | Responsibilities | | ---------------- | --------------- | ----------------------------------------------------------------------------------------------------- | | Ragini Krishna | Manager | Defining test strategy, managing QA activities, and ensuring overall product quality. | | Chandra Sekhar N | Lead | Leading the test team, planning and executing tests, and ensuring timely delivery of quality results. | ### Appendix This includes additional reference information for the report. It contains a history of document versions. **Appendix A**: Versions

Version	Date	Author	Reviewers
V1.0	07/05/2026	Prathmesh Jadhav	Ragini Krishna

### Document History It outlines the strategy used to ensure a comprehensive evaluation.

Version	Author	Date	Review	Affected Sections
V1.0	Prathmesh Jadhav	07/05/2026	Ragini Krishnamurthy

Refer [**here**](https://github.com/mosip/test-management/tree/master/e-signet/1.8.0) to get more details on reports.
# v1.7.1 **Release Number:** v1.7.1 (Patch) **Release Date:** 19th December, 2025 ### **Overview** We are pleased to announce the release of [eSignet v1.7.1](https://github.com/mosip/esignet/tree/v1.7.1), a patch release focused exclusively on addressing critical functional issues identified in earlier versions.\ This release improves stability and correctness across UI schema handling, KBI authentication flows, and deployment-related assets, ensuring a smoother and more reliable experience for integrators and deployers. ### **Major Highlights** #### **Critical Bug Fixes** * Fixed an issue in the UI schema where the email field was treated as mandatory even when configured as optional. * Resolved a problem where KBI login in mock services failed when CAPTCHA was enabled. * Addressed multiple issues related to deployment documentation, improving accuracy and clarity. * Fixed issues in partner onboarding scripts to ensure smoother setup and execution. ### **Bug Fixes** Several known issues from the previous release have been addressed to improve platform stability and performance. Please refer to the [link here](https://mosip.atlassian.net/issues?jql=%22Release%20Number%5BLabels%5D%22%20%3D%20eSignet_v1.7.1\&selectedIssue=MOSIP-43960) for the complete list of resolved issues.

Jira ID	Summary
MOSIP-43960	Partner onboarder issue in esignet-signup
MOSIP-43958	Issue in partner onboarder esignet .
MOSIP-43957	Update keycloak init scripts in esignet-signup
MOSIP-43956	Update readme for partner-onboarding/esignet
ES-2738	Deployment : esignet readme does not contain delete steps Please Mention delete steps in readme
ES-2737	Deployment : softhsm for esignet is getting deployed in esignet ns but in the delete-all.sh its searching for softhsm which needs to be updated
ES-2725	eSignet- mosipid: “Unsupported language” error displayed on Forgot Password page when using Khmer language
ES-2719	Fix content for wallet_header on WLA login page
ES-2716	In Ui schema when email is marked as optional field by default its taking as mandatory field
ES-2710	Inji logo is not updated in esqa2
ES-2709	KBI login in mock is not working when captcha is enabled
ES-2707	eSignet - aud_claim in client-assertion is not accepting any three of par endpoint, token endpoint and issuer identifier.
ES-2578	FAPI 2.0 Compliance - Server accepted a cipher that is not on the list of permitted ciphers
ES-2375	Unable to create OIDC client from PMS endpoint from postman
ES-2373	In Android web browser, user can enter as many character as they want, it is not restricted by max length
ES-2310	Datatype mismatch in SBI Auth capture request
ES-2237	For the first capture the previousHash should be the SHA256 hash of an empty UTF-8 string

### **Known Issues** Please [refer here](https://mosip.atlassian.net/issues?jql=issuetype%20%3D%20Bug%20and%20labels%20%3D%20known_issue_eSignet_1.7.1\&selectedIssue=ES-2761) for full list of known issues.

Jira ID	Summary
MOSIP-44103	Partner onboarding fails due to existing records with no automated cleanup
ES-2761	eSignet-MOSIP & MOCK: When the user lands on the Network Error page, the browser Back and Forward buttons do not navigate to the previous or next pages.
ES-2757	eSignet-deployment: Missing Deployment Instructions for /mock-relying-party-ui, mock-relying-party-service in Documentation
ES-2756	eSignet-deployment: eSignet-with-Plugins Installation Script Missing OIDC Setup Steps
ES-2755	eSignet-deployment: End-User URL Not Clearly Defined for Cross-Cluster Module Dependencies
ES-2754	eSignet-Signup MOCK : Privacy Policy link navigates away from signup page instead of opening in new tab
ES-2734	Support both object and array for verified_claims request parameter

### **Repositories Released** | Repository | Tag | | -------------- | ------------------------------------------------------------- | | esignet | [v1.7.1](https://github.com/mosip/esignet/tree/v1.7.1) | | esignet-signup | [v1.3.1](https://github.com/mosip/esignet-signup/tree/v1.3.1) | | mosip-sdk | [v0.10.1](https://github.com/mosip/mosip-sdk/tree/v0.10.1) | ### **Compatible Modules** #### eSignet with MOSIP compatibility matrix

Module/Repo	Compatible Version
PMS	1.2.2.1
IDA	1.2.1.0 1.3.x - Future release (For identity assurance 1.0 support)

#### eSignet with Sunbird compatibility matrix | Module/Repo | Compatible Version | | ----------- | --------------------------------------------------------------------------- | | Sunbird | [v2.0.0-rc3](https://github.com/Sunbird-RC/sunbird-rc-core/tree/v2.0.0-rc3) | #### Signup with MOSIP compatibility matrix

Module/Repo	Compatible Version
ID Repository	1.2.1.0 1.3.x Future release (for identity assurance 1.0 support)
otpmanager	1.2.0.1
kernel-notification-service	1.2.0.1
auditmanager	1.2.0.1

### **Documentation** **API Documentation** * [**eSignet API (v1.7.1)**](https://github.com/mosip/esignet/blob/master/docs/esignet-openapi.yaml) * [**Signup API (v1.3.1)**](https://github.com/mosip/esignet-signup/blob/master/docs/esignet-signup-openapi.yaml) **Integration Guides** * [**eSignet Integration Guide**](https://docs.esignet.io/esignet-authentication/develop/integration) * [**Signup Integration Guide**](https://docs.esignet.io/esignet-signup/develop/integration-guide-signup-portal) **End User Guides** * [**eSignet End User Guide**](https://docs.esignet.io/esignet-authentication/test/end-user-guide) * [**Signup End User Guide**](https://docs.esignet.io/esignet-signup/test/end-user-guide) [**QA Report**](/home/esignet/roadmap-and-releases/versions/v1.7.1/test-report) # Test Report ## 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, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation 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 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 - which 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 creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which 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** - * eSignet with 6 languages (English/Khmer/Hindi/Kannada/arabic/tamil) * Signup with 2 languages (Khmer/English) ### Main features tested * Signup Portal with mock ID * Login with Password with mock ID * Forgot Password with mock ID * Login with OTP and biometrics with mock ID * Login with KBI with mock ID * Identity verification process (L2 flow) with mock ID and MOSIP ID * Identity verification process (L1 flow) with CRE * Wallet login performed (CRE) for release environment * Signup Portal with MOSIP IDA * Login with Password with MOSIP IDA * Forgot Password with MOSIP IDA * Login with OTP and biometrics with MOSIP IDA * Sunbird Plugin with KBI login * DPoP and PAR in all plugins * Deployment testing on eSignet & signup-mosipid-qabase plugin * FAPI 2.0 compliance ### Features not in scope * UI Automation for Signup/eSignet ## Feature Health

## Test execution statistics ## Functional test results Below are functional testing metrics using mock MDS, mock Auth, and mock ABIS. Black-box testing based on specifications was performed across individual modules and integrations. Test data aligned to user stories; results were verified via UI. Coverage includes GUI, system, end-to-end flows across multiple languages and configurations. Testing simulated multiple identity schema and corresponding UI schema configurations. | Total | Passed | Failed | Skipped | | :---: | :----: | :----: | :-----: | | 3443 | 3372 | 36 | 35 | Test Run Rate: 98% • Pass Rate: 98% **Note**: In API-based testing, 35 test cases were marked as skipped because they were not automated and cannot be executed using Postman. **Here is the detailed breakdown**: ### API Based Testing — eSignet | Total | Passed | Failed | Skipped | | :---: | :----: | :----: | :-----: | | 2192 | 2139 | 18 | 35 | ### UI Based Testing | Total | Passed | Failed | Skipped | | :---: | :----: | :----: | :-----: | | 1251 | 1233 | 18 | 0 | ### API TestRig — eSignet and Signup (Mock ID) **API Based TestRig — eSignet** | Total | Passed | Failed | Skipped | Ignored | Known Issues | | ----: | -----: | -----: | ------: | ------: | -----------: | | 1273 | 729 | 0 | 0 | 544 | 0 | **API Based TestRig — eSignet Signup**

Total	Passed	Failed	Skipped	Ignored	Known Issues
665	635	0	0	30	0

**Note**: 544 test cases in eSignet and 30 test cases in signup related to the MOSIP ID plug-in are currently being ignored. ### API TestRig — eSignet and Signup (MOSIP — CRE) **API Based TestRig — eSignet** | Total | Passed | Failed | Skipped | Ignored | Known Issues | | :---: | :----: | :----: | :-----: | :-----: | :----------: | | 1273 | 1091 | 8 | 8 | 166 | 0 | **API Based TestRig — eSignet Signup** | Total | Passed | Failed | Skipped | Ignored | Known Issues | | :---: | :----: | :----: | :-----: | :-----: | :----------: | | 665 | 405 | 53 | 190 | 17 | 0 | **Note**: * 61 Failures in eSignet; in signup, 198 are skipped due to L2 flow not being supported in eSignet and signup. **API TestRig results for eSignet and Signup with MOSIP — qa-base**: **API Based TestRig — eSignet** | Total | Passed | Failed | Skipped | Ignored | Known Issues | | :---: | :----: | :----: | :-----: | :-----: | :----------: | | 1273 | 1107 | 0 | 0 | 166 | 0 | **API Based TestRig — eSignet Signup** | Total | Passed | Failed | Skipped | Ignored | Known Issues | | :---: | :----: | :----: | :-----: | :-----: | :----------: | | 665 | 648 | 0 | 0 | 17 | 0 | **Note**: 166 test cases in eSignet and 17 test cases in signup related to the mock plug-in are currently being ignored. **API TestRig results for eSignet and Signup with Sunbird**: **API Based TestRig — Sunbird** | Total | Passed | Failed | Skipped | Ignored | Known Issues | | :---: | :----: | :----: | :-----: | :-----: | :----------: | | 1273 | 93 | 0 | 0 | 1180 | 0 | **Note**: mock and mosipid plugin test cases are being ignored. ### 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. Key tracking metrics: * Passed Test Case Coverage: (Number of passed tests / Total executed) × 100 * Failed Test Case Coverage: (Number of failed tests / Total executed) × 100 ### Sonar Report | Repo | Branch | Release (POM) | Coverage (≥80%) | Reliability | Security | Hotspots | Duplications (<3%) | | :-------------------------------------: | :------------: | :------------: | :-------------: | :---------: | :------: | :------: | :----------------: | | eSignet | release-1.7.x | release-1.7.1 | 84.8 | 0 | 0 | 0 | 0% | | eSignet Signup | release-1.3.x | release-1.3.1 | 81.9 | 0 | 0 | 0 | 0% | | esignet-mock-services | release-0.12.x | release-0.12.1 | 85.2 | 0 | 0 | 0 | 0% | | esignet-plugins (mock-plugin) | release-1.3.x | release-1.3.4 | 83.0 | 0 | 0 | 0 | 2.9% | | esignet-plugins (mosip-identity-plugin) | release-1.3.x | release-1.3.4 | 69.1 | 0 | 0 | 0 | 0% | | esignet-plugins (sunbird-rc-plugin) | release-1.3.x | release-1.3.4 | 83.0 | 0 | 0 | 0 | 0% | Refer to the github link for more on reports [**here**](https://github.com/mosip/test-management/tree/master/e-signet/1.7.1). # v1.7.0 **Release Number:** v1.7.0 **Release Date:** 2nd December, 2025 ## **Overview** We’re excited to announce the release of [**eSignet v1.7.0**](https://github.com/mosip/esignet/tree/release-1.7.x), a feature-rich upgrade over v1.6.1 that introduces major advancements in security, enhanced user interaction flexibility, and improved deployment efficiency. This release includes full support for the [**FAPI 2.0 Security Profile**](https://docs.esignet.io/esignet-authentication/features#fapi-2.0-security-profile), implemented through multiple industry-standard RFCs, and brings dynamic, schema-driven UI enhancements for both Signup and KBI authentication—while ensuring complete backward compatibility with existing authentication flows. ## **Major Highlights** ### **New Features** #### **Support for FAPI 2.0 Security Profile** eSignet now [implements key RFCs required for FAPI 2.0 compliance](https://docs.esignet.io/esignet-authentication/features#fapi-2.0-security-profile), strengthening security and interoperability: * **Pushed Authorization Request (PAR)** – A new PAR endpoint is introduced to support secure, tamper-resistant authorization requests. * **Demonstration of Proof of Possession (DPoP)** – Adds cryptographic proof-of-possession for access tokens, preventing token replay attacks. * **Authorization Server Issuer Identification** – Enhances security by enabling the ‘Authorization Server’ to uniquely identify itself during authorization flows; includes updates to configurations in [oauth authorization server well-known](/home/esignet/esignet-authentication/develop/configuration/.well-known/oauth-configuration). {% hint style="success" %} **Tips**: **eSignet now supports FAPI 2.0 security profile.** However, enforcement of the FAPI 2.0 security profile is **client-configurable**. Each client can choose whether or not to enable FAPI 2.0 security profile for their integrations.\ If a client does **not** enforce the FAPI 2.0 security profile, their authentication flows will continue to work **seamlessly without any change**. {% endhint %} ### **Enhancements** #### **Dynamic Schema-Driven Signup UI** The Signup UI has been improved and [can now be generated dynamically based on a backend-driven UI schema](https://docs.esignet.io/esignet-signup/features#dynamic-signup-form-schema-driven-ui).\ This leverages a JSON form-builder library for improved flexibility and faster configuration changes. #### **Dynamic Schema-Driven KBI Authentication UI** [The KBI authentication UI](https://docs.esignet.io/esignet-authentication/features#supported-authentication-methods) is now also fully dynamic and powered by the same schema-based JSON form builder, enhancing consistency and maintainability. #### **Improved Deployment Scripts** Deployment scripts for the eSignet service have been refined to simplify setup, reduce configuration overhead, and ensure smoother deployments across environments. ### **Bug Fixes** Several known issues from the previous release have been addressed to improve platform stability and performance. Please refer to the link [here](https://mosip.atlassian.net/issues/?jql=issuetype%20%3D%20Bug%20and%20%22Release%20Number%5BLabels%5D%22%20%3D%20eSignet_v1.7.0) for the complete list of resolved issues.

Jira ID	Summary
ES-2702	Deployment : Not able to complete the sanity, after registration getting the error "Unable to process. Please try again".
ES-2691	Deployment : signup captcha is not working, throwing an error "The captcha you entered is incorrect. Please try again".
ES-2683	Deployment : esignet image is not getting updated to mosipqa/esignet-with-plugins:1.7.x its taking develop branch image.
ES-2678	Deployment : In init_values.yaml branch is pointing to develop branch instead of release-1.7.x.
ES-2677	Deployment : Still keyclock postgres image is pointing to bitnami.
ES-2665	Docker-compose : In mock-relying-party-portal-fapi2-docker-compose.yml volumes: are not given.
ES-2659	Linux : Docker Compose fails to start containers — “failed to extract layer” error.
ES-2632	eSignet-MOSIP: User is unable to complete eKYC verification in MOSIP-ID plugin.
ES-2629	esignet mock: Captcha is enabled but its not displayed in UI, but checking for captcha in UI and we are getting this error while signing up.
ES-2588	In mock : KBI Login is not working.
ES-2577	eSignet-MOCK: fetchUserInfo fails with error "Failed to get the User Info." when DPoP and PAR are disabled.
ES-2574	eSignet-MOSIP-ID: User is unable to register in signup-mosipid-qabase.
ES-2556	JWKS.json returning incorrect userinfo signing certificate.

### Known Issues Please refer [here](https://mosip.atlassian.net/issues/?jql=issuetype%20%3D%20Bug%20and%20labels%20%3D%20known_issue_eSignet_1.7.0) for full list of known issues.

Jira ID	Summary
ES-2716	In UI schema when email is marked as optional field by default its taking as mandatory field.
ES-2709	KBI login in mock is not working when captcha is enabled
MOSIP-43956	Update documentation for partner-onboarding/esignet.
MOSIP-43957	Update keycloak init scripts in esignet-signup.
MOSIP-43958	Issue in partner on boarder script for eSignet.
MOSIP-43960	Partner on boarder script issue in esignet-signup.

### Story Development

Story ID	Description
ES-2589	eSignet - Signup - Add a new endpoint to support the multi-part data.
ES-2429	Signup Module - Signup UI registration Form - Add support to capture the face photo for the user.
ES-2379	Authorization Server Issuer Identification for FAPI 2.0 Compliance.
ES-2346	Add Support for additional Config in client management endpoint.
ES-2333	Push Authorization request (PAR) - FAPI 2.0 Compliance - Add a new authorize url to process request with clientid and request uri.
ES-2296	Push Authorization request (PAR) - FAPI 2.0 Compliance - New endpoint development to initiate PAR flow.
ES-2297	Sender constrained tokens using DPOP for FAPI 2.0 security profile compliance.
ES-2058	Enhance KBI form in eSignet UI.
ES-1644	Registration form on the eSignet sign-up page should dynamically adjust its fields and layout based on a predefined UI schema.

### Repositories Released | Repository | Tag | | --------------------- | ---------------------------------------------------------------------- | | esignet | [v1.7.0](https://github.com/mosip/esignet/tree/v1.7.0) | | esignet-signup | [v1.3.0](https://github.com/mosip/esignet-signup/tree/v1.3.0) | | esignet-mock-services | [v0.12.0](https://github.com/mosip/esignet-mock-services/tree/v0.12.0) | | esignet-plugins | [v1.3.4](https://github.com/mosip/esignet-plugins/tree/v1.3.4) | ### Compatible Modules #### eSignet compatibility with MOSIP | Module/Repo | Compatible Version | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------- | | PMS | [1.2.2.1](https://github.com/mosip/partner-management-services/tree/v1.2.2.1) | | IDA |

1.2.1.0
1.3.x (for identity assurance 1.0 support)

| #### eSignet compatibility with Sunbird | Module/Repo | Compatible Version | | ----------- | --------------------------------------------------------------------------- | | Sunbird | [v2.0.0-rc3](https://github.com/Sunbird-RC/sunbird-rc-core/tree/v2.0.0-rc3) | #### eSignet Signup compatibility with MOSIP | Module/Repo | Compatible Version | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | ID Repository |

1.2.1.0
1.3.x (for identity assurance 1.0 support)

| | otpmanager | [1.2.0.1](https://github.com/mosip/otp-manager/tree/v1.2.0.1) | | kernel-notification-service | [1.2.0.1](https://github.com/mosip/commons/tree/v1.2.0.1/kernel/kernel-notification-service) | | auditmanager | [1.2.0.1](https://github.com/mosip/audit-manager/tree/v1.2.0.1) | ### DB Changes * **eSignet Mock Identity System**: * Please refer the [link here](https://github.com/mosip/esignet-mock-services/blob/master/db_upgrade_script/mosip_mockidentitysystem/sql/0.11.2_to_0.12.0_upgrade.sql) for the DB upgrade script * Please refer the [link here](https://github.com/mosip/esignet-mock-services/blob/master/db_upgrade_script/mosip_mockidentitysystem/sql/0.11.2_to_0.12.0_rollback.sql) for the DB rollback script ### Config Changes * **eSignet**: The properties listed below are newly added to the eSignet default configuration. For a comprehensive view of all configuration properties in eSignet, please [refer here](https://github.com/mosip/esignet/blob/master/esignet-service/src/main/resources/application-default.properties). * `mosip.esignet.par.expire-seconds=60` * `mosip.esignet.par.request-uri.prefix=urn:ietf:params:oauth:request_uri:` * `mosip.esignet.dpop.clock-skew=10` * `mosip.esignet.dpop.nonce.expire.seconds=15` * `mosip.esignet.kbispec.ttl.seconds=18000` * `mosip.esignet.client-assertion.unique.jti.required=true` * **Signup**: The properties listed below are newly added to the Signup default configuration. For a comprehensive view of all configuration properties in eSignet, please [refer here](https://github.com/mosip/esignet-signup/blob/master/signup-service/src/main/resources/application-default.properties). * `mosip.signup.uispec.ttl.seconds=18000` ### Documentation **API Documentation** * [**eSignet API (v1.7.0)**](https://github.com/mosip/esignet/blob/master/docs/esignet-openapi.yaml) * [**Signup API (v1.3.0)**](https://github.com/mosip/esignet-signup/blob/master/docs/esignet-signup-openapi.yaml) **Integration Guides** * [**eSignet Integration Guide**](https://docs.esignet.io/esignet-authentication/develop/integration) * [**Signup Integration Guide**](https://docs.esignet.io/esignet-signup/develop/integration-guide-signup-portal) **End User Guides** * [**eSignet End User Guide**](https://docs.esignet.io/esignet-authentication/test/end-user-guide) * [**Signup End User Guide**](https://docs.esignet.io/esignet-signup/test/end-user-guide) [**QA Report**](/home/esignet/roadmap-and-releases/versions/v1.7.0/test-report) # Test Report ## 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, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation 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 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 - which 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 creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which 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 - * eSignet with 6 languages (English/Khmer/Hindi/Kannada/arabic/tamil) * Signup with 2 languages (Khmer/English) ### Main feature tested * Signup Portal with mock ID * Login with Password with mock ID * Forgot Password with mock ID * Login with OTP and biometrics with mock ID * Login with KBI with mock ID * Identity verification process (L2 flow) with mock ID and MOSIP ID * Identity verification process (L1 flow) with Cre * Wallet login performed cre for release environment * Signup Portal with MOSIP IDA * Login with Password with MOSIP IDA * Forgot Password with MOSIP IDA * Login with OTP and biometrics MOSIP IDA * Sunbird Plugin with KBI login * DPoP and PAR in all plugins * Docker Compose testing for esignet, esignet-signup, esignet-mock-services (windows,linux,MAC) * Deployment testing on mock plugin (esignet,signup and FAPI 2.0) ### Features not in scope * Deployment testing on MOSIPID and Sunbird * UI Automation for Signup ## 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 tests were performed in combination of 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 simulation of multiple identity schema and respective UI schema configurations.

Total	Passed	Failed	Skipped
3443	3357	51	35
Test Rate: 98% with Pass rate: 98%

{% hint style="success" %} **Note**: In API-based testing, 35 test cases were marked as skipped because they were not automated and cannot be executed using Postman. {% endhint %} **Here is the detailed breakdown**:

		Test cases

API Based Testing - eSignet	Total	2192
	Passed	2129
	Failed	28
	Skipped	35
UI Based Testing	Total	1251
	Passed	1228
	Failed	23
	Skipped	0

**API Testrig results for eSignet and Signup with Mock ID**:

		Test cases

API Based Testrig - eSignet	Total	1273
	Passed	729
	Failed	0
	Skipped	0
	Ignored	544
	Known issues	0
API Based Testrig - eSignet-signup	Total	665
	Passed	635
	Failed	0
	Skipped	0
	Ignored	30
	Known issues	0

{% hint style="success" %} **Note**: 544 test cases in esignet and 30 test cases in signup related to the MOSIP ID plug-in are currently being ignored. {% endhint %} **API Testrig results for eSignet and Signup with MOSIP - CRE**:

		Test cases
API Based Testrig - eSignet	Total	1273
	Passed	1091
	Failed	8
	Skipped	8
	Ignored	166
	Known issues	0
API Based Testrig - eSignet-signup	Total	665
	Passed	405
	Failed	53
	Skipped	190
	Ignored	17
	Known issues	0

{% hint style="success" %} **Note**: 61 Failures in esignet and signup 198 are skipped due to L2 flow is not supported in esignet and signup. {% endhint %} **API Testrig results for eSignet and Signup with MOSIP – qa-base**:

		Test cases
API Based Testrig - eSignet	Total	1273
	Passed	1107
	Failed	0
	Skipped	0
	Ignored	166
	Known issues	0
API Based Testrig - eSignet-signup	Total	665
	Passed	648
	Failed	0
	Skipped	0
	Ignored	17
	Known issues	0

Note: 166 test cases in esignet and 17 test cases in signup related to the mock plug-in are currently being ignored. API Testrig results for eSignet and Signup with Sunbird:

		Test cases
API Based Testrig - Sunbird	Total	1273
	Passed	93
	Failed	0
	Skipped	0
	Ignored	1180
	Known issues	0

{% hint style="success" %} **Note**: mock and mosipid plugin test cases are getting ignored {% endhint %} **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 failed test cases. (Number of failed tests / Total number of test cases executed) x 100 **Sonar Report:**


Repo Name	Branch Name	Release Version (POM)	Coverage (>80%)	Reliability (0)	Security (0)	Hotspots (0)	Duplications (Less than 3%)
eSigent	release-1.7.x	release-1.7.0	84.7	0	0	0	0%
eSignet Signup	release-1.3.x	release-1.3.0	81.9	0	0	0	0%
esignet-mock-services	release-0.12.x	release-0.12.0	85.2	0	0	0	0%
esignet-plugins(mock-plugin)	release-1.3.x	release-1.3.4	83	0	0	0	2.9%
esignet-plugins(mosip-identity-plugin)	release-1.3.x	release-1.3.4	69.1	0	0	0	0%
esignet-plugins(sunbird-rc-plugin)	release-1.3.x	release-1.3.4	83	0	0	0	0%

Refer to the github link for more on reports [**here**](https://github.com/mosip/test-management/tree/master/e-signet/1.7.0). # v1.6.2 **Release Number:** v1.6.2 (Patch) **Release Date:** 28th August, 2025 ### Overview We are excited to announce [**eSignet v1.6.2**](https://github.com/mosip/esignet/tree/v1.6.2), a patch release that adds [**Identity Assurance 1.0** ](https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html)**support in the MOSIP Identity plugin**. This enhancement enables the **identity verification feature of the Signup module, such as video eKYC**, to work seamlessly with **MOSIP ID**. Alongside this, the release delivers important **security improvements** and **bug fixes**, further strengthening stability and reliability. ### Major Highlights 1. [**Identity Assurance 1.0 Support in MOSIP Identity Plugin**](https://docs.esignet.io/esignet-signup/features#identity-assurance-flow-ekyc-verification)\ Support in **MOSIP Identity plugin** to comply with [Identity Assurance 1.0](https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html). This enables the **Signup video eKYC flow** to work with MOSIP ID Repo and IDA. ### Enhancements 1. **Bug Fixes**\ Multiple known issues have been resolved to improve stability and reliability. Please [refer here](https://mosip.atlassian.net/issues/?filter=-4\&jql=project%20%3D%20eSignet%20and%20issuetype%20%3D%20Bug%20and%20%22Release%20Number%5BLabels%5D%22%20%3D%20eSignet_v1.6.2) for full list of bug fixes. 2. **Security Fixes**\ Applied critical security patches to address vulnerabilities and strengthen system security. ### Compatibility Note eSignet **v1.6.2** mainly introduces support for **Identity Assurance 1.0 in MOSIP Identity Plugin**, which enables the eSignet and Signup module to integrate seamlessly with MOSIP ID. ⚠️ **Important:** 1. The **Identity Assurance 1.0 support** added in the MOSIP ID plugin will be available starting with the **following future versions of MOSIP modules**: * **ID Repo:** v1.2.3.0 (Coming Soon) * **IDA:** v1.2.2.0 (Coming Soon) 2. eSignet and the Signup module have been **verified with these yet-to-be-released versions** of MOSIP modules. 3. The **identity verification feature** in Signup (such as **video eKYC**) will be **fully compatible with MOSIP ID only when** the above module versions are officially released. 4. Until then, **all existing features of eSignet and Signup** (other than the video eKYC flow) will continue to work as expected with the **currently released versions** of MOSIP ID modules. ### Known Issues | Jira ID | Summary | | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | [ES-2506](https://mosip.atlassian.net/browse/ES-2506) | esignet mosip id SendBindingOtp and WalletBinding test cases are failing with "errorCode": "IDA-MLC-018" | | [ES-2491](https://mosip.atlassian.net/browse/ES-2491) | In mock when we are providing "trust\_framework": null we are getting the user info response for first claim | Please [refer here](https://mosip.atlassian.net/issues/?filter=-4\&jql=%20issuetype%20%3D%20Bug%20and%20labels%20%3D%20known_issue_eSignet_1.6.2) for full list of known issues. ### Repositories Released | Repository | Tag | | --------------------- | ---------------------------------------------------------------------- | | esignet | [v1.6.2](https://github.com/mosip/esignet/tree/v1.6.2) | | esignet-signup | [v1.2.2](https://github.com/mosip/esignet-signup/tree/v1.2.2) | | esignet-mock-services | [v0.11.2](https://github.com/mosip/esignet-mock-services/tree/v0.11.2) | | esignet-plugins | [v1.3.3](https://github.com/mosip/esignet-plugins/tree/v1.3.3) | ### Compatible Modules #### eSignet with MOSIP compatibility matrix | Module/Repo | Compatible Version | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------- | | PMS | [1.2.2.1](https://github.com/mosip/partner-management-services/tree/v1.2.2.1) | | IDA |

1.2.1.0
1.2.2.0 (for identity assurance 1.0 support)

| #### eSignet with Sunbird compatibility matrix | Module/Repo | Compatible Version | | ----------- | --------------------------------------------------------------------------- | | Sunbird | [v2.0.0-rc3](https://github.com/Sunbird-RC/sunbird-rc-core/tree/v2.0.0-rc3) | #### Signup with MOSIP compatibility matrix | ID Repository |

1.2.1.0
1.2.3.0 (for identity assurance 1.0 support)

| | ------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Keymanager | [1.2.1.0](https://github.com/mosip/keymanager/tree/v1.2.1.0) | ### DB Changes * **eSignet**: N/A * **Signup**: N/A ### Config Changes * **eSignet**: * Added the following configurations in mosip-identity-plugin properties file to invoke IDA v2 endpoints for eKYC flow * mosip.esignet.authenticator.ida.kyc-auth-url-v2 * mosip.esignet.authenticator.ida.kyc-exchange-url-v2 * **Signup**: N/A ### Documentation **API Documentation** * [**eSignet API (v1.6.2)**](https://github.com/mosip/esignet/blob/v1.6.2/docs/esignet-openapi.yaml) * [**Signup API (v1.2.2)**](https://github.com/mosip/esignet-signup/blob/v1.2.2/docs/esignet-signup-openapi.yaml) **Integration Guides** * [**eSignet Integration Guide**](https://docs.esignet.io/esignet-authentication/develop/integration) * [**Signup Integration Guide**](https://docs.esignet.io/esignet-signup/develop/integration-guide-signup-portal) **End User Guides** * [**eSignet End User Guide**](https://docs.esignet.io/esignet-authentication/test/end-user-guide) * [**Signup End User Guide**](https://docs.esignet.io/esignet-signup/test/end-user-guide) **QA Report** * [QA Report](/home/esignet/roadmap-and-releases/versions/v1.6.2/test-report) # Test Report ## 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, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation 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 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 - which 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 creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which 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 - * eSignet with 7 languages (English/Khmer/Hindi/Kannada/Tamil/Arabic/French) * Signup with 2 languages (Khmer/English) Main feature tested: * Signup Portal with mock ID * Login with Password with mock ID * Forgot Password with mock ID * Login with OTP with mock ID * Login with biometrics with mock ID * Login with KBI with mock ID * Identity verification process (L2 flow) with mock ID * Identity verification process (L2 flow) with MOSIP ID * Signup Portal with MOSIP IDA * Login with Password with MOSIP IDA * Forgot Password with MOSIP IDA * Login with OTP with MOSIP IDA * Login with biometrics MOSIP IDA * Sunbird Plugin with MOSIP IDA * Critical and Blocker Bugs verification * Docker Compose testing for esignet, esignet-signup, esignet-mock-services (windows) ## Feature Health

Total	Passed	Failed	Skipped
3183	3113	35	35

Test Rate: 98% with Pass rate: 98% {% hint style="info" %} Note: In API-based testing, 35 test cases were marked as skipped because they were not automated and cannot be executed using Postman. {% endhint %} Here is the detailed breakdown:

	Test cases	Total
API Based Testing - eSignet		2017
	Passed	1965
	Failed	17
	Skipped	35
UI Based Testing		1166
	Passed	1148
	Failed	18
	Skipped	0

#### API Testrig results for eSignet and Signup with Mock ID:

	Test cases	Total
API Based Testrig - eSignet		1011
	Passed	514
	Failed	0
	Skipped	0
	Ignored	495
Known issues	2
API Based Testrig - eSignet-signup		661
	Passed	626
	Failed	0
	Skipped	0
	Ignored	30
	Known issues	5

Note: 525 test cases related to the MOSIP ID plug-in are currently being ignored. #### API Testrig results for eSignet and Signup with MOSIP - CRE:

	Test cases	Total
API Based Testrig - eSignet		1011
	Passed	838
	Failed	0
	Skipped	0
	Ignored	169
	Known issues	4
API Based Testrig - eSignet-signup	Total	661
	Passed	400
	Failed	53
	Skipped	186
	Ignored	17
	Known issues	5

{% hint style="info" %} Note: * In the mosipid-cre environment, 186 test cases are being skipped as L2 flow test cases are out of scope. * There is 1 failure in the registration status endpoint; the other 52 failures are related to L2 test cases and can be ignored. * Additionally, 186 test cases are being ignored due to the esignet sunbird report being executed separately. {% endhint %} #### API Testrig results for eSignet and Signup with MOSIP – qa-base:

	Test cases	Total
API Based Testrig - eSignet		1011
	Passed	848
	Failed	0
	Skipped	0
	Ignored	169
Known issues		4
API Based Testrig - eSignet-signup		661
	Passed	643
	Failed	0
	Skipped	0
	Ignored	17
	Known issues	1

Note: 186 test cases related to the mock plug-in are currently being ignored. #### API Testrig results for eSignet and Signup with Sunbird:

	Test cases	Total

API Based Testrig - Sunbird		1011
	Passed	93
	Failed	0
	Skipped	0
	Ignored	918

#### **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 failed test cases. (Number of failed tests / Total number of test cases executed) x 100 #### **Sonar Report**:

Repo Name	Branch Name	Release Version (POM)	Coverage (>80%)	Duplications (Less than 3%)
eSigent	release-1.6.x	release-1.6.x	86	0%
eSignet Signup	release-1.2.x	release-1.2.x	82.1	0%
esignet-mock-services	release-0.11.x	Release-0.11.x	81.4	0%
esignet-plugins(mock-plugin)	release-1.3.x	release-1.3.x	83	2.9%
esignet-plugins(mosip-identity-plugin)	release-1.3.x	release-1.3.x	68.9	0%
esignet-plugins(sunbird-rc-plugin)	release-1.3.x	release-1.3.x	83	0%

Refer to the github link for more on reports [**here**](https://github.com/mosip/test-management/tree/master/e-signet/1.6.2). # v1.6.1 **Release Number:** v1.6.1 **Release Date:** 29th Jul, 2025 ## Overview We’re excited to announce the upcoming release of [**eSignet v1.6.1**](https://github.com/mosip/esignet/tree/v1.6.1), a major update packed with new features, improved configurability, and enhanced security. This version brings greater flexibility for Relying Parties (RPs) to customize login experiences, a revamped UI, and significant improvements to deployment processes. {% hint style="success" %} **Version Note:** **eSignet v1.6.1** is a patch release over the originally planned **v1.6.0**, addressing critical deployment-related bug fixes. It is the latest official version following **eSignet v1.5.1**. {% endhint %} ## Major Highlights ### New Features * [**Prefix & Postfix support for Choice of Login ID**](https://docs.esignet.io/esignet-authentication/develop/configuration/login-id-configuration-in-esignet)\ Configure login ID types (Email, Phone, VID, etc.) as per relying party (RP) needs. Comes with a revamped, more intuitive UI. * [**Customizable Client Configuration**](https://github.com/mosip/esignet/blob/v1.6.1/docs/esignet-openapi.yaml#L36)\ Enhanced client management endpoint with additional options for better customization and control of eSignet's behavior. * [**Purpose-Based eSignet UI**](https://docs.esignet.io/esignet-authentication/develop/configuration/purpose-based-ui-rendering-in-esignet)\ UI dynamically adapts titles and tile subtitles based on the context and purpose of the service, providing a more relevant user experience. ### Enhancements * **JTI Mandatory in Client Assertion**\ JTI is now a required parameter in the client assertion JWT in token endpoint for improved security. ⚠️ **Breaking Change**: Existing relying parties (RPs) must include the `jti` claim to share consented claims successfully. * **Unique nonce for each transaction:** nonce query parameter in the [authorize url](https://docs.esignet.io/esignet-authentication/develop/integration/relying-party/development-and-integration-with-esignet#get-authorize) should be unique for each transaction. ⚠️ **Breaking Change**: If duplicate nonce is found “invalid\_request“ error is thrown. * **Updated Vulnerable Libraries**\ Security has been bolstered by updating dependencies and patching known vulnerabilities. * [**Improved Deployment Scripts**](https://github.com/mosip/esignet/blob/v1.6.1/deploy/README.md)\ Upgraded installation scripts provide a smoother experience for new deployments of eSignet. ## Features Released | Feature | Jira | | ----------------------------------------------- | ------------------------------------------------------------- | | Prefix & Postfix support for Choice of Login ID | [ES-1665](https://mosip.atlassian.net/browse/ES-1665) | | Customizable Client Configuration | [ES-1655](https://mosip.atlassian.net/browse/ES-1655) | | Purpose-Based eSignet UI | [ES-216](https://mosip.atlassian.net/browse/ES-216) | | Deployment Script Update | [MOSIP-40529](https://mosip.atlassian.net/browse/MOSIP-40529) | ## Security Enhancements **Library Upgrades for Vulnerability Fixes:** Dependencies in eSignet service have been upgraded to fix known vulnerabilities. ## Bug Fixes Several known issues from the previous release have been addressed to improve platform stability and performance. Please refer to the [link here](https://mosip.atlassian.net/issues/?filter=-4\&jql=%22Release%20Number%5BLabels%5D%22%20%3D%20eSignet_v1.6.1%20and%20issuetype%20%3D%20Bug%20and%20status%20IN%20%28Closed%29) for the complete list of resolved issues. ## Key Known Issues | Jira Issue | Summary | | ----------------------------------------------------- | ------------------------------------------------------------------------------ | | [ES-2317](https://mosip.atlassian.net/browse/ES-2317) | Verified Consented claims are not returned in userinfo response in MOSIP IDA | | [ES-2359](https://mosip.atlassian.net/browse/ES-2359) | Getting `invalid_request` when the `additional_config` is added for the client | Please refer to [link here](https://mosip.atlassian.net/issues/?filter=-4\&jql=labels%20%3D%20known_issue_eSignet_1.6.1) for the full list of known issues. ## Repositories Released | Repository | Tags | | --------------------- | ---------------------------------------------------------------------- | | esignet | [v1.6.1](https://github.com/mosip/esignet/tree/v1.6.1) | | esignet-signup | [v1.2.1](https://github.com/mosip/esignet-signup/tree/v1.2.1) | | esignet-mock-services | [v0.11.1](https://github.com/mosip/esignet-mock-services/tree/v0.11.1) | | esignet-plugins | [v1.3.2](https://github.com/mosip/esignet-plugins/tree/v1.3.2) | ## Compatibility Matrix **eSignet with MOSIP compatibility matrix** | Module/Repo | Compatible Version | | ----------------- | ----------------------------------------------------------------------------- | | ID Authentication | [1.2.1.0](https://github.com/mosip/id-authentication/tree/v1.2.1.0) | | PMS | [1.2.2.1](https://github.com/mosip/partner-management-services/tree/v1.2.2.1) | **eSignet with Sunbird compatibility matrix** | Module/Repo | Compatible Version | | ----------- | --------------------------------------------------------------------------- | | Sunbird | [v2.0.0-rc3](https://github.com/Sunbird-RC/sunbird-rc-core/tree/v2.0.0-rc3) | **Signup with MOSIP compatibility matrix** | Module/Repo | Compatible Version | | ------------- | ----------------------------------------------------------------------------- | | ID Repository | [1.2.2.1](https://github.com/mosip/id-repository/tree/v1.2.2.1) | | Keymanager | [1.2.1.0](https://github.com/mosip/keymanager/tree/v1.2.1.0) | | PMS | [1.2.2.1](https://github.com/mosip/partner-management-services/tree/v1.2.2.1) | ## Config Changes ### eSignet 1. Added the following configurations to provide a structured and flexible approach to supporting multiple login ID types: `mosip.esignet.ui.config.login-id.options=` `mosip.esignet.ui.config.login-id.options=` Allows customization for each ID type, including options such as: * **Prefixes** (e.g., country codes for mobile numbers) * **Associated icons** for improved UI experience * **Validation rules**, such as regular expressions or length constraints 2. Property to configure additional config schema `mosip.esignet.additional-config.schema.url` Please [refer here](https://github.com/mosip/esignet/blob/v1.6.1/esignet-service/src/main/resources/application-default.properties) for details. ## eSignet Mock Services 1. Property to configure the url to fetch the schema of additional config `mosip.mock.ui-spec.schema.url` Please [refer here](https://github.com/mosip/esignet-mock-services/blob/v0.11.1/mock-identity-system/src/main/resources/application-default.properties) for details. ## Database Changes ### eSignet 1. **New column:** `additional_config` of type `jsonb` added to the `client_detail` table for storing flexible JSON configuration data. 2. **Increased length of `name` column** in the `client_detail` table to **600 characters** to support longer client names. Please [refer here](https://github.com/mosip/esignet/blob/release-1.6.x/db_upgrade_script/mosip_esignet/sql/1.5.1_to_1.6.0_upgrade.sql) for details. ### eSignet Mock Services 1. Modified the `identity_json` column in the `client_detail` table to use `VARCHAR` **without a length limit**, allowing for variable-length string data of unlimited size. Please [refer here](https://github.com/mosip/esignet-mock-services/blob/release-0.11.x/db_upgrade_script/mosip_mockidentitysystem/sql/0.10.1_to_0.11.0_upgrade.sql) for details. ## Documentation **API Documentation** * [**eSignet API (v1.6.1)**](https://github.com/mosip/esignet/blob/v1.6.1/docs/esignet-openapi.yaml) * [**Signup API (v1.2.1)**](https://github.com/mosip/esignet-signup/blob/v1.2.1/docs/esignet-signup-openapi.yaml) **Integration Guides** * [**eSignet Integration Guide**](https://docs.esignet.io/esignet-authentication/develop/integration) * [**Signup Integration Guide**](https://docs.esignet.io/esignet-signup/develop/integration-guide-signup-portal) **End User Guides** * [**eSignet End User Guide**](https://docs.esignet.io/esignet-authentication/test/end-user-guide) * [**Signup End User Guide**](https://docs.esignet.io/esignet-signup/test/end-user-guide) [**QA Report**](/home/esignet/roadmap-and-releases/versions/v1.6.1/test-report) # Test Report ## 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, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation 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 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 - which 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 creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open source artifact which 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 - * eSignet with 7 languages (English/Khmer/Hindi/Kannada/Tamil/Arabic/French) * Signup with 2 languages (Khmer/English) #### Main feature tested: * Signup Portal with mock ID * Login with Password with mock ID * Forgot Password with mock ID * Login with OTP with mock ID * Login with biometrics with mock ID * Login with KBI with mock ID * Identity verification process (L2 flow) with mock ID * Signup Portal with MOSIP IDA * Login with Password with MOSIP IDA * Forgot Password with MOSIP IDA * Login with OTP with MOSIP IDA * Login with biometrics MOSIP IDA * Sunbird Plugin with MOSIP IDA * Critical and Blocker Bugs verification * Docker Compose testing for eSignet and signup (windows, Linux and Mac) ## Feature Health

Total	Passed	Failed	Skipped
3183	3110	38	35

Test Rate: 98% with Pass rate: 98% Here is the detailed breakdown:

	Test cases	Total
API Based Testing - eSignet		2017
	Passed	1962
	Failed	20
	Skipped	35
UI Based Testing		1166
	Passed	1148
	Failed	18
	Skipped	0

API Testrig results for eSignet and Signup with Mock ID:

	Test cases	Total
API Based Testrig - eSignet	Total	1011
	Passed	93
	Failed	0
	Skipped	0
	Ignored	918
API Based Testrig - eSignet-signup		585
	Passed	559
	Failed	0
	Skipped	0
	Ignored	26

API Testrig results for eSignet and Signup with MOSIP ID:

	Test cases	Total
API Based Testrig - eSignet		1011
	Passed	842
	Failed	0
	Skipped	0
	Ignored	169
API Based Testrig - eSignet-signup		585
	Passed	301
	Failed	1
	Skipped	0
	Ignored	283

API Testrig results for eSignet and Signup with Sunbird:

	Test cases	Total
API Based Testrig - Sunbird		1011
	Passed	93
	Failed	0
	Skipped	0
	Ignored	918

{% hint style="warning" %} **Note**: In API Based testing, 35 test cases are marked as skipped as they were not automated and cannot be tested using postman. {% endhint %} #### 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 failed test cases. (Number of failed tests / Total number of test cases executed) x 100 #### Sonar Report:


Repo Name	Branch Name	Release Version (POM)	Coverage (>80%)	Reliability (0)	Security (0)	Hotspots (0)	Duplications (Less than 3%)
eSigent	release-1.6.x	release-1.6.1	86.2	0	0	0	0%
eSignet Signup	release-1.2.x	release-1.2.1	79.3	0	0	0	0%
esignet-mock-services	release-0.11.x	release-0.11.1	83.3	0	0	0	0%
esignet-plugins(mock-plugin)	release-1.3.x	release-1.3.2	83.0	0	0	0	2.9%
esignet-plugins(mosip-identity-plugin)	release-1.3.2	release-1.3.2	83.6	0	0	0	0%
esignet-plugins(sunbird-rc-plugin)	release-1.3.2	release-1.3.2	83	0	0	0	0%

*** # v1.5.1 **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](https://github.com/mosip/esignet-signup/blob/v1.1.1/docker-compose/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. 4. **Documentation:** Updated the Sign-up Docker Compose README to ensure a smooth local setup for Sign-up services. #### **Bug Fixes** * Several known issues from v1.5.0 have been resolved to improve platform stability. A detailed list of fixes is available [here](https://mosip.atlassian.net/issues/ES-2224?jql=%22Release%20Number%5BLabels%5D%22%20%3D%20esignet_v1.5.1%20and%20issuetype%20%3D%20Bug%20and%20status%20not%20in%20%28Cancelled%2CCanceled%29%20ORDER%20BY%20cf%5B10017%5D%20desc). We believe this release will greatly improve eSignet's security, efficiency, and user experience. Thank you for your continued support! #### **Key Known Issues** | Jira Issue | Summary | | ----------------------------------------------------- | --------------------------------------------------------------------------------------- | | [ES-2222](https://mosip.atlassian.net/browse/ES-2222) | The user is not getting registered with an 8-digit UIN in MOSIP IDA. | | [ES-2023](https://mosip.atlassian.net/browse/ES-2023) | Intermittent: Signup register and reset password are throwing errors but able to login. | Please refer to [this link](https://mosip.atlassian.net/issues/MOSIP-35494?jql=labels%20%3D%20ES_v1.5.1_known_issue) for the list of all known issues. #### **Repositories Released** | Repository Released | Tags | | --------------------- | ---------------------------------------------------------------------- | | esignet | [v1.5.1](https://github.com/mosip/esignet/tree/v1.5.1) | | esignet-signup | [v1.1.1](https://github.com/mosip/esignet-signup/tree/v1.1.1) | | esignet-mock-services | [v0.10.1](https://github.com/mosip/esignet-mock-services/tree/v0.10.1) | | esignet-plugins | [v1.3.1](https://github.com/mosip/esignet-plugins/tree/v1.3.1) | #### **Compatible Modules** | Module/Repository | Compatible Version | | -------------------------- | ------------------------------------------------------------------------------------------------ | | ID Authentication | [1.2.1.0](https://github.com/mosip/id-authentication/tree/v1.2.1.0) | | ID Repository | [1.2.1.0](https://github.com/mosip/id-repository/tree/v1.2.1.0) | | kernel - core | [1.2.0.1](https://github.com/mosip/commons/tree/v1.2.0.1/kernel/kernel-core) | | kernel-notfication-service | [1.2.0.1](https://github.com/mosip/commons/tree/v1.2.0.1/kernel/kernel-notification-service) | | kernel-idgenerator-service | [1.2.0.1](https://github.com/mosip/commons/tree/v1.2.0.1/kernel/kernel-idgenerator-service) | | kernel-auth-adaptor | [1.2.0.1](https://github.com/mosip/mosip-openid-bridge/tree/v1.2.0.1/kernel/kernel-auth-adapter) | | kernel-auth-service | [1.2.0.1](https://github.com/mosip/mosip-openid-bridge/tree/v1.2.0.1/kernel/kernel-auth-service) | | kernel-otp-manager | [1.2.0.1](https://github.com/mosip/otp-manager/tree/v1.2.0.1/kernel/kernel-otpmanager-service) | | Sunbird | [v2.0.0-rc3](https://github.com/Sunbird-RC/sunbird-rc-core/tree/v2.0.0-rc3) | ### **DB Changes** **eSignet** * Changed public\_key column data type to JSONB in the client\_details table. Please refer [here](https://github.com/mosip/esignet/blob/v1.5.1/db_upgrade_script/mosip_esignet/sql/1.5.0_to_1.5.1_upgrade.sql) for details. **eSignet mock services** * The length limit on the identity\_json column has been removed from the identity database. Please refer [here](https://github.com/mosip/esignet-mock-services/blob/v0.10.1/db_upgrade_script/mosip_mockidentitysystem/sql/0.10.0_to_0.10.1_upgrade.sql) 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 [here](https://github.com/mosip/esignet-mock-services/blob/v0.10.1/mock-identity-system/src/main/resources/application-default.properties) for details. #### **Documentation** 1. [API Documentation](https://mosip.stoplight.io/docs/identity-provider/branches/1.5.0/7oz4lmhu3pf6b-e-signet) 2. [Integration Guides](/home/esignet/esignet-authentication/develop/integration/relying-party/development-and-integration-with-esignet) 3. [End User Guide](/home/esignet/esignet-authentication/test/end-user-guide) 4. [QA Report](/home/esignet/roadmap-and-releases/versions/v1.5.1/test-report) # Test Report ### 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 Configurability and Extensibility of the software are 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 automation 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 processor, 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: ● eSignet with 7 Languages (English/Khmer/Hindi/Kannada/Tamil/Arabic/French) ● Signup in 2 languages (Khmer/English) #### Main features tested: * **Signup Portal** with mock ID * **Login with Password** with mock ID * **Forgot Password** with mock ID * **Login with OTP** with mock ID * **Login with Biometrics** with mock ID * **Login with KBI** with mock ID * **Identity Verification Process (L2 flow)** with mock ID * **Signup Portal** with MOSIP IDA * **Login with Password** with MOSIP IDA * **Forgot Password** with MOSIP IDA * **Login with OTP** with MOSIP IDA * **Login with Biometrics** with MOSIP IDA * **Login with KBI** with MOSIP IDA * **Sunbird Plugin** with MOSIP IDA * **Critical and Blocker Bugs Verification** * **Docker Compose Testing** for eSignet and signup (Windows and Linux) ### 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.

Total Test Cases	Passed	Failed	Skipped
2928	2815	67	46

**Test Rate:** 98% with **Pass rate:** 97% Here is the detailed breakdown: #### API Based Testing - eSignet

Total Test Cases	Passed	Failed	Skipped
1934	1857	51	26

#### UI Based Testing

Total Test Cases	Passed	Failed	Skipped
994	958	16	20

### API Testrig results for eSignet and Signup with Mock ID: #### API Based Testrig - eSignet

Total Test Cases	Passed	Failed	Skipped	Ignored
962	465	0	0	497

#### API Based Testrig - eSignet-signup

Total Test Cases	Passed	Failed	Skipped	Ignored
579	552	0	0	26

{% hint style="info" %} **Note:** In API Based testing, 26 test cases are marked as skipped as they were not automated and cannot be tested using Postman. In UI Based testing, 20 test cases are marked as skipped as they were out of scope for the release. {% endhint %} ### 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:

Repo Name	Branch Name	Release Version (POM)	Coverage (>80%)	Reliability (0)	Security (0)	Hotspots (0)	Duplications (Less than 3%)
eSigent	release-1.5.x	v1.5.1	86.2%	0	0	0	0%
eSignet Signup	release-1.1.x	v1.1.1	81.2%	0	0	0	0%

# v1.5.0 **Release Name**: v.1.5.0 **Release Date**: 23rd Jan, 2025 ### **Overview** We are excited to announce the release of eSignet v1.5.0, featuring the key implementation of Identity Assurance 1.0 (Draft). This open standard enhances eSignet’s ability to verify and authenticate identities more assuredly, laying the foundation for the newly supported video-based eKYC verification plugin. In addition to this core feature, the release includes security fixes and several architectural updates to streamline workflows and enhance the overall user and developer experience. ### **Features** 1. [**Identity Assurance Implementation**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.5.0/broken-reference/README.md) * Implemented Identity Assurance 1.0 (Draft), aligning with open standards for higher identity verification assurance, laying the foundation for video eKYC support. 2. [**Signup and Login with OTP for Verified Claims**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.5.0/broken-reference/README.md) * Added video eKYC via WebSocket in the signup portal, enabling secure, real-time video verification during registration. 3. [**Well-Informed Claim Details**](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.5.0/broken-reference/README.md) * Users now receive clear consent requests before starting eKYC, ensuring transparency on data usage. 4. **Clickable QR Code for INJI Wallet Login** * A clickable QR code now appears for INJI Wallet login, with an embedded deeplink for seamless access within the same device. ### Major Highlights 1. [**Local Deployment with Docker-Compose**](/home/esignet/build-and-deploy/local-deployment) * Removed artifactory and config Server dependencies, enabling local eSignet deployment via docker-compose for easier setup and environment management. 2. [**eSignet-Plugins Repository Updates**](https://github.com/mosip/esignet-plugins/tree/develop) * eSignet-plugins repository for better compatibility and functionality. 3. [**Captcha Validation Improvements**](https://github.com/mosip/captcha) * Enhanced captcha validation for improved security and fewer vulnerabilities. 4. [**VC Issuance migration to Inji Certify**](https://docs.mosip.io/inji/inji-certify/overview) * eSignet no longer supports VC issuance. This functionality was supported up to eSignet v1.4.2. INJI Certify now handles VC issuance. The documentation has been updated to reflect this change. {% hint style="info" %} **Note:** The Identity Assurance feature has been added in the eSignet 1.5.0 release, and is currently supported only with the mock identity system. {% endhint %} ### **Security Enhancements** * Security issues have been addressed to enhance platform security and speed. For a complete list of fixed bugs, please refer to this [link](https://mosip.atlassian.net/issues/MOSIP-35595?filter=-4\&jql=labels%20IN%20%28Security%2Csecurity_related%29%20and%20status%20IN%20%28Fixed%2CClosed%2CDocumentation%29%20AND%20%22Release%20Number%5BLabels%5D%22%20%3D%20esignet_v1.5.0). ### **Bug Fixes** * Several known issues from v1.4.1 have been resolved to improve platform stability. A detailed list of fixes is available [here](https://mosip.atlassian.net/issues/ES-1216?filter=11684\&jql=labels%20%3D%20known-issue\[%E2%80%A6]0IN%20%28Closed%29%20and%20project%20NOT%20IN%20%28MOSIP%29). We believe this release will greatly improve eSignet's security, efficiency, and user experience. Thank you for your continued support! ### **Key Known Issues** | Jira Issue | Issue Description | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | [ES-1992](https://mosip.atlassian.net/browse/ES-1992) | OAuth Details API is initiating the transaction despite a mismatch between the aud claim in the provided ID token and the clientId | | [ES-1986](https://mosip.atlassian.net/browse/ES-1986) | IDT based authentication is successful on using reused challenge. | | [ES-1981](https://mosip.atlassian.net/browse/ES-1981) | The system is not checking for an available slot every “6” seconds, for a max of “10” time while the loading screen is displaying | | [ES-1977](https://mosip.atlassian.net/browse/ES-1977) | Individual ID is not validated with IDT auth factor | Please refer to [this link](https://mosip.atlassian.net/issues/?filter=11689) for the list of all known issues. ### **Repositories Released** | Repository Released | Tags | | --------------------- | ----------------------------------------------------------------------------- | | esignet | [v1.5.0](https://github.com/mosip/esignet/tree/v1.5.0) | | esignet-signup | [v1.1.0](https://github.com/mosip/esignet-signup/tree/v1.1.0) | | esignet-mock-services | [v0.10.0](https://github.com/mosip/esignet-mock-services/tree/v0.10.0) | | esignet-plugins | [v1.3.0](https://github.com/mosip/esignet-plugins/tree/v1.3.0) | | mosip-onboarding | [v1.3.0-beta.1](https://github.com/mosip/mosip-onboarding/tree/v1.3.0-beta.1) | ### **Compatible Modules** | Module/Repository | Compatible Version | | ----------------- | ------------------ | | IDA | 1.2.1.0 | | ID Repository | 1.2.1.0 | | Kernel | 1.2.0.1 | | Sunbird | v2.0.0-rc3 | ### **Documentation** 1. [API Documentation](https://mosip.stoplight.io/docs/identity-provider/branches/1.5.0/7oz4lmhu3pf6b-e-signet) 2. [Integration Guides](/home/esignet/esignet-authentication/develop/integration/relying-party/development-and-integration-with-esignet) 3. [End User Guide](/home/esignet/esignet-authentication/test/end-user-guide) 4. [QA Report](/home/esignet/roadmap-and-releases/versions/v1.5.0/test-report) # Test Report ## Testing Scope The scope of testing is to verify fitment to the specification from the perspective of ● Functionality ● Deployability ● Configurability ● Customizability Verification is performed from the end user perspective and the System Integrator (SI) point of view. Hence, the software's Configuration and Extensibility are also assessed. This ensures the software's readiness 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 automation Test Rig was created for the same. ### **Test Approach** A 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 designed and developed to support 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 creating 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 software must effectively restrict the needs of negative persona classes. ### **Verified configuration** Verification is performed on various configurations as mentioned below * Default configuration - with 7 Languages (English/Khmer/Hindi/Kannada/Tamil/Arabic/French) ### **Main feature tested** * Signup Portal with mock ID * Login with a Password with a mock ID * Forgot Password with mock ID * Login with Otp with a mock ID * Login with biometrics with mock ID * Login with KBI with a mock ID * Identity verification process with mock ID * Signup Portal with Mosip IDA * Login with Password with Mosip IDA * Forgot Password with Mosip IDA * Login with Otp with Mosip IDA * Login with biometrics Mosip IDA * Login with KBI with Mosip IDA ### Feature Health

### **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. | Total | Passed | Failed | Skipped | | ----- | ------ | ------ | ------- | | 2928 | 2785 | 97 | 46 | **Test Rate:** 98% with **Pass rate:** 96% Here is the detailed breakdown: **API Based Testing - eSignet:** | Total Test Cases | Passed | Failed | Skipped | | ---------------- | ------ | ------ | ------- | | 1934 | 1829 | 79 | 26 | **UI Based Testing:** | Total Test Cases | Passed | Failed | Skipped | | ---------------- | ------ | ------ | ------- | | 994 | 956 | 18 | 20 | #### **API Testrig results for eSignet and Signup with Mock ID** **API Based Testrig - eSignet:** | Total Test Cases | Passed | Failed | Skipped | Ignored | | ---------------- | ------ | ------ | ------- | ------- | | 813 | 445 | 0 | 0 | 368 | **API Based Testrig - eSignet-signup:** | Total Test Cases | Passed | Failed | Skipped | Ignored | | ---------------- | ------ | ------ | ------- | ------- | | 554 | 516 | 34 | 4 | 0 | {% hint style="info" %} **Note:** * In API Based testing - 26 test cases are marked as skipped as they were not automated and cannot be tested using Postman. * In UI Based testing - 20 test cases are marked as skipped as they were out of scope for the release. * In API Based Testrig - eSignet, 368 testcases are marked as ignored as VID is not supported. {% endhint %} #### **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 #### **Device and Browser details:**

Device	Browser	OS version	Display resolution	Screen size
Oppo A96 v11.0	Chrome	Android, v11.0	1080x2412 px	6.59
Samsung Galaxy S8 v7.0	Fire fox	Android, v7.0	1440 x 2960 px	5.8
Redmi 6A	edge, chrome & firefox	Android, v9.0	1440 x 720 px	5.45
iPhone XS v15.3	safari	iOS, v15.3	1125 x 2436 px	5.8
iphone 7	safari, chrome, firefox & edge	15.6	750x 1334 px	4.7
Oppo Reno12 Pro	chrome	Android 14	1080 x 2412 pixels	6.7
Redmi A1	chrome	Android 12	720 x 1600 pixels	6.52
Iphone 15 Plus	Safari	IOS 18	2796x1290 pixels	6.7
MOSIP's MacBook Air	Safari	Sonoma 14.6.1	2560*1664	13.6
Nokia T10	chrome	Android 14	800 x 1280 pixels	8

### **Desktop browser specification** Browser Compatibility for desktop and mobile: | OS | Version | | ------------- | ------------------------ | | Google Chrome | 118. 0.5993.72 and above | | Firefox | 118.0.2 and above | | Edge | 118.0.2088.46 and above | | Safari | 14.1 and above | ### **Sonar Report**

Repository Name	Branch Name	Release Version (POM)	Coverage (>80%)	Reliability (0)	Security (0)	Hotspots (0)	Duplications (Less than 3%)
eSignet	release-1.5.x	v1.5.0	86.8%	0	0	0	0%
eSignet Signup	release-1.1.x	v1.1.0	81.2%	0	0	0	0%

# v1.4.2 **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: ### Key Updates 1. **Updated Property Value** * Corrected the missing property value in the `application-default.properties` file under the docker-compose folder. Cache names missing in the property `mosip.esignet.cache.names` are added as part of this patch. 2. **Postman Utility Library Installation** * Added clear installation instructions for the **postman-utility-lib** in the README file to simplify the setup process. 3. **Updated Docker Configuration** * Updated the Docker Compose file to replace `mosipqa` images with `mosipid` images, ensuring consistency with the latest environment configurations. {% hint style="info" %} **Note:** The API test rig is currently using a snapshot version of the commons library. As a result, the build failure associated with the API test rig is ignored for this release. {% endhint %} ### **Repositories Released** | **Repository Released** | **Tags** | | ----------------------- | ------------------------------------------------------ | | eSignet | [v1.4.2](https://github.com/mosip/esignet/tree/v1.4.2) | # v1.4.1 **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. [Authenticator plugin implementation for KBI with Sunbird RC.](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.4.1/broken-reference/README.md) * Implementation of the Authenticator plugin to enable Knowledge-Based Identification (KBI) within Sunbird RC. b. [VC Issuance plugin implementation for Sunbird RC.](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.4.1/broken-reference/README.md) * Implementation of the VC Issuance plugin to facilitate the issuance of verifiable credentials within Sunbird RC. c. [eSignet UI to support KBI form configuration](https://github.com/mosip/documentation/blob/esignet/docs/roadmap-and-releases/versions/v1.4.1/broken-reference/README.md). * 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 [KBI documentation](/home/esignet/esignet-authentication/test/end-user-guide/health-portal/knowledge-based-authentication) {% hint style="info" %} **Note:** The newly developed plugins are independent and can be adapted to various use cases that utilize Knowledge-Based Identification. An example use case like Insurance Card VC Issuance demonstrates how a user can be issued a verifiable credential using the [Sunbird RC](https://github.com/mosip/digital-credential-plugins/blob/master/sunbird-rc-esignet-integration-impl/README.md) registry configured with KBI. {% endhint %} ### 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 [bug fixes list](https://mosip.atlassian.net/jira/software/c/projects/ES/issues/?jql=%22Release%20Number%5BLabels%5D%22%20in%20$esignet_v1.4.1$%20and%20issuetype%3DBug). ### **Known Issues** * Key Known Issue: | Jira Issue | Issue Description | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | [ES-903](https://mosip.atlassian.net/browse/ES-903) | Intermittent issue faced in Biometric Login when used in certain organization/domain specific laptops. | Please refer to [this link](https://mosip.atlassian.net/jira/software/c/projects/ES/issues/?jql=labels%20%3D%20known-issue-eSignet-v1.4.1) for the list of all known issues. ### **Repositories Released** | Repository Released | Tags | | -------------------------- | -------------------------------------------------------------------------------- | | eSignet | [v1.4.1](https://github.com/mosip/esignet/tree/v1.4.1) | | mosip-config | [v1.4.1-ES](https://github.com/mosip/mosip-config/tree/release-1.4.1-ES) | | esignet-mock-services | [v0.9.3](https://github.com/mosip/esignet-mock-services/tree/release-0.9.x) | | mosip-ref-impl/kernel | [v1.2.0.2](https://github.com/mosip/mosip-ref-impl/tree/release-1.2.0.x/kernel) | | artifactory-ref-impl | [v1.4.1-ES](https://github.com/mosip/artifactory-ref-impl/tree/release-1.4.1-ES) | | eSignet Signup | [v1.0.2](https://github.com/mosip/esignet-signup/tree/release-1.0.x) | | digital-credential-plugins | [v0.1.0](https://github.com/mosip/digital-credential-plugins) | {% hint style="info" %} **Note:** digital-credential-plugins was released as part of v1.4.0, and is compliant with v1.4.1. {% endhint %} For details on deployment, refer to the [helm charts](https://github.com/mosip/esignet/tree/v1.4.1/helm) in the eSignet repository. ### Documentation * [Feature Documentation](/home/esignet/esignet-authentication/features) * [Integration Guides](/home/esignet/esignet-authentication/develop/integration/relying-party/development-and-integration-with-esignet) * [End User Guide](/home/esignet/esignet-authentication/test/end-user-guide) * [API Documentation](https://github.com/mosip/esignet/blob/v1.4.0/docs/esignet-openapi.yaml) * [QA Report](/home/esignet/roadmap-and-releases/versions/v1.4.1/test-report) # Test Report ## 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 * SubirdRC Integration (Using Inji App) * SubirdRC Integration (Using InjiWeb) ## 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. | Total | Passed | Failed | Skipped | | ----- | ------ | ------ | ------- | | 2265 | 2191 | 59 | 15 | **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 2. **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 {% hint style="info" %} **Note:** In API Based testing, 2 test cases are marked as skipped as they were not automated. In UI Based testing, 13 test cases are marked as skipped as they were enhancement test cases. {% endhint %} ### 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: # Performance Report ## Overview The eSignet Performance Report provides a comprehensive analysis of the system’s responsiveness, reliability, and scalability under various operational conditions. It captures key performance metrics such as throughput, resource utilization and memory consumption. This report is designed to help stakeholders understand how eSignet performs in real-world scenarios, identify potential bottlenecks, and guide future optimizations to ensure a seamless and secure digital identity experience. Read more about eSignet: [eSignet Documentation
](https://docs.esignet.io)Further reading for eSignet integration with MOSIP: [MOSIP eSignet | MOSIP Docs 1.2.0](https://docs.mosip.io/1.2.0/interoperability/integrations/e-signet) ## Scope This performance report focuses specifically on benchmarking and evaluating eSignet v1.4.1 under controlled test conditions using a mock Identity Authentication (IDA) system. The key areas covered within the scope of this report include: 1. Performance testing is limited to eSignet v1.4.1 and does not extend to earlier or future versions. 2. Only OTP-based authentication flows were included in the performance assessment. Other factors such as biometrics or password-based flows were excluded because the performance was conducted with mock ID system, so the change in the auth factor does not impact the response times of user authentication and userinfo exchange. 3. The system was tested to achieve and maintain a constant throughput of 100 requests per second (RPS), which in turn translates to [15 transactions per second (TPS)](#user-content-fn-1)[^1] based on the 7 endpoints required to complete 1 transaction. 4. System was able to maintain the throughput of 100 RPS both with and without intentional delays introduced in the mock IDA system. The goal was to ensure consistent performance while remaining within the predefined Service Level Agreements (SLAs) for response times. 5. All performance bottlenecks, failures, or irregularities encountered during testing were documented. Where applicable, fixes and optimizations were implemented and validated to ensure compliance with performance targets. ## Approach To perform the test run, **Apache - JMeter** was used as the load testing tool to simulate **106 users**, maintaining a consistent **throughput of 100 requests per second (RPS)** for a duration of **30 minutes**. 1. **100,000 sample user data was** prepared for the run, if the total number of user samples exceeds **100,000** then the first **100,000** sample user data will be unique, and the **100,001st** sample data will be a repeat of the **1st** sample data from the entry list. 2. To mimic a real-world scenario, an **additional delay of 1000ms** was introduced for the **send-OTP**, **auth**, and **token** endpoints in the mock identity system. Consequently, the **SLA was updated to 1.5 seconds.** ## Tools Used 1. Jmeter to simulate the user load. 2. Jprofiler to profile JVM and the application code. ## Summary 1. Focus: OTP-based authentication flows only 2. Scenarios tested: 1. With 1-second induced delay in mock Identity Authentication (IDA) system 2. Without induced delay 3. Load conditions: 1. Sustained 100 **requests per second** (RPS) 2. 30-minute duration 4. Test environment configuration: 1. eSignet: 2 pods (1500m CPU, 2250Mi memory each) 2. Mock ID system: 2 pods (300m CPU, 2250Mi memory each) 5. Results: 1. Target throughput achieved 2. All Service Level Agreements (SLAs) consistently met 3. Excellent performance and stability under high load and delayed response conditions ### **Test Results Summary** | API Endpoint | Response time (no delay) | Response time (with delay) | SLA | | ------------------------------ | ------------------------ | -------------------------- | -------- | | /authorization/send-otp | 58 ms | 1260 ms | ≤1500 ms | | /authorization/v3/authenticate | 79 ms | 1258 ms | ≤1500 ms | | /oauth/v2/token | 76 ms | 1267 ms | ≤1500 ms | ### **Scenarios Considered** The performance run is carried out with below assumptions and considerations: 1. Performance of eSignet APIs is checked against MOCK ID plugin. 2. We have considered the OTP auth factor for the performance run. ### **SLA:** We are considering that the integrated ID system will take 1.5 secs for below integration points to return back the response: 1. **Send OTP (**/authorization/send-otp**)** 2. **KYC Auth (**/authorization/v3/authenticate**)** 3. **KYC Exchange (**/oauth/v2/token**)**

Module Name

Scenario to be tested

API Endpoint

Accepted Response Time

Weightage

eSignet

Pre-requisite:

Client ID is generated using eSignet API(/v1/esignet/client-mgmt/oidc-client).
eSignet API requires PMS auth Token

User authentication with OTP

/csrf/token → GET
/authorization/v2/oauth-details → POST
/authorization/send-otp → POST
/authorization/v3/authenticate → POST
/authorization/auth-code → POST
/oauth/v2/token → POST
/oidc/userinfo → GET

<=100ms
<=100ms
<=1.5s
<=1.5s
<=100ms
<=1.5s
<=100ms

100%

## Test Environment ### Deviation from the default deployment
1. Migration from the softhsm to PK12.\ \ As part of the performance evaluation, a key deviation from the default deployment was the **migration from SoftHSM to PKCS#12 (PK12)** for key storage. This change enhanced compatibility and operational efficiency such that eSignet met its SLA targets under both normal and stress conditions. ### Software (Under Test) Following ‘Images’ were under the scope of ‘Performance Testing’: #### Modules Segregation | Image ID | Tag Name | Comments | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | | mosipid/esignet:1.4.1 | [release-1.4.1](https://github.com/mosip/esignet/tree/v1.4.1) | | | mosipid/mock-identity-system:release-0.11.0 | [release-0.11.0](https://github.com/mosip/esignet-mock-services/tree/v0.11.0/mock-identity-system) | The changes are tested with mosipqa image and are available in release-0.11.x | | mosipid/mock-relying-party-ui:0.9.2 | [release-0.9.2](https://github.com/mosip/esignet-mock-services/tree/v0.9.2/mock-relying-party-ui) | | | mosipid/mock-relying-party-service:0.9.2 | [release-0.9.2](https://github.com/mosip/esignet-mock-services/tree/v0.9.2/mock-relying-party-service) | | | mosipid/oidc-ui:1.4.1 | [release-1.4.1](https://github.com/mosip/esignet/tree/v1.4.1/oidc-ui) | | #### Test Data Performance data load has been populated before the run to ensure realistic results. | DB | Table Name | Number Of Records/Sample Data | | ------------- | ----------- | ----------------------------- | | mock identity | uin | 100000 | | | fullName | 100000 | | | emailId | 100000 | | | phoneNumber | 100000 | ### Test Design * **Test Duration**: 30 mins * **Test Type**: Load * **Ramp Up**: 3 mins #### **User distribution among the scenarios**

Scenario Name	Module Name	API Endpoint	HTTP Method	SLA(ms) <=	Weightage/Load Distribution	Throughput (RPS)
User with OTP authentication	eSignet-service	/csrf/token	GET	100	100	100
		/authorization/v2/oauth-details	POST	100
		/authorization/send-otp	POST	1500
		/authorization/v3/authenticate	POST	1500
		/authorization/auth-code	POST	100
		/oauth/v2/token	POST	1500
		/oidc/userinfo	GET	100

### Resource level configuration | Container name | 100RPS | | | -------------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | **Number of pods** | **Resource configuration** | | eSignet | 2 |

resources:

limits:

cpu: 1500m

memory: 2250Mi

requests:

cpu: 1500m

memory: 2250Mi

name: JDK\_JAVA\_OPTIONS

value: '-Xms2250M -Xmx2250M'

| | mock-identity-system | 2 |

resources:

limits:

cpu: '300m'

memory: 2250Mi

requests:

cpu: 300m

memory: 2250Mi

name: JDK\_JAVA\_OPTIONS

value: '-Xms1500M -Xmx1500M'

| ## Test Result #### Performance test execution results | **Application Name** | eSignet | | -------------------- | -------------------- | | **Test Duration** | 13/03/2025 (30 mins) | | **Status** | Pass | ### Test Report 1. Test results for 100 RPS for a 30-minute run, simulating the real-time ID system by adding a fixed 1-second processing time for each endpoint (send-OTP, auth, and token). | **Scenario Name** | **Transaction Name** | **API Endpoint** | **HTTP Method** | **100 RPS** | | | | | | | ---------------------------- | ---------------------- | ------------------------------- | --------------- | --------------------------------------------- | --------------- | ----------- | ------------ | ------- | ----------- | | | | | | **Date : 09/06/2025 (half an hour duration)** | | | | | | | | | | | **# Samples** | **Min** | **Average** | **90% Line** | **Max** | **Error %** | | User with OTP authentication | S01 T01 GetCsrf | /csrf/token | GET | 25969 | 7 | 12 | 17 | 358 | 0.00% | | | S01 T02 OAuthdetails | /authorization/v2/oauth-details | POST | 25968 | 6 | 12 | 17 | 391 | 0.00% | | | S01 T03 Send OTP | /authorization/send-otp | POST | 25968 | 1017 | 1095 | 1260 | 1719 | 0.00% | | | S01 T04 Authentication | /authorization/v3/authenticate | POST | 25952 | 1025 | 1101 | 1258 | 1754 | 0.03% | | | S01 T05 Autorization | /authorization/auth-code | POST | 25934 | 7 | 14 | 19 | 1026 | 0.00% | | | S01 T06 Token | /oauth/v2/token | POST | 25934 |

1030

| 1106 | 1267 | 1964 | 0.00% | | | S01 T07 Userinfo | **/oidc/userinfo** | GET | 25918 | 6 | 12 | 17 | 437 | 0.00% | ### Metrics **Table of eSignet endpoint metrics**

**Time chart of 90th percentile response time for eSignet services**

#### Dependent services metrics **Table of mock identity system endpoint metrics and time-chart of 90th percentile response time**

#### CPU Utilisation

#### Memory Utilisation

## Resource Calculator Please refer the details [resource calculator published here](https://github.com/mosip/esignet/tree/develop/performance-test) for sizing guidelines. ## Performance Analysis ### KPI Comparison The key performance metrics from the overall run focused on the **response times** of the endpoints: **send-OTP**, **KYC-Auth**, and **KYC-Exchange** from the integrated identity system to achieve 100/sec through put is shown below. | End points | Expected response time (ms) | Actual Response time (ms) | | ---------------- | --------------------------- | ------------------------- | | **send-OTP** | 1500 | 1260 | | **KYC-Auth** | 1500 | 1258 | | **KYC-Exchange** | 1500 | 1267 | ### Bottlenecks Based on the scope of the performance run, **no bottlenecks or issues were observed**. ### Recommendation The performance of the system was evaluated based on the defined scope and approach, achieving a consistent **throughput of 100 requests per second (RPS)** during a **30-minute run**. It is recommended to use a **Resource Calculator** for estimating requirements and scaling for the desired number of users and transactions. ## Annexure: * References: * [Little's law](https://en.wikipedia.org/wiki/Little's_law) * [Little’s Law in Performance Testing](https://www.perfmatrix.com/littles-law-in-performance-testing/) [^1]: 100 RPS are the individual requests that are hit for each endpoint. For the performance run there are 7 individual endpoints that are required to be hit sequentially to complete 1 transaction. Hence 100/7 = 15 (approx) becomes the TPS for the performance run. # v1.4.0 **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 [here](/home/esignet/esignet-authentication/features). 1. **Fixes for known issues from v1.3.0** {% hint style="info" %} **Note:** 1. The authentication factor can be referred to as either Knowledge Based Authentication (KBA) or Knowledge Based Identification (KBI). However, from the eSignet’s perspective, we will specifically refer to the authentication method as Knowledge Based Identification (KBI). 2. Given the relatively low level of assurance provided by Knowledge Based Identification (KBI), we recommend that Knowledge Based Authentication (KBA) / Knowledge Based Identification (KBI) should be used for the issuance of Verifiable Credentials (VC) or certificates rather than serving as a primary method of authentication. {% endhint %} ## Repositories Released | Repository Released | Tags | | -------------------------- | ------------------------------------------------------------- | | esignet | [v1.4.0](https://github.com/mosip/esignet) | | mosip-config | [v1.4.0-ES](https://github.com/mosip/mosip-config) | | artifactory-ref-impl | [v1.4.0-ES](https://github.com/mosip/artifactory-ref-impl) | | digital-credential-plugins | [v0.1.0](https://github.com/mosip/digital-credential-plugins) | For details on deployment, refer to the [helm charts](https://github.com/mosip/esignet/tree/v1.4.0/helm) in the eSignet repository. ## Documentation * [Feature Documentation](/home/esignet/esignet-authentication/features) * [Integration Guides](/home/esignet/esignet-authentication/develop/integration/relying-party/development-and-integration-with-esignet) * [End User Guide](/home/esignet/esignet-authentication/test/end-user-guide) * [API Documentation](https://github.com/mosip/esignet/blob/v1.4.0/docs/esignet-openapi.yaml) * [QA Report](/home/esignet/roadmap-and-releases/versions/v1.4.0/test-report) # Test Report 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 configureability 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 The persona-based approach has been adopted to perform the IV\&V(Independent Verification and Validation) by simulating the 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 * Configure-ability * Customize-ability 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 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 centre, processing the packet through the registration processor, 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 which 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 configurations Verification is performed on various configurations as mentioned below: * Default configuration - with 7 Languages (English / Khmer / Hindi / Kannada / Tamil / Arabic / French) **Main features tested** * Signup Portal * Login with Password * Forgot Password * Login with OTP * Login with Biometrics * Login with Inji Wallet App * SubirdRC Integration (Using Inji App) * KBA Downloading and Sharing * KBA Pinning and Unpinning * KBA Backup and restore * KBA remove from the wallet ### Feature health

### Test Execution Statistics #### Functional test results for eSignet Below are the test metrics obtained by performing functional testing for eSignet using mockMDS, mockAuth and mockABIS. 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, and end-to-end flows across multiple languages and configurations. The testing cycle included the simulation of multiple identity schema and respective UI schema configurations. | **Total** | **Passed** | **Failed** | **Skipped** | | --------- | ---------- | ---------- | ----------- | | 2203 | 2085 | 106 | 12 | **Test Rate: 99%** with **Pass Rate: 95%** Here is the detailed breakdown of metrics for eSignet: **API based testing** * Total Test cases: 1575 * Passed: 1499 * Failed: 74 * Skipped: 2 **UI based testing** * Total Test cases: 628 * Passed: 586 * Failed: 32 * Skipped: 10 **API Testrig results for eSignet and Mimoto** **API based testing - eSignet** * Total Test cases: 1279 * Passed: 1194 * Failed: 72 * Skipped: 13 **API based testing - momoto** * Total Test cases: 157 * Passed: 145 * Failed: 12 * Skipped: 0 **Note**: In API Based testing, test cases are marked as skipped as they were not automated. In UI Based testing, test cases are marked as skipped as they were enhancement test cases. #### 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 Link for the [detailed test report](https://github.com/mosip/test-management/tree/master/e-signet/1.4.0). ## Sonar Report ### eSignet

### eSignet Signup Repository --- [Next Page](/llms-full.txt/1)

:rocket-launch:

Getting started

:book:

Core concepts

:graduation-cap:

Guides

:book-open:

Reference

For builders

For admins

For developers