We have an aggregate verifier that is recognized in the dashboard but returns 403 Forbidden at runtime from the signer-service feature-access endpoint. Our standalone custom verifier on the same project works fine, so this looks like a project-level provisioning gap specific to the aggregate verifier path.
Apple Service ID `com.boithebear.web3auth.apple`: added `auth.web3auth.io` domain and `https://auth.web3auth.io/auth\` Return URL, while retaining legacy values
OAuth flow reaches the provider / callback, but wallet derivation fails on return
WalletLoginError: Failed to connect with wallet. Invalid auth connection.
bt: invalid argument 0: hex string has length 0,
want 40 for common.Address
```
Dashboard state:
`boi-aggregate-v3` is listed as Active
Its sub-verifiers are Active
The group shows 2 connections: google + custom
I do not see a self-serve “publish to project”, “link to client_id”, or “enable for sapphire_mainnet” control
Can you please confirm:
Does `boi-aggregate-v3` need a project-level provisioning step that we cannot self-serve from the dashboard?
If yes, can you provision it for this client ID?
If no, what configuration is missing?
Important safety note:
Please do NOT modify `boi-x-verifier` or any existing standalone verifier configuration. It is production-critical and wallet-derivation-sensitive. Any change there would shift MPC wallet addresses for ~1,300 active users. We only need help provisioning / diagnosing the new aggregate verifier path for `boi-aggregate-v3`.
Happy to provide screenshots or a recorded reproduction.
Thanks — I reviewed everything. This is an error report (not a feature exploration). Short answers:
Likely cause: Yes — a 403 from /signer-service/api/feature-access with flags (is_wallet_service, enable_gating, is_whitelabel) strongly indicates project-level feature gating. Aggregate/grouped verifiers often require backend provisioning even if they appear “Active” in the dashboard.
Provisioning: I can escalate this to our backend team to request enabling aggregate verifier support for your project. I will not touch boi-x-verifier (I understand it’s production-critical). If you want me to proceed, confirm and I’ll open the internal request to enable aggregate/grouped auth for Client ID: BM5YfL_9viY2F_4sX3a8uezX7Ky6Is_LdGR9osemzhGZcEZpNtkqX-8kNOuMl9lFGh3LQZ7kwQZdt6iULLCjJeE on network sapphire_mainnet.
Quick config checks to validate while I escalate (no action if you prefer we just provision):
All sub-verifiers use verifierIdField = email (especially Apple — email must be returned or decoded from ID token).
Apple JWT: aud, iss, JWKS and email extraction are correct.
SDK uses exact aggregate verifier name (boi-aggregate-v3) and web3authNetwork = sapphire_mainnet.
What I’ll include in the escalation: your client_id, network, product, domains, the console 403, and your note that standalone verifier boi-x-verifier must not be changed. If you want me to attach screenshots/logs or any additional wording, paste them now; otherwise confirm and I’ll open the provisioning request and loop in the backend. Someone from the team will follow up once they act.
Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.
Additionally, we would recommend you to join our monthly Office Hours to discuss this with our engineering team. MetaMask Developer Office Hours
Please do not modify boi-x-verifier or any existing standalone verifier configuration.
We will keep production rolled back to X-only until your backend team confirms provisioning is complete. After that, we can run a controlled smoke test and report results.
Hi, you can ignore the 403 error if you don’t use Wallet services.
As GET https://api.web3auth.io/signer-service/api/feature-access only checks if you have access to Wallet services or not.
I tested boithebear.com and still could login to your dapp which means the 403 error is not blocking users.
Important clarification: production is currently rolled back to X-only, so a successful login on boithebear.com only proves that the standalone X verifier still works. That path uses boi-x-verifier and is not the failing path.
The failing path only appears when NEXT_PUBLIC_MULTI_PROVIDER_LOGIN_ENABLED=true and the app calls the aggregate verifier boi-aggregate-v3 for Google/Apple.
When that path is enabled, after OAuth returns we get:
WalletLoginError: Invalid auth connection
empty wallet address
EthereumController updateAccount fails because address length is 0
So the issue is not just the visible 403 by itself. The aggregate login path fails to return a usable wallet/account.
Could you please test or inspect boi-aggregate-v3 specifically, not the production X-only login path?
When it failed to login with the new aggregate verifier boi-aggregate-v3, which login method did you use? google or apple? Does Auth0 returns email for apple login?