# Wallet Security Standardization Roadmap

Two problems to solve:
- device binding
- wallet authentication

Motivation:
- successful but propietary solution in german BKAmt pilot
- efforts in Germany & Canada
- standardization neccessary for interoperable and scalable solution

## Status Quo

- using upfront REST API calls before sending the DIDComm invitation
- Certificate Pinning


## Device Binding

Prior thoughts on device binding : https://docs.google.com/document/d/1iJAB7VRe1P4wEaBOAb-g8Fn4JvyMXpkpEMkK06U1Qh4/edit#heading=h.y4fziuuyzbcj

### Issuance Option #1:

- Issuance Option 1a: define new DIDCommProtocol
- send invitation and establish DIDComm conncetion first, process device binding, process credential issuance
- binding between Device Binding and issue credential protocol?
- proposal 1a: https://hackmd.io/@pwlb/Sk2jrJZlc
- Issuance Option 1b: extend existing with decorators/attachments
- more compact, less messages
- missing first communication form issuer to holder?
- multiple issue_v* processes
- Sebastian Bickerle will evaluate possiblities for Option 1b
- proposal 1b: https://hackmd.io/@sbickerle/rka12zWe5

- how to bootstrap process?
- DIDComm [discover 2.0 feature](https://github.com/hyperledger/aries-rfcs/tree/main/features/0557-discover-features-v2) ?
- get WalletSecurityCapabilities? device binding and wallet authentication
- writeup Aries RFC

### Verification process must also be considered

#### todo: where to integrate proof?

Options:
1. self-attested attribute (status quo)
2. decorator for present proof V* (2b)
3. separate protocol (2a)

## Wallet Authentication

- Motivation:
- user authentication performed locally on device, key mangement on device
- there this requires trust into the correct implementation of the wallet
- eIDAS also requires user authentication
- usable mechanisms: Android SafetyNet, iOS Device Check, Key Attestation etc..

### Design questions
- Question 1 : Who shall request wallet authentication? (Issuer) vs (Issuer and Verifier)
- Question 2: How fresh must this information be?
- Question 3: How is this information transmitted?
- Question 4: Is Device Binding coupled to Wallet Authentication or is it separatly usable?

Best practice:
- one hardware key per credential(where necessary) instead of one global key -> ensure best privacy possible
- repsect data privacy as best as possible, try to avoid trackable information
- ues ZKP for checks where possible

### Option #1:

- Wallet Authentifaction directly to the issuer
- Advantage:
- Issuer directly validates the wallet
- high security
- "fresh" proof
- Disadvantage:
- mechanisms are initially intended for app backend, nonce provided by "third party"
- might run into scalibility issues when many parties using this (ecpecially verifiers)
- requires separate DIDComm Protocol?

- regard hybrid solutions Cloud/edge

### Option #2a:

- Wallet Authentication is proofed towards a service, e.g. Wallet Issuer, that encodes the information in a VC
- Advantage:
- easily usable for Issuer and Verfier
- interoperable solution using existing mechanisms
- scalable
- Disadvantage:
- proof is "not fresh"
- trust is indirect - although we have to trust the wallet implementer anyhow
- additional work for the wallet implementer

challenges: Device Binding and/or prevent VC to be transferable (Backup/recovery)?

question: timeframe for renewal?

### Option 2b:

- Wallet contacts Wallet issuer upfront
- they perform Wallet Authentication with SafetyNet/DeviceCheck etc..
- secure hardware key is generated
- wallet authentication and hardware public key isnchored in VC
- Advantage:
- one Wallet Auth VC per hardware key
- "fresh" proof during key generation
- Disadvantage:
- one Wallet Auth VC per hardware key
- key format/signature/security mechanism is determined upfront
- additional work for the wallet implementer

giving this VC to the Verifier?

### offtopic:
- Wallet implementer should go through a certification/pen testing(both variants)
- binding to Google Android, iOS Services
- Android Derivatives?
- What about chinese phones?