View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007278 | Taler | exchange | public | 2022-07-05 17:14 | 2025-05-10 02:13 |
| Reporter | oec | Assigned To | oec | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Target Version | 1.0 | Fixed in Version | 1.0 | ||
| Summary | 0007278: Common handling of age restriction verification for withdraw and reward needed | ||||
| Description | Both protocols, withdraw and tipping, will need support for age restriction. In particular, a customer might be required to proof to be in a specific age group: For example, if children can have bank accounts and the exchange can identify those accounts during a transfer to a reserve, it can - and should - ask for a proof of the _maximum_ age of the holder of the corresponding wallet that performs the withdraw. Similarly, a merchant might ask for a minimum age during a tipping protocol. This might be done by an additional age proof provided by the wallet to the exchange, or (maybe) communicated by the merchant to the exchange when setting up the reserve for the tipping and then the minimum age requirement is verified by the exchange. | ||||
| Tags | No tags attached. | ||||
| To address the first point: With commit d20804124025c259af1bc3e00ceed653c734b468 and previous, there is now an endpoint for age-withdraw, see https://docs.taler.net/core/api-exchange.html#withdraw-with-age-restriction | |
| The /age-withdraw endpoint now exists since commit 571d43cef3732ed6f491d91a9e767a80008edeb1, handling withdraws from reserves with a birthday set. If the birthday is not far away in the past, the wallet has to proof that it has set appropriate age restrictions on the coins, using a cut&choose protocol. To fix this issue 7278, I suggest to either a) implement DD 45, so that a merchant can attest another reserve with a given one, and set an appropriate and lower birthday (and therefore age) on the target reserve that way and/or b) extend /reserves/$RESERVE_PUB/open so that the merchant can provide a maximum_age_group parameter to the particular reserve. The wallet then has to perform the /age-withdraw operation. Note that setting a birthday and setting a max_age_group have slightly different semantics: If the reserve has a birthday set, the maximum_age_group associated will grow over time. | |
| We removed rewards, and I think endpoints were quite unified. @oec: what is left here? | |
| As Christian correctly pointed out, rewards/tipping is removed, and withdraw already supports proof-of-age if required by the birthday set on a reserve. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-07-05 17:14 | oec | New Issue | |
| 2022-07-05 17:14 | oec | Status | new => assigned |
| 2022-07-05 17:14 | oec | Assigned To | => oec |
| 2023-04-04 14:19 | Florian Dold | Target Version | => post-1.0 |
| 2023-12-23 22:43 | oec | Note Added: 0020803 | |
| 2024-01-12 13:10 | oec | Relationship added | child of 0008073 |
| 2024-02-02 14:27 | oec | Summary | Common handling of age restriction verification for withdraw and tipping needed => Common handling of age restriction verification for withdraw and reward needed |
| 2024-02-02 14:27 | oec | Note Added: 0021126 | |
| 2025-05-08 20:56 | Christian Grothoff | Note Added: 0024855 | |
| 2025-05-09 05:30 | oec | Status | assigned => informing |
| 2025-05-09 05:30 | oec | Resolution | open => fixed |
| 2025-05-09 05:30 | oec | Note Added: 0024859 | |
| 2025-05-10 02:12 | Christian Grothoff | Fixed in Version | => 1.0 |
| 2025-05-10 02:13 | Christian Grothoff | Target Version | post-1.0 => 1.0 |
| 2025-05-10 02:13 | Christian Grothoff | Status | informing => closed |