User Identity Repository
Component Detail
Description
Manages persistence and retrieval of verified user identity data in Supabase, including personnummer obtained via Vipps Login and BankID verification status. Provides the data layer for syncing identity data back to organization membership systems.
user-identity-repository
Summaries
The User Identity Repository is the foundational trust layer that enables the platform to operate as a compliant, verified identity service. By securely persisting government-grade identity data — including Norwegian national identification numbers obtained through Vipps Login and BankID — the system can guarantee that every user is who they claim to be. This directly reduces fraud risk, eliminates manual identity verification overhead, and opens the platform to regulated use cases that require verified membership. The automatic sync back to organization membership systems removes administrative burden from staff, accelerating onboarding and reducing human error.
For organizations operating under compliance mandates around member identity, this component is the key enabler of regulatory adherence without operational cost.
The User Identity Repository sits at the intersection of the mobile app and backend infrastructure, making it a coordination point between multiple workstreams. It has no declared inter-service dependencies, but relies implicitly on Supabase schema readiness for the user profile and organization membership tables — any delays in database schema finalization will block this component. The sync-to-membership interface introduces a cross-system dependency that must be coordinated with the organization management team. Testing requires real or mocked Vipps/BankID flows, adding QA complexity.
Medium complexity rating reflects this coordination surface rather than intrinsic code difficulty. Plan for integration testing time across both mobile and backend execution contexts, and ensure Supabase row-level security policies are reviewed before deployment.
User Identity Repository is a data-layer component operating across mobile and backend execution contexts, backed by Supabase (PostgreSQL). The core interfaces follow an async Future-based pattern consistent with Dart/Flutter conventions. `savePersonnummer` and `getBankIdVerified` read/write to the Supabase `user_profiles` table — ensure RLS policies allow authenticated users to read their own records only. The `syncIdentityToMembership` method performs a cross-table write to the organization membership record and should be wrapped in a database transaction or handled via a Supabase Edge Function to maintain consistency.
BankID verification status includes a timestamp field — confirm the schema stores `verified_at` for audit purposes. No in-memory caching is implemented; callers performing authorization checks should cache results at the service layer to avoid repeated DB round-trips.
Responsibilities
- Store and retrieve personnummer in the Supabase user profile
- Record BankID verification status and timestamp per user
- Sync updated identity fields to the organization membership record
- Provide read access to identity verification state for authorization decisions
Interfaces
savePersonnummer(userId: String, nin: String): Future<void>
getPersonnummer(userId: String): Future<String?>
setBankIdVerified(userId: String, verified: bool): Future<void>
isBankIdVerified(userId: String): Future<bool>
syncIdentityToMembership(userId: String, orgId: String): Future<void>
getUserIdentityRecord(userId: String): Future<UserIdentity?>
Relationships
Used Integrations (1)
External integrations and APIs this component relies on