feat!: World ID 3.0 compatibility #44

Takaros999 · 2026-01-16T10:13:30Z

This PR:

Adds verification_level and signal to Bridge payload, to keep compatibility with old World App versions and World ID 3.0
Removed VerificationLevel from the SDKs in favor of requests and credentials.

Try this your self by:

pnpm i --frozen-lockfile
pnpm build
cd /js/examples/broswer 
pnpm dev

⚠️ ⚠️ ⚠️ Note: IDKit is still in active development so don't pay too much attention to the interface exposed to RPs, I have many improvements on the way.

Takaros999 · 2026-01-16T10:16:00Z

@codex review

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 01af092d1b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-01-16T10:22:07Z

js/packages/core/src/bridge.ts

+		// Map requests to WASM format
+		const reqs = requests.map((req) => ({
+			credential_type: req.credential_type,
+			signal: typeof req.signal === 'string' ? req.signal : undefined,
+			signal_bytes: req.signal_bytes,


Preserve ABI-encoded request signals

In createClient you only forward req.signal when it is a string. RequestConfig.signal still allows AbiEncodedValue, but those values are dropped here, so the request is sent without a signal. With verification_level/top-level signal removed in this commit, there is no remaining path to pass ABI‑encoded signals, which means proofs will be bound to an empty signal and on‑chain verification that expects the ABI signal will fail. Consider converting AbiEncodedValue to signal_bytes (or rejecting non‑string signals unless signal_bytes is provided).

Useful? React with 👍 / 👎.

will address in another PR

chatgpt-codex-connector · 2026-01-16T10:22:07Z

rust/core/src/types.rs

+    pub fn from_credential_types(types: &[CredentialType]) -> Self {
+        // Check in reverse priority order (least restrictive first)
+        if types.contains(&CredentialType::Device) {
+            Self::Device
+        } else if types.contains(&CredentialType::Face) {


Avoid dropping face when deriving legacy level

from_credential_types chooses Device whenever any device request is present. For mixed request sets like { face, device }, this derives verification_level=Device, which in World App 3.0 allows only device or orb. That silently excludes face even though the request set allowed it, so legacy clients will reject valid face proofs. Consider detecting incompatible mixes (face+device, document+device, etc.) and either error/warn or pick a level that preserves all requested credential types when possible.

Useful? React with 👍 / 👎.

not accurate, this will be refactored

Takaros999 · 2026-01-16T17:33:03Z

rust/core/src/bridge.rs

+///
+/// Priority (most to least restrictive): orb > `secure_document` > document > face > device
+//TODO: This is not 100% accurate, will refine this in a followup PR, but for now it "works".
+fn derive_legacy_fields(requests: &[Request]) -> (VerificationLevel, String) {


@andy-t-wang

This is not final, but basically, I'm picking the minimum credential and hashing the signal.

As I think about this more, I think the better path to migration is to create like 4 types that they can do
OrbMin, DocMin, SecureDocMin, DeviceMin. Put these all under CredentialPreset.Legacy.

If you request anything else we dont support backwards compatibility. After a certain time they can choose to request a new credential. Otherwise there's a ton of edge cases here that I think will be confusing to someone who tries.

What if you have a signal for 4 proofs and you actually want them all. You don't want to just take one proof. What if you have multiple requests with the same credential type. I want an any secure with face auth + orb face, or orb + secure with face auth.

I feel like a bimodal approach here is actually the cleanest

You use our predefined legacy types that you know will work like what you had before. By the time this rolls out formally most people should be on the new type. People will need to update the app anyways to get the new authenticators.

I feel like this roughly outlines what I was thinking. It simplifies the code and our mental model greatly

https://www.notion.so/worldcoin/Migration-Plan-2e98614bdf8c807dbee2fee166d77a5d?source=copy_link

agree, i wanted to get this merged and come back to refactor

Takaros999 · 2026-01-16T17:33:31Z

rust/core/src/bridge.rs

            action_description,
            requests: requests.clone(),
            constraints,
+            signal,


@andy-t-wang

I think this might be breaking too right? In old IDKit we hash the signal in the new one we rely on authenticator to do so.

andy-t-wang · 2026-01-16T18:58:48Z

js/examples/browser/index.html

                    action: ACTION,
-                    verification_level: verificationLevel,
-                    signal: 'demo-signal-' + Date.now(),
+                    requests: requests,


Nit: not sure requests is the right word here. Maybe challenges?

andy-t-wang · 2026-01-16T18:59:28Z

js/packages/core/src/react/types.ts

@@ -1,6 +1,6 @@
 import type { IDKitConfig, ISuccessResult, IErrorState } from '../'

-export type WidgetConfig = Pick<IDKitConfig, 'app_id' | 'action' | 'signal' | 'requests' | 'constraints' | 'bridge_url' | 'partner' | 'action_description'> & {


We need to figure out how to migrate partner since it is used to trigger the Razer flow right now

andy-t-wang · 2026-01-16T19:06:56Z

js/packages/core/src/types/config.ts

-		face_auth?: boolean
-	}>
+	/** Credential requests - at least one required */
+	requests: RequestConfig[]


Nit: Constraints below

andy-t-wang · 2026-01-17T00:34:04Z

js/packages/core/src/bridge.ts

 		await initIDKit()

+		// Validate requests
+		if (!requests || requests.length === 0) {


I feel like we should just decide on the policy/requests thing we are talking about a decision 1 day away

andy-t-wang · 2026-01-17T01:14:49Z

js/packages/core/src/bridge.ts

-		let session: WasmModule.Session
-
-		if (requests && requests.length > 0) {
-			if (verification_level) {


I do think this warn is good. To say if they try to request a type of credential that won't be backwards comaptible

andy-t-wang · 2026-01-17T05:23:30Z

rust/core/src/types.rs

+    ///
+    /// This is the credential type that determines the level (the least restrictive one).
+    #[must_use]
+    pub const fn primary_credential(&self) -> CredentialType {


Not a fan of this

andy-t-wang · 2026-01-17T05:44:26Z

rust/core/src/bridge.rs

+///
+/// Priority (most to least restrictive): orb > `secure_document` > document > face > device
+//TODO: This is not 100% accurate, will refine this in a followup PR, but for now it "works".
+fn derive_legacy_fields(requests: &[Request]) -> (VerificationLevel, String) {


As I think about this more, I think the better path to migration is to create like 4 types that they can do
OrbMin, DocMin, SecureDocMin, DeviceMin. Put these all under CredentialPreset.Legacy.

If you request anything else we dont support backwards compatibility. After a certain time they can choose to request a new credential. Otherwise there's a ton of edge cases here that I think will be confusing to someone who tries.

What if you have a signal for 4 proofs and you actually want them all. You don't want to just take one proof. What if you have multiple requests with the same credential type. I want an any secure with face auth + orb face, or orb + secure with face auth.

I feel like a bimodal approach here is actually the cleanest

You use our predefined legacy types that you know will work like what you had before. By the time this rolls out formally most people should be on the new type. People will need to update the app anyways to get the new authenticators.

andy-t-wang · 2026-01-17T06:04:25Z

rust/core/src/bridge.rs

+///
+/// Priority (most to least restrictive): orb > `secure_document` > document > face > device
+//TODO: This is not 100% accurate, will refine this in a followup PR, but for now it "works".
+fn derive_legacy_fields(requests: &[Request]) -> (VerificationLevel, String) {


I feel like this roughly outlines what I was thinking. It simplifies the code and our mental model greatly

andy-t-wang · 2026-01-17T06:04:27Z

rust/core/src/bridge.rs

+///
+/// Priority (most to least restrictive): orb > `secure_document` > document > face > device
+//TODO: This is not 100% accurate, will refine this in a followup PR, but for now it "works".
+fn derive_legacy_fields(requests: &[Request]) -> (VerificationLevel, String) {


https://www.notion.so/worldcoin/Migration-Plan-2e98614bdf8c807dbee2fee166d77a5d?source=copy_link

andy-t-wang · 2026-01-17T06:08:36Z

rust/core/src/bridge.rs

            action_description,
            requests: requests.clone(),
            constraints,
+            signal,


I think this might be breaking too right? In old IDKit we hash the signal in the new one we rely on authenticator to do so.

Takaros999 added 3 commits January 16, 2026 11:08

feat!: World ID 3.0 compatibility

89dd646

native packages

e3da040

remove ghost button

01af092

clippy

082ca9d

chatgpt-codex-connector bot reviewed Jan 16, 2026

View reviewed changes

Takaros999 marked this pull request as ready for review January 16, 2026 14:30

Takaros999 requested review from 0x1, Gr1dlock, Guardiola31337, SeanROlszewski, andy-t-wang and paolodamico as code owners January 16, 2026 14:30

Takaros999 mentioned this pull request Jan 16, 2026

feat!: Refactor idkit-core JS package #45

Open

Takaros999 commented Jan 16, 2026

View reviewed changes

andy-t-wang reviewed Jan 17, 2026

View reviewed changes

andy-t-wang approved these changes Jan 17, 2026

View reviewed changes

		@@ -1,6 +1,6 @@
		import type { IDKitConfig, ISuccessResult, IErrorState } from '../'

		export type WidgetConfig = Pick<IDKitConfig, 'app_id' \| 'action' \| 'signal' \| 'requests' \| 'constraints' \| 'bridge_url' \| 'partner' \| 'action_description'> & {

feat!: World ID 3.0 compatibility #44

Are you sure you want to change the base?

feat!: World ID 3.0 compatibility #44

Conversation

Takaros999 commented Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Takaros999 commented Jan 16, 2026

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector bot Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Takaros999 commented Jan 16, 2026 •

edited

Loading