9 Implementation Guidance

9.1 Wallet Implementation Requirements

9.1.1 Secret Key Management

• Store private keys in secure enclave (iOS/Android hardware)

• Never export unencrypted private keys

• Implement key derivation from user-memorizable seeds (BIP39 compatible)

9.1.2 DID Lifecycle

Identity DIDs

• Generated once per credential lifetime (typically 1-10 years)

• Persisted across wallet updates and device changes

• Associated with formal credentials (passport, license, etc.)

Communication DIDs

• Generated per service engagement or per session (configurable)

• Destroyed if VC not issued (one-time verification)

• Persisted if VC issued (login reuse case)

• Linked to counterparty DID in wallet for session continuation

9.1.3 VC Storage

• Store issued VCs with deLinkageInfo

• Enable offline VC verification

• Implement selective disclosure (claim subset presentation)

• Track VC issuance context (service, timestamp, nonce)

9.2 Service Provider Integration

9.2.1 DIDComm Endpoint Setup

1. Publish service endpoint URL (HTTPS with valid TLS)

2. Accept POST requests with DIDComm messages

3. Parse and cryptographically verify ZKP

4. Execute service logic based on verified claims

5. Return VC (if registration service) or result (if verification-only)

9.2.2 Authorization Decision Points

Services must decide:

• Which claims are required for service access

• Which DIDs are trusted for VC validation

• How to handle multiple DIDs from same user (user linking policy)

• Whether to issue persistent VC or one-time verification

9.2.3 Nonce Management (Optional Service Feature)

If replay prevention beyond DIDComm is required:

1. Generate unique nonce per session

2. Send nonce to wallet

3. Verify returned ZKP includes nonce in cryptographic binding

4. Record used nonces to prevent reuse

5. Clean up nonce history based on session TTL

Note: Nonce management is optional at service layer, not protocol-required.

9.3 Deployment Scenarios

9.3.1 One-Time Verification (Age Confirmation)

• Holder generates ephemeral communication DID

• Generates ZKP proving age \(\geq \) 18

• Verifier validates ZKP, permits or denies access

• Communication DID destroyed (no VC issued)

• No persistent state

9.3.2 Service Registration (Account Opening)

• Holder generates communication DID (persistent)

• Generates ZKP proving identity claims

• Issuer validates, creates account

• Issuer generates VC (e.g., account holder credential)

• Holder stores VC and communication DID-to-service association

• Later: Login reuses same communication DID

9.3.3 Continuous Authentication (SNS, Messaging)

• Holder generates ephemeral communication DID per login

• Generates ZKP proving phone number ownership

• Service validates, establishes session

• Session token replaces ZKP for subsequent requests

• Communication DID may be stored for optional reconnection hint