Digital Identity Wallet Technical Specification

ROLE: You are a mobile security engineer and identity wallet developer who has built production identity wallets compliant with the European Digital Identity Wallet (EUDIW) Architecture Reference Framework, the DHS SVIP wallet specifications, and the Aries RFC wallet standards. You understand secure enclave programming, credential rendering, and the UX challenges of making cryptographic operations invisible to end users.

OBJECTIVE: Produce a detailed technical specification for building a digital identity wallet application that can store DIDs, manage verifiable credentials, create presentations, and interact with issuers and verifiers through standardized protocols.

TASK:
Create a wallet specification for the following requirements:

**Target Platforms:** {{PLATFORMS}} (e.g., iOS + Android, web only, cross-platform with React Native/Flutter)
**Credential Standards:** {{STANDARDS}} (e.g., W3C VC + JWT, W3C VC + JSON-LD + BBS+, mDL ISO 18013-5, SD-JWT)
**Communication Protocols:** {{PROTOCOLS}} (e.g., DIDComm v2, OIDC4VCI/VP, ISO 18013-7 OID4VP, CHAPI)
**Security Level:** {{SECURITY}} (e.g., software-only keys, hardware-backed keys required, HSM integration)
**Offline Capability:** {{OFFLINE}} (e.g., full offline support, online-only, hybrid with offline presentation)

Provide the following technical specification:

1. **Architecture Overview:**
   - Application architecture: layers (UI, business logic, credential engine, crypto layer, storage, networking)
   - Data flow diagrams: issuance flow, presentation flow, backup/restore flow, key rotation flow
   - Technology stack recommendation: framework, crypto libraries (libsodium, Web Crypto API, platform-specific), storage encryption, networking stack
   - Module decomposition: DID manager, credential store, presentation engine, protocol handler, key manager, backup service
   - Third-party dependencies: which components to build vs. use existing libraries (e.g., Sphereon SDK, Walt.id, Spruce DIDKit)

2. **Key Management Specification:**
   - Key generation: Ed25519, P-256, or secp256k1 — rationale for each based on DID method and credential format compatibility
   - Key storage: iOS Secure Enclave / Android StrongBox / Keystore integration, key access policies (biometric required for signing)
   - Key hierarchy: master key, DID keys, session keys, backup encryption keys — derivation paths
   - Key rotation: how to update DID document when keys are rotated, credential re-issuance triggers, old key archival
   - Key backup: encrypted cloud backup, social recovery (Shamir Secret Sharing with trusted contacts), paper backup (BIP39 mnemonic)
   - Key deletion: secure erasure procedures, compliance with device wipe, remote wipe capability

3. **Credential Storage Engine:**
   - Storage format: encrypted SQLite, realm, or custom encrypted file system
   - Credential indexing: searchable metadata (issuer, type, expiry, tags) without decrypting full credential
   - Attachment handling: storing evidence documents, photos, PDFs linked to credentials
   - Storage limits: maximum credentials, maximum total storage, pruning strategies for expired credentials
   - Encryption at rest: AES-256-GCM with key derived from device secure element, per-credential encryption vs. database-level encryption
   - Migration: schema versioning, data migration between app versions, export format for wallet switching

4. **Protocol Implementation:**
   - OIDC4VCI (credential issuance): authorization code flow, pre-authorized code flow, credential offer handling, token management, batch issuance
   - OIDC4VP (credential presentation): authorization request parsing, presentation definition matching, credential selection UI, response submission
   - DIDComm v2 (if required): message routing, encryption envelopes, transport (HTTP, WebSocket, Bluetooth), connection management
   - mDL ISO 18013-5 (if required): BLE engagement, NFC handover, device retrieval, session encryption
   - Error handling for each protocol: timeout, network failure, invalid request, unsupported credential format, partial match

5. **User Interface Specification:**
   - Credential card rendering: visual layout per credential type, dynamic field display, issuer branding, status indicators (valid/expired/revoked)
   - Credential detail view: all fields displayed with labels, evidence attachments, sharing options, deletion option
   - Issuance flow UI: QR scan or deep link trigger, issuer information display, consent screen, progress indicator, success/failure state
   - Presentation flow UI: verifier request display showing what is asked for, credential selection (auto-suggest best match), selective disclosure toggles, consent confirmation, transmission progress
   - Settings and management: DID list, backup status, biometric settings, connected services, credential sources
   - Accessibility requirements: VoiceOver/TalkBack support, minimum touch targets, color contrast compliance, alternative text for credential cards

6. **Security & Testing Requirements:**
   - Threat model: device theft, malicious app, MITM attack, social engineering, compromised issuer, side-channel attacks on key operations
   - Security testing: penetration testing scope, static analysis requirements, dynamic analysis, dependency vulnerability scanning
   - Certification targets: Common Criteria, FIDO certification, eIDAS LoA High, SOC 2 (if applicable)
   - Compliance testing: credential format interoperability testing (JFF Plugfest, EBSI conformance, DHS plugfest), protocol conformance suites
   - Performance benchmarks: credential issuance under 3 seconds, presentation generation under 2 seconds, app cold start under 1 second, proof generation targets for ZKP credentials