030-offline-payments.rst (3470B)
1 DD 30: Offline payments 2 ####################### 3 4 Summary 5 ======= 6 7 This design document discusses support for offline payments. 8 9 Motivation 10 ========== 11 12 Many proposed CBDCs claim to support offline payments. 13 Taler is explicitly meant to be an online payment system. However, since there 14 recently seems to be an increased interest in offline CBDC solutions, 15 we have decided to still explore how Taler could support offline payments in the future. 16 17 While we still recommend online-only payments, this work operates under the the 18 following theme: "If Taler can support offline payments that are no worse than 19 those of competing systems (that often offer less freedom and privacy to 20 users), why should we claim we can't support them and fare worse in comparisons"? 21 22 Requirements 23 ============ 24 25 TBD. 26 27 Possible Solutions 28 ================== 29 30 Approach 1: Trust-based offline payments 31 ---------------------------------------- 32 33 The merchant simply trusts payments without depositing them at the exchange, up 34 to a certain threshold and when an emergency mode is activated. 35 36 Advantages: 37 38 - Offers the most user freedom 39 - Very few protocol/implementation changes required 40 41 Disadvantages: 42 43 - Requires manual switching to "emergency mode" where merchant 44 just trusts payments without verification. 45 - Linkability of transactions unavoidable, because refresh is not available offline 46 - Unclear if/how business logic based on order state will be affected. 47 (Will there be a "paid-offline" / "paid-unconfirmed" state for orders?) 48 49 Approach 2: Full HSM wallet 50 --------------------------- 51 52 Implement the full wallet in a hardware security module. When paying, the HSM 53 wallet attests itself to the merchant, who then (if configured appropriately) 54 trusts that the coins are still valid without talking to the exchange first. 55 56 Advantages: 57 58 - Easy to lift coins out of the HSM into a software wallet. 59 The HSM would internally mark the coins as "online" and give 60 the coin secrets to the software wallet. 61 - Few exchange/merchant protocol changes required. 62 63 Disadvantages: 64 65 - Complex implementation, might not be supported on commodity HSMs. 66 - Requires medium-to-major merchant backend changes (to verify HSM sigs and 67 deposit coins once offline) 68 - Difficult to support P2P payments 69 - Depending on available coins, linkable transactions 70 might be unavoidable. 71 - Since the HSM wallet supports the full protocol, regulators might 72 be encouraged to make the HSM a requirement for *all* payments. 73 - The usual (justified!) HSM security and freedom concerns 74 75 Approach 3: Light-weight HSM balance register 76 --------------------------------------------- 77 78 The HSM maintains an offline balance, effectively as a single, HSM protected 79 register. To obtain offline cash, the software wallet spends coins to get a 80 signature that can be passed to the HSM to increment the offline balance. 81 To spend, the software wallet requests an "offline deposit permission" 82 that decrements the HSM balance register. The exchange accepts these offline 83 deposit permissions in lieu of a normal coin deposit permission. 84 85 Advantages: 86 87 - Trivially supports P2P payments 88 - Cleanly separates normal Taler functionality from offline functionality 89 90 Disadvantages: 91 92 - Requires non-trivial (but backwards compatible) protocol changes 93 - The usual (justified!) HSM security and freedom concerns 94 95 96 Discussion / Q&A 97 ================ 98 99 (This should be filled in with results from discussions on mailing lists / personal communication.)