Site-Global vs Account-Level Identity Verification in QCDS

QCDS can use either a site-wide Identity Verification provider profile managed by a Joomla Super User or a sender-owned account-level profile. The choice affects new Level 2 Requests; Requests already sent stay bound to the exact provider profile selected when they were created.

The Two Configuration Scopes

• Global Site Identity Verification: configured in Joomla Administrator under QC Digital Signature → Identity Verification. Only a Super User can manage this site-level profile.
• Account-Level Identity Verification: configured by an authorized sender in the frontend QCDS Settings page. The profile belongs to that workspace and Joomla user.

Both scopes support Didit and Shufti. Provider credentials are stored locally in encrypted form; signer-facing pages receive the verification state needed for the transaction, not the raw saved credentials.

Global Always Takes Precedence

If an enabled Global profile exists, QCDS uses it for new participants that require Level 2 Identity Verification. The sender's saved account-level profile is preserved but ignored while Global is enabled.

This is a strict override, not a fallback chain. If Global is enabled but its provider connection is not ready, QCDS reports the Global profile as unavailable for new Level 2 Requests rather than silently falling back to a sender's account-level credentials.

What Happens to Account-Level Settings

While Global Identity Verification is enabled, the frontend Settings page tells the sender that the site is providing the provider profile. QCDS preserves the sender's account-level profile, but account-level save, test, and credential-removal operations are blocked until Global Identity Verification is disabled.

After Global is disabled, the sender can again manage and use the preserved account-level profile if it is enabled and its connection is ready.

Existing Sent Requests Do Not Switch Providers

Provider choice is frozen when the Request is sent. Changing from Didit to Shufti, enabling or disabling Global, or editing a sender's account-level settings changes future Request availability; it does not rewrite an existing Request's bound provider profile.

This preservation matters for pending signers. Removing credentials from a profile that still has pending bound Level 2 participants can make those participants show Verification Unavailable until the required provider credentials are restored.

Choose the Scope That Matches Your Governance

Use Global when the site owner wants one centrally controlled provider account for all new Level 2 transactions. Use account-level profiles when individual authorized senders should supply and manage their own provider credentials. In either model, save and test the provider before relying on Level 2 in production.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCDS feature? Visit the QC Digital Signature Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.