For the complete documentation index, see llms.txt. This page is also available as Markdown.

Version 1.0.0-alpha.1

Release Name: Inji Verify v1.0.0-alpha.1

Support: Developer Release

Release Date: 4th August, 2026

Overview

We are excited to bring the release of Inji Verify v1.0.0-alpha.1. This release completes Inji Verify's move to DCQL (Digital Credentials Query Language) — the OpenID4VP 1.0 way of describing what a verifier needs from a wallet — across the entire verification flow: authorization requests, VP token submission, validation, and results. The core change is the migration from Presentation Exchange (PEX) to DCQL (Digital Credentials Query Language).

Presentation Exchange (presentation_definition) is no longer accepted for new requests; only previously completed PD-based verifications remain readable through the result-fetch endpoints.

Highlights

  • Stronger holder proofrequire_cryptographic_holder_binding lets verifiers demand cryptographic proof of holder possession for both SD-JWT VC and LDP_VC presentations, replacing the older acceptVPWithoutHolderProof flag.

  • Wider SD-JWT compatibility — both vc+sd-jwt and dc+sd-jwt format identifiers are accepted, so wallets built against either the draft or final SD-JWT VC spec continue to verify.

  • Replay protection — KB-JWT nonce and aud claims are validated on every SD-JWT submission, so a captured presentation can't be resubmitted elsewhere.

  • Tamper-resistant sessions — VP request expiry and duplicate submissions are now enforced server-side, not left to the wallet to self-report.

  • More accurate credential matching — the Verify UI matches submitted credentials against DCQL type_values, keeping matches correct when multiple verifier configurations share a credential type.

  • Spec-aligned protocol fields — client ID scheme, client_metadata handling, and supported-formats fields are updated to match OpenID4VP 1.0. Full field-level detail: API Changes.

Note: The Inji Verify UI is a reference implementation to demonstrate orchestration. Developers can selectively embed SDK components in the verifier applications as per their needs.

Repositories: Released/Dependent

Inji Verify Repo → 4 projects (all these projects are of same version) as below:

Repositories
Tags: Released/Dependent

vc-verifier

v1.9.0

inji-verify

v1.0.0-alpha.1

Compatible modules

The following table outlines the tested and certified compatibility of Inji Verify v1.0.0-alpha.1 with other modules.

Module
Version

Pixel-Pass library

0.8.0

Inji Wallet

1.0.0-alpha.1 (Release Coming Soon)

Inji Web

1.0.0-alpha.1 (Release Coming Soon)

Bug Fixes

Below is the list of fixes as part of the v1.0.0-alpha.1 release, refer here for the comprehensive list.

Bug ID
Description

#2086

Verify library contributes global servlet context path when embedded in Certify.

#1919

Upload valid claim 169 QR code shows invalid result intermittently.

#1920

Scan QR Code feature returns invalid result for valid VC intermittently across multiple camera scenarios.

#2045

Nonce validation gaps in VP request creation.

#2062

Possible race condition in VP submission: status listener notified before transaction commits.

#1928

Open INJI-Verify application Navigate to Verify Credentials Select Scan QR Code tab Disable internet connection (simulate offline mode) Click on Scan QR Code button Observe the behaviour after scan failure / retry.

User Stories

Story ID
Description

#1721

Changes in client_id did prefix as per OpenID4VP spec v1.0.

#1758

Changes in client_metadata as per OpenID4VP spec v1.0.

#1765

Handling client_metadata for Pre-registered client_id Scheme as per OpenID4VP spec v1.0.

#1768

DCQL support in Authorization Request as per OpenID4VP spec v1.0

#1703

Migrate OpenID4VP response handling from PEX to DCQL and implement vp_token validations.

#1935

VP Token DCQL Query Satisfaction at Submission Stage.

#1957

VP Result Processing & Validation (DCQL + Legacy Support).

#1961

Inji Verify must support both vc+sd-jwt and dc+sd-jwt as credential format.

#1965

Support require_cryptographic_holder_binding in DCQL during VP submission for LDP_VC.

#1988

Support require_cryptographic_holder_binding in DCQL during VP submission for SD-JWT VC.

#1940

Remove presentation_definition Table.

#2034

Replace acceptVPWithoutHolderProof with DCQL require_cryptographic_holder_binding in Verify UI.

#1973

Enforce VP Request Expiry and Prevent Duplicate VP Submission on Server Side.

#2049

Verify UI: Match Submitted Credentials Using DCQL type_values Instead of Configuration type.

#2043

Validate nonce and aud claims from Key Binding JWT (KB-JWT) for SD-JWT VP submissions.

Known Issues

Below is a list of some key known issues. For a detailed overview and the complete list of issues related to Inji Verify, please click here.

Issue ID
Description

#1845

We are uploading an invalid QR code, and while it displays an error message stating that the QR code is invalid, the credential details are still visible.

#1844

On iPhone 8 and iPhone 7, uploading the Injiweb QR code PDF shows an error message.

#1852

Inji Verify - Upload not functioning on Mac Safari Browser Versions 16 and below.

#1789

INJI Verify SDK should be able to support integration with applications built on platforms beyond React (Typescript) applications, such as Angular, PHP, and others.

#2178

The latest Inji Verify release cannot support complete end-to-end testing of VP (Verifiable Presentation) flow and Data Share flow when integrated with Inji Web.

API Changes

Refer here for 'Changes to API' and 'New APIs'.

Removals & Replacements

The following are no longer supported in this release. See the PEX to DCQL Migration Guide to update existing integrations.

Removed
Replaced By
What This Means

Presentation Exchange (presentation_definition, presentationDefinitionId)

DCQL (dcql_query)

New requests using PD are rejected; previously completed PD-based results remain readable via result-fetch endpoints only.

acceptVPWithoutHolderProof

require_cryptographic_holder_binding

Holder-proof enforcement is now expressed inside the DCQL query itself.

presentation_submission

— (DCQL-only)

This field is no longer accepted; DCQL query IDs identify submissions instead.

Legacy request endpoints (/vp-request, /vp-session-request, /vp-request/{requestId}, /vp-submission/direct-post)

/v2 counterparts

Existing integrations calling these paths must move to the /v2 endpoints.

Documentation

Last updated

Was this helpful?