01Control plane and identity payloads are different data classes
The control plane needs to know which organisations, relying parties, applications and policies exist. It does not need a historical database containing every credential value users presented.
That separation is already reflected in the database model: verification transactions store operational state and non-sensitive metadata, while comments and schema constraints explicitly prohibit wallet payloads and claim values from those records.
Least privilege starts at the database
All current application tables use row-level security. Public anonymous table access is revoked, tenant-aware relationships prevent cross-organisation references, and API keys are modelled as one-way hashes rather than retrievable secrets.
The current Supabase security advisor reports no security lints on the initial control-plane schema.
Production verifier trust stays separate
The production verifier will require certificate and trust material that should not be treated like ordinary web application configuration. The architecture therefore allows the verifier core and key management to move to dedicated EU-hosted infrastructure while the public API contract remains unchanged.
That production trust layer will be enabled only after interoperability testing, certificate lifecycle design and operational monitoring are in place.