Signet
GitHubCommunityWhat's New
  • 🌐eSignet
  • 🔍Overview
    • ✨Features
      • Signup Portal
    • âš–ī¸Principles
    • 📏Standards & Security
    • 📜License
  • đŸ’ģDevelop
    • đŸĻžTechnology
      • đŸ“ĻTechnology Stack
      • âš™ī¸Components - eSignet
      • đŸ¤ŗComponents - Signup Portal
      • 📲API
    • âš™ī¸Configure eSignet
      • ACR
      • Claims
      • .well-known
        • jwks.json
        • oauth-configuration
        • openid-configuration
  • 🎮Test
    • đŸ•šī¸Try It Out
      • Using Mock Data
      • Register Yourself
      • Integrate with eSignet
    • 👨‍đŸ’ģEnd User Guide
      • Health Portal
        • Login with Biometrics
        • Login with Password
        • Login with OTP
        • Login with QR code (Inji)
        • Knowledge Based Identification
        • Signup and Login with OTP for Verified Claims
    • 🧩Integration Guides - eSignet
      • Authenticator Plugin
      • Key Binder Plugin
      • Audit Plugin
      • Digital Wallet
        • Credential Holder
        • Wallet Authenticator
      • Relying Party
    • 🔐Integration Guide - Signup Portal
      • Identity Verifier Plugin
      • Profile Registry Plugin
      • Integration with eSignet portal
  • đŸ› ī¸Deploy
    • â›´ī¸Deployment Architecture
      • On-Prem Installation Guidelines
    • ⚓Local Deployment
      • Mock Identity System
      • Mock Relying Party
  • 🔌Interoperability
    • MOSIP
    • Inji
    • OpenCRVS
  • 🚀Roadmap and Releases
    • đŸ›Ŗī¸Roadmap
      • Roadmap 2025
      • Roadmap 2024
    • 📖Releases
      • v1.5.1
        • Test Report
      • v1.5.0
        • Test Report
      • v1.4.2
      • v1.4.1
        • Test Report
      • v1.4.0
        • Test Report
      • v1.3.0
        • Test Report
      • v1.2.0
        • Test Report
      • v1.1.0
        • Test Report
      • v1.0.0
        • Test Report
      • v0.9.0
        • Test Report
  • 🤝Community
    • Code Contribution
    • Code of Conduct
  • 📌General
    • 📚Resources
    • ❓FAQs
    • 💡Glossary
Powered by GitBook

Copyright Š 2021 MOSIP. This work is licensed under a Creative Commons Attribution (CC-BY-4.0) International License unless otherwise noted.

On this page

Was this helpful?

Edit on GitHub
Export as PDF
  1. Develop
  2. Configure eSignet

ACR

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

ACR values are used to convey information about how a user was authenticated and the strength of that authentication. ACR values are typically defined by identity providers and relying parties to communicate the level of trust and security associated with an authentication event. These values can vary from one system to another but are often used to indicate different levels of assurance.

The specific meaning and usage of ACR values may vary depending on the context and the identity system in use. They provide a way to communicate the security and assurance level associated with an authentication event, allowing relying parties to make access control decisions based on this information.

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

Supported ACRs

eSignet currently supports the below ACR values:

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

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

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

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

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

Note: acr_values request parameter in the /authorize request takes the above values as a space-separated list in any combination.

Note: Wallet binding is a separate process where the RSA public key and the individual ID are shared with the server, and the server then returns the signed certificate to the wallet.

Last updated 5 months ago

Was this helpful?

đŸ’ģ
âš™ī¸