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