Excessively Large URI Generation During Concordium Identity Workflow

I am implementing a migration to a backend infrastructure utilizing the Concordium Node SDK to facilitate signing and transaction operations on behalf of users. The current focus is guiding users through the identity creation process for Concordium identities. However, the generation of the redirect URI is resulting in an excessively large response, leading to browser failures due to URI size constraints.


  • Environment: Concordium Node SDK JS, specifically utilizing the wallet example provided at Concordium GitHub repository.
  • Issue: During the identity creation workflow, the redirect URI generated post identity request is exceptionally large. This size anomaly causes the browser to throw an error related to the URI being too large, thus halting the process.

Code Snippet:

const identityProviders = await fetchIdentityProviders();
const cryptographicParameters = await this.client.getCryptographicParameters();
const identityIndex = 0;
const selectedIdentityProvider = identityProviders[0];
const wallet = ConcordiumHdWallet.fromSeedPhrase("<seed phrase>", "Testnet");
const identityProviderIndex = selectedIdentityProvider.ipInfo.ipIdentity;
const idCredSec = wallet.getIdCredSec(identityProviderIndex, identityIndex).toString('hex');
const prfKey = wallet.getPrfKey(identityProviderIndex, identityIndex).toString('hex');
const blindingRandomness = wallet.getSignatureBlindingRandomness(identityProviderIndex, identityIndex).toString('hex');
const identityRequestInput = {
    arsInfos: selectedIdentityProvider.arsInfos,
    arThreshold: determineAnonymityRevokerThreshold(Object.keys(selectedIdentityProvider.arsInfos).length),
    ipInfo: selectedIdentityProvider.ipInfo,
    globalContext: cryptographicParameters,
const url = await sendIdentityRequest(identityRequestInput, identityProviders[0].metadata.issuanceStart);
return url;

Attempted Solutions:

  • N/A. The issue seems to be directly related to the size of the generated URI and might require optimization or alternative handling of the identity request response.



  • Any guidance or recommendations on how to address or work around this issue would be greatly appreciated. Specifically, insights into minimizing the size of the URI or alternative approaches to handling the identity request and response flow without causing browser limitations to be exceeded.

It’s not exactly redirect_uri that is the problematic part, it’s the “state” parameter.

Unfortunately this is the defined API between the wallet and identity providers. The request is a GET request with parameters being passed in the URL, and that cannot be changed without investment from identity providers.

The request is long because the state parameter contains a number of proofs that the person requesting knows the relevant secrets.

I’m surprised that the browser would complain, we’ve never seen that issue, but we have seen that some network infrastructure (application load balancers or proxies) have restricted long URLs.

Which browser is causing this problem?

This is happening on brave browser at the moment

After reformatting your code in the original message I just noticed that you are not actually sending the request, but rather the inputs to constructing the identity object request.

You should use concordium-node-sdk-js/packages/sdk/src/wasm/identity.ts at 6724364de8e7b4d4086aec0bf379f965b7cf781c · Concordium/concordium-node-sdk-js · GitHub

to actually construct the request to submit.The code you have does not actually typecheck I think.

The resulting URL will still be large, but not as large as you have it now.

Okay changed to this but now I have a new error
Error: The provided seed is invalid as its length was not 128.

This wasn’t happening before. Am i to use a different value?

Also, the rustbindings import seems outdated and throws errors in node environment
import * as wasm from ‘@concordium/rust-bindings/wallet’;

Okay never mind about the first part
changed fromHex to fromSeedPhrase

It generates the link like this
https://id-service.testnet.concordium.com/api/v1/www.gatewayapp.co/confirm-identity#error=Duplicate%20idCredPub which, when opened, shows internal server error on the browser

Appears to be complaining of a duplicate, not sure. Is there a way to work around this? Maybe check status and retrieve instead to prevent this error?

This will determine your “idCredPub” which needs to be unique when requesting an identity.

Have you looked at the flow description concordium-base/identity-provider-service at main · Concordium/concordium-base · GitHub ?

The flow is designed with redirects in mind. When you initiate a flow you supply the URI to which you want to be redirected to. In the example wallet that is set to this concordium-node-sdk-js/examples/wallet/src/util.ts at 6724364de8e7b4d4086aec0bf379f965b7cf781c · Concordium/concordium-node-sdk-js · GitHub

In your case that appears to be www.gatewayapp.co/

You want to intercept that redirect and handle it like the example wallet does concordium-node-sdk-js/examples/wallet/src/CreateIdentity.tsx at main · Concordium/concordium-node-sdk-js · GitHub

OKay but have you tried running the wallet example of late? Its broken

[vite] Internal server error: Failed to resolve entry for package “@concordium/web-sdk”. The package may have incorrect main/module/exports specified in its package.json.
Plugin: vite:import-analysis
File: /Users/emmanuel/Desktop/work_folder/concordium-node-sdk-js/examples/wallet/src/CreateAccount.tsx
at packageEntryFailure (file:///Users/emmanuel/Desktop/work_folder/concordium-node-sdk-js/node_modules/vite/dist/node/chunks/dep-bb8a8339.js:28725:11)
at resolvePackageEntry (file:///Users/emmanuel/Desktop/work_folder/concordium-node-sdk-js/node_modules/vite/dist/node/chunks/dep-bb8a8339.js:28722:5)
at tryNodeResolve (file:///Users/emmanuel/Desktop/work_folder/concordium-node-sdk-js/node_modules/vite/dist/node/chunks/dep-bb8a8339.js:28453:20)
at Context.resolveId (file:///Users/emmanuel/Desktop/work_folder/concordium-node-sdk-js/node_modules/vite/dist/node/chunks/dep-bb8a8339.js:28212:28)
at async Object.resolveId (file:///Users/emmanuel/Desktop/work_folder/concordium-node-sdk-js/node_modules/vite/dist/node/chunks/dep-bb8a8339.js:44276:32)
at async TransformContext.resolve (file:///Users/emmanuel/Desktop/work_folder/concordium-node-sdk-js/node_modules/vite/dist/node/chunks/dep-bb8a8339.js:43992:23)
at async normalizeUrl (file:///Users/emmanuel/Desktop/work_folder/concordium-node-sdk-js/node_modules/vite/dist/node/chunks/dep-bb8a8339.js:41836:34)
at async file:///Users/emmanuel/Desktop/work_folder/concordium-node-sdk-js/node_modules/vite/dist/node/chunks/dep-bb8a8339.js:41998:47
at async Promise.all (index 6)
at async TransformContext.transform (file:///Users/emmanuel/Desktop/work_folder/concordium-node-sdk-js/node_modules/vite/dist/node/chunks/dep-bb8a8339.js:41914:13)
Failed to resolve entry for package “@concordium/web-sdk”. The package may have incorrect main/module/exports specified in its package.json.

Perhaps upgrade to latest release?


So I checked out main of the repository just now, commit 6724364de8e7b4d4086aec0bf379f965b7cf781c and running

yarn & yarn build

in the root of the repository followed by

yarn build && yarn start

in examples/wallet leads me to a functional wallet application that I can access in my browser

If these steps do not work for you, can you specify what steps exactly you have taken since checking out the repository?

Was able to get the wallet example to run but it gets stuck on this page

Can you show the console?

This looks like a JS build issue that I can’t help with.

Perhaps read a guide on how to resolve this Solved: "Cannot Use Import Statement Outside a Module" Error - Kinsta®

Made no changes to the repo. This is resulting from directly cloning the repo


I tried from a fresh checkout of the repository now and the following

git clone --recurse-submodules git@github.com:Concordium/concordium-node-sdk-js.git 
cd ./concordium-node-sdk-js
yarn && yarn build
cd ./examples/wallet
yarn start

gets me to a working page with no warnings. Are you doing something else?

I may add one thing here, if you are using Mac M1 run this npm_config_target_arch=x64 yarn before installing dependencies. And I used this seed phrase generator but couldnt reproduce the issue you are having. Can you let us know if you are still facing?

The issue is not with running the code. It runs fine even if it shows those error in the console. However, after clicking the create identity button, it gets stuck forever on “Generating identity request. This can take a while.”. Seems the service workers arent triggering.
Screenshot 2024-03-27 at 22.00.16. How long is this expected to take?

Thats the issue. If that works on your end then i will check and see if its something wrong on my end

Yes, it does work, it takes a couple of seconds before it redirects to the identity provider.

That should be the expected time range, could be 10s on slower machines.