> For the complete documentation index, see [llms.txt](https://rc.sunbird.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rc.sunbird.org/use/latest-release-v1.0.0/credentialing/v2.1.0-latest.md). # v2.1.0 (latest) ## Standards-Based Wallet Interoperability: OpenID4VC Comes to Sunbird RC **Tag:** `v2.1.0` \ **Github:** [**sunbird-rc**](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.1.0)\ **Released:** 10 August 2026 *** ### Introduction **v2.1.0 is the first feature-bearing release of Sunbird RC in roughly two years** — the last one was `v2.0.2` in August 2024. (`v2.0.3`, in July 2026, was a maintenance release: CVE remediation and stability fixes, no new capability.) It is therefore both a **major feature release** and a **platform-wide upgrade**: every service in the repository has been touched, either to add the new capability or to bring its runtime and dependency tree up to date. **The core feature of this release is OpenID Connect for Verifiable Credentials (OID4VC).** Until now, getting a Sunbird RC credential into a wallet meant integrating against Sunbird's own APIs. From v2.1.0 the platform speaks the standards that wallets already speak — **OpenID4VCI 1.0** for issuance and **OpenID4VP 1.0/draft-23** for presentation — via a new `oid4vc-service`. Any conformant wallet can now receive a credential from a Sunbird RC deployment and present it back to a Sunbird RC verifier, with no Sunbird-specific integration on the wallet side. Three things make this a genuinely additive release rather than a migration: 1. **Nothing existing changes.** `oid4vc-service` is a protocol façade. It holds no credential keys and no credential storage of its own; it delegates every key operation and every persistence concern to the services that already own them. The registry's hook into it is flag-gated and off by default (`oid4vc.enabled=false`), fail-open, and cannot fail entity creation or claim grant. The service ships behind a Docker Compose profile (`--profile oid4vc`) and its nginx routes are separate, gated locations that degrade gracefully rather than blocking gateway startup. 2. **Four credential formats are supported end-to-end** — `ldp_vc`, `jwt_vc_json`, `vc+sd-jwt`, and `mso_mdoc` — including selective disclosure, and all four were verified issuance-through-verification in a self-driven harness. Two of them were additionally confirmed against independent third-party wallets in real interop testing. 3. **W3C VC Data Model 2.0** support lands alongside the existing 1.1 support, opt-in via `@context`, with no database migration and no behavior change for existing callers. Alongside the feature work, this release completes a **security and dependency pass across the whole platform**: a focused review of the new OID4VC code path (8 fixes, all pre-release), a CVE remediation sweep across the Java registry and both Java services, and Go/Node runtime and library upgrades everywhere else. Service-by-service detail is in the next section. *** ### Service-by-Service Upgrade Status
ServiceStatus in v2.1.0What changed
oid4vc-serviceNew serviceThe OpenID4VCI / OpenID4VP protocol façade. Modules for oid4vci, oid4vp, session store, auth, and downstream clients. Ships as a new Docker image and under the optional oid4vc Compose profile. Stateless with respect to keys and credential storage.
credentials-serviceFeature upgradeW3C VC Data Model 2.0 support; new credential-format abstraction layer covering all four formats; status-list (revocation) support; Prisma migration add_vc_format_enveloped_statuslist. Dependencies: @digitalbazaar/vc 6.3 → 7.1.1, added @digitalbazaar/credentials-context 3.2.
identity-serviceFeature upgradeNew signing endpoints /utils/sign-jwt, /utils/sign-sd-jwt, /utils/sign-mdoc; published JWKS at /.well-known/jwks.json; resolution for self-contained DID methods (did:key, did:jwk) for holder binding; vault write hardening with new unit tests. Dependencies: added @auth0/mdl 3.0, @peculiar/x509 1.9, jose 4.15, @digitalbazaar/credentials-context 3.2.
credential-schemaFeature upgradeSchemas can opt into OID4VCI via a new oid4vciConfig block (formats, render method); surfaced through the new GET /credential-schema/oid4vci-configsendpoint. Prisma migration add_oid4vci_config. No dependency changes.
encryption-serviceMaintenance upgradeCVE remediation pass in pom.xml, no functional change: spring-framework → 5.3.39, spring-security → 5.8.16, jackson-core → 2.18.8 / jackson-databind → 2.18.9, snakeyaml → 2.0, nimbus-jose-jwt → 9.37.2, postgresql → 42.7.12, kafka-clients → 3.9.2, spring-kafka → 2.9.13, commons-io → 2.14.0, snappy-java → 1.1.10.4, lz4-java → 1.8.1, org.json → 20231013, libthrift → 0.14.0, mssql-jdbc → 12.8.2.jre11.
id-gen-serviceMaintenance upgradeSame CVE remediation pass as encryption-service, applied to this service's own pom.xml. No functional change.
notification-serviceMaintenance upgradeGo 1.23 → 1.25. SMS client migrated off the unmaintained imroc/req to go-resty/resty v2.17.2. golang.org/x/net → 0.57.0, golang.org/x/text → 0.40.0, golang.org/x/sys → 0.47.0. Behaviour unchanged.
metricsMaintenance upgradeGo 1.24 → 1.25. go-redis/v9 9.0.5 → 9.6.3, golang.org/x/net 0.50.0 → 0.57.0, golang.org/x/sys → 0.47.0. No functional change.
nginx gatewayConfig upgradeNew public routes for the OID4VC endpoints, gated so they degrade gracefully rather than blocking gateway startup on deployments that don't enable the feature. nginx.confis now bind-mounted in Compose so local edits take effect.
**Upgrade takeaway:** every service ships a new image in v2.1.0. Deployments that do not want OID4VC can upgrade for the security and runtime fixes alone and see **no behavioural change** — the new service need not be deployed. *** ### OpenID4VCI Credential Issuance A new `oid4vc-service` speaks OpenID4VCI 1.0 (with an optional `DRAFT13_COMPAT_MODE`) on the wallet-facing side, while delegating all key operations and storage to the existing platform services — it holds no credential keys and no credential storage of its own. It supports: * Discovery via `.well-known/openid-credential-issuer`, sourced live from `credential-schema`'s opted-in schemas. * The `pre-authorized_code` grant, with atomically single-use codes and `c_nonce` values. * Proof-of-possession verification at the credential endpoint, supporting both DID-bound (`kid`) and inline-JWK (`did:jwk`) holder keys. * Deferred issuance for credentials pending an external claim resolution. * W3C VC Render Method support (inline SVG or hosted URL) for wallet-side visual rendering. ### OpenID4VP Presentation Verification The same service also implements OpenID4VP 1.0/draft-23 for verifiers: * Presentation requests default to a signed JAR (`did:`-prefixed `client_id`); an unsigned mode and a legacy pre-draft-22 shape (`OID4VP_LEGACY_CLIENT_ID_SCHEME`) are available for wallets that haven't caught up to the latest draft. * DCQL (Digital Credentials Query Language) evaluation against disclosed claims. * A six-point verification chain per presentation — holder/device signature, nonce/session-transcript freshness, credential signature, revocation, holder binding, and DCQL satisfaction — all of which must pass before a verifier's `GET /vp/status/:id` reports `verified: true`. ### Credential Format Support Four credential formats are supported end-to-end, selected per schema via `oid4vciConfig.oid4vciFormats`: | Format | Selective disclosure | Notes | | ------------- | -------------------- | ----------------------------------------- | | `ldp_vc` | No | W3C Data Integrity (Ed25519Signature2020) | | `jwt_vc_json` | No | W3C VC-JWT convention | | `vc+sd-jwt` | Yes | IETF SD-JWT VC | | `mso_mdoc` | Yes (per-element) | ISO/IEC 18013-5 mobile documents | All four formats were verified end-to-end in a self-driven test harness (issuance → wallet receipt → presentation → verification, all checks OK), and `jwt_vc_json` / `vc+sd-jwt` were additionally confirmed against two independent third-party wallets — [**Paradym Wallet**](https://paradym.id/) (presentation) and [**walt.id Wallet**](https://walt.id/wallet) (issuance and presentation) — in real interop testing. 👉 [**See Wallet Integration**](https://rc.sunbird.org/use/integrations/wallet-integration) for the demo apps, per-wallet interop results, and the wallet-compatibility configuration flags. ### W3C VC Data Model 2.0 `credentials-service` now supports the W3C Verifiable Credentials Data Model 2.0 alongside the existing 1.1 support: * **Context-aware issuance:** the `@context` on an incoming credential request determines whether `validFrom`/`validUntil` (2.0) or `issuanceDate`/`expirationDate` (1.1) are populated — existing 1.1 callers see no behavior change. * Verification reads whichever date fields are present, so 1.1 and 2.0 credentials both verify correctly. * **No database migration required** — 2.0's date fields map onto the existing `issuanceDate`/`expirationDate`columns. * Fully backward compatible and opt-in: existing credential templates keep issuing 1.1 credentials until explicitly updated to a 2.0 `@context`. ### Supporting Service Enhancements * **`identity-service`:** new signing endpoints for the additional formats (`/utils/sign-jwt`, `/utils/sign-sd-jwt`, `/utils/sign-mdoc`), a published JWKS endpoint (`/.well-known/jwks.json`), and resolution support for self-contained DID methods (`did:key`, `did:jwk`) needed for wallet holder-binding. * **`credential-schema`:** schemas can now opt into OID4VCI via an `oid4vciConfig` block, surfaced through a new `/credential-schema/oid4vci-configs` endpoint. * **`credentials-service`:** a credential-format abstraction layer and status-list (revocation) support, now active across all four formats. * **`nginx`:** new public gateway routes for the OID4VC endpoints, gated so they degrade gracefully rather than blocking gateway startup on deployments that don't enable the feature. ### Security Hardening A focused security review of the new OID4VC code path led to several fixes prior to this release: * Closed a replay bypass where a presented SD-JWT with its Key Binding JWT stripped could be accepted without proof of holder possession. * Closed a holder-binding bypass where a self-asserted inline JWK header wasn't checked against the DID it claimed to represent, at both issuance and presentation time. * Made pre-authorized-code and nonce consumption genuinely atomic under concurrent requests (in-memory session store). * Made status-list index allocation atomic, preventing double-allocation of a revocation index under concurrent issuance. * Hardened key storage against silently overwriting an existing secret on a transient vault error. * Pinned JWT verification to a fixed signing algorithm and stopped falling back to an unrelated key on a `kid`mismatch. * Added authentication to the two remaining unauthenticated internal verifier endpoints. * Mitigated a stored-XSS vector in schema-supplied SVG render templates. Separately, the platform-wide CVE remediation pass covering the Java registry, `encryption-service`, `id-gen-service`, and the Go services is summarised per service in the table above. ### Docker Images A new image, **`sunbird-rc-oid4vc-service`**, is published alongside the existing platform images. As with prior releases, the `latest` tag always points to the latest version of the platform; this release is tagged **`v2.1.0`**. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://rc.sunbird.org/use/latest-release-v1.0.0/credentialing/v2.1.0-latest.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.