Design goals and production evidence
The wallet and processing stack are reference software. Production adapters, independent assurance and real-device testing are separate requirements. The educational demo handles fictional data locally and does not use an enclave or verify identity.
Start with less information
The reference design keeps original document images on the user's device and limits approved submissions to the data needed for a particular verification. The proposed membership pilot can instead reuse a credential from an accountable issuer's existing process. Its relying services need a membership answer, not source evidence.
Where confidential processing fits
Trusted execution environments and confidential computing are intended to isolate processing from some infrastructure access. The repository contains enclave-related implementations. Protection must be assessed for the selected hardware, code, key provisioning, logs and operational configuration; it is not a guarantee that no person or vulnerability can ever expose information.
What attestation establishes
An attestation can provide evidence about an environment and its measured software, subject to the platform's verification rules. A deployment must validate authenticity, freshness and the approved measurement before releasing data or keys.
Attestation alone does not establish that the code is safe, that its inputs represent a real person, or that all output, telemetry and retained records are harmless. Those need separate review and testing.
Key controls need their own evidence
Document how keys are created, provisioned, sealed, rotated, recovered and destroyed. Identify every authority that can change approved software or release policies. Do not assume every supported platform uses the same key derivation or that a key can never be copied, misused or exposed.
Data and records that remain
- Issuer evidence: governed by the issuer's lawful process and agreed retention.
- Wallet credentials and keys: need device protection, recovery and loss handling.
- Derived verification data: requires an explicit inventory, approved processors and lifecycle.
- Verifier receipts and logs: need access controls and proportionate retention.
- Network metadata: public identifiers and timing may permit correlation; encryption does not conceal every relationship.
Withdrawal and deletion
Withdrawing consent should stop future sharing under that consent. It does not undo a previous disclosure or automatically erase lawful service records. Deletion and key destruction need verifiable procedures, including backups, copies and any immutable chain records.
A real pilot must agree the retention period and deletion limits before taking participant data. The privacy policy provides the policy context; any pilot requires its own accurate scope notice.
What must be demonstrated before a real pilot
- Working encryption and device adapters, with development fallbacks excluded.
- Validated attestation and key-release controls for the selected deployment, where confidential processing is used.
- Reviewed software, including issuer/holder binding, proof construction and replay prevention.
- End-to-end data inventory, logs, backups, retention and deletion tests.
- Independent security and privacy assessment, incident response and accessible recovery.
Inspect the reference repository · Read the proposed pilot data flow · Review the pilot proposal