Aggregate verifier returns 403 on feature-access — needs provisioning

Embedded Wallets (Web3Auth)
,
1

Hi MetaMask / Web3Auth team,

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.

Project details:

  • Client ID: BM5YfL_9viY2F_4sX3a8uezX7Ky6Is_LdGR9osemzhGZcEZpNtkqX-8kNOuMl9lFGh3LQZ7kwQZdt6iULLCjJeE
  • Network: sapphire_mainnet
  • Product: Plug and Play / Embedded Wallets, Web Application
  • SDK: @web3auth/modal v10
  • Domains: www.boithebear.com, boithebear.com

Working existing verifier:

  • Custom JWT verifier `boi-x-verifier` (Sub-keyed)
  • Used standalone and derives wallets correctly for ~1,300 users

Failing newly-created aggregate:

  • Group connection `boi-aggregate-v3` (Email-keyed)
  • Sub-verifiers:
    • `boi-google-social-v1` (Google built-in social, custom Client ID)
    • `boi-apple-v3` (Custom JWT, Apple JWKS / aud / iss configured)

What we already tried:

Runtime console error:
```text
GET https://api.web3auth.io/signer-service/api/feature-access
?client_id=BM5YfL…
&is_wallet_service=true
&enable_gating=true
&is_whitelabel=true
→ 403 Forbidden

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:

  1. Does `boi-aggregate-v3` need a project-level provisioning step that we cannot self-serve from the dashboard?
  2. If yes, can you provision it for this client ID?
  3. 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.

2

Thanks — I reviewed everything. This is an error report (not a feature exploration). Short answers:

  1. 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.

  2. 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.

  3. 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.
  • Both domains (boithebear.com, www.boithebear.com) are allowlisted.

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

3

Yes, please proceed with the internal provisioning request.

Please enable aggregate/grouped auth support for this exact setup:

Client ID: BM5YfL_9viY2F_4sX3a8uezX7Ky6Is_LdGR9osemzhGZcEZpNtkqX-8kNOuMl9lFGh3LQZ7kwQZdt6iULLCjJeE
Network: sapphire_mainnet
Aggregate verifier: boi-aggregate-v3
Sub-verifiers:

  • boi-google-social-v1
  • boi-apple-v3

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.