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