The wallet holds identity
Government ID data and derived attributes (age, residency, affiliation, KYC status) live in the user's wallet. During policy checks, raw images and full identity fields do not leave the device.
Technical Architecture
Double-blind by design.
Nexion's architecture is built so that no single party sees the full picture of who, where, and what. The wallet holds identity, your product sees policies and decisions, and Nexion cannot track where checks happen.
This page is for security, privacy, and architecture teams who want to see how the model works under the hood—for both web2 and web3 deployments.
Core Principle
The double-blind verification model
Double-blind verification means no single actor can reconstruct the full story of who a user is, where they used their credential, and what they were accessing.
The verifier sees rules and outcomes
Your systems see the access rule you asked for, its Pass/Fail decision, and the corresponding policy receipt. That is enough to prove enforcement and debug flows, without building central identity profiles.
Nexion does not track where it is used
Presentations are verifier-bound and the wallet does not call home during checks, so Nexion does not receive telemetry about which sites, apps, or protocols a user proves policies to. You keep local evidence; we cannot track usage across verifiers.
This split aligns closely with privacy-by-design obligations and the emerging EUDI wallet pattern.
Data Distribution
What data lives where
On the user's device (wallet)
- Government ID data and biometric data used during issuance
- Verifiable credentials (e.g., "over 18", "resident of country X", "passed KYC for product Y")
- Local logs of where credentials have been presented (for user visibility)
In your systems (verifier)
- Policies and rules you define (age, region, eligibility, KYC requirements, limits, etc.)
- Pass/Fail outcomes for each check
- Policy receipts for audit and investigation purposes
- Standard auth, risk, and access logs you already maintain
At Nexion
- Configuration for supported policies and verifiers
- Issuer metadata, keys, and revocation information
- Operational telemetry needed to run the service (minimised and aggregated where possible)
What Nexion intentionally does not keep
- No central map of which user accessed which verifier with which policy
- No central storage of raw ID images or biometric data
- No centralised logs of user-by-user verification history across verifiers
Privacy Guarantees
Wallet behaviour and privacy guarantees
No phone-home during checks
When the wallet proves a policy to your verifier, it does not contact Nexion's servers to report that event.
Verifier binding
Presentations are bound to a specific verifier, limiting replay across different sites, apps, or protocols.
Selective disclosure
Only the attributes required for a given policy are used in the evaluation; the rest of the credential stays local.
User control
Users can see where their credential has been used and can revoke devices if they are lost.
Combined, these guarantees reduce correlation and tracking risks, while still giving you strong, auditable decisions.
Security
Security controls
Nexion is designed as a security-sensitive dependency in your stack; controls reflect that assumption.
Issuance: High-assurance eKYC (document, biometric, liveness) via vetted providers, aligned with recognised standards (e.g., NIST SP 800-63-4 IAL2).
Encryption: Data encrypted in transit and at rest, with hardened key management for cryptographic material.
Key handling: Clear separation between keys used for issuing credentials, verifying presentations, and signing receipts.
Operational security: Least-privilege access, logging, and monitoring around sensitive services.
SOC 2 Type I in progress: In progress with external testing and review.
For more detail on controls, attestations, and third-party audits, see the Security & Trust page.
Standards
Standards and interoperability
Nexion is built on open standards so that you can plug it into existing identity and wallet ecosystems, and evolve with them over time.
EUDI-compatible architecture
Follows the same pattern as the European Digital Identity wallet model (identity in the wallet; policies and decisions at the verifier).
W3C Verifiable Credentials 2.0
Used to represent claims such as age, residency, affiliation, or KYC status in a structured, portable format.
OID4VP 1.0
OpenID for Verifiable Presentations used to request and validate proofs from wallets to verifiers.
For implementers, the Developers section provides concrete examples of how these standards appear in requests and responses.
FAQ
Architecture & privacy FAQ
Can Nexion see where our users are being verified?
No. Presentations are verifier-bound, and the wallet does not call home to Nexion during policy checks. Nexion does not maintain a central log of which user accessed which verifier with which policy. You keep local receipts and logs; Nexion sees configuration and operational telemetry only.
Can a breach at Nexion reconstruct full identity profiles?
The architecture is designed so that identity data and attributes live in the wallet, not at Nexion. A breach at Nexion would not expose a centralised repository of user IDs, documents, or full verification histories across verifiers. You should still evaluate Nexion as a critical dependency, but the data surface is intentionally limited.
How does this interact with our own logging and monitoring?
Policy receipts are simple signed JSON objects that can be written into your existing logging and monitoring pipelines. They provide evidence that a policy ran and what decision it produced, without adding long-lived identity attributes to those logs.
Have technical questions about integration? Visit our developer docs