AstruVerify is a broker, not a new identity warehouse.
The intended production model is federated: the bank remains the identity provider, the citizen controls consent, and the requesting organisation receives only a signed result for the claims it requested.
Requests selected facts
Name, ID match, age threshold, or account relationship.
Creates consent request
Stores the minimum required transaction and audit metadata.
Authenticates customer
App PIN, OTP, passkey, assisted process, or another bank-approved method.
Returns verified claims
Signed, time-limited, consented and auditable.
Role separation now implemented
Citizen accounts own wallets and consent. Organisation accounts create requests, Bank accounts see only requests routed to their bank, and Administrator accounts manage trusted access. Public registration cannot self-assign a privileged role.
What AstruVerify should not store
- Fingerprints or facial templates
- Bank passwords or PINs
- Bank balances or transaction histories
- Unrequested identity attributes
What the production version needs
- Bank / digital identity provider APIs
- Asymmetric signing keys in an HSM or managed key vault
- Strong relying-party authentication
- POPIA, FICA and security review
- Revocation, expiry and incident controls
Campaign advocacy is not part of the identity trust chain.
JusticeSA may explain biometric exclusion, gather campaign participation under its own privacy controls, and link a person to AstruVerify. It is not automatically an Identity Provider, relying organisation or administrator merely because it promotes the solution.
Authenticated AstruVerify pages are not embedded in JusticeSA, and AstruVerify does not send JusticeSA citizen wallets, assertions, consent receipts, bank credentials or provider secrets. The only optional public integration is a small-sample-suppressed aggregate impact feed.
JusticeSA + AstruVerify integration