View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004379 | Taler | wallet-core | public | 2016-04-06 21:34 | 2024-08-12 08:00 |
| Reporter | Florian Dold | Assigned To | 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 | have not tried |
| Status | implementing | Resolution | open | ||
| Target Version | post-2.0 | ||||
| Summary | 0004379: error handling: exportable proof of e.g. double spending for auditor | ||||
| Description | When payments fail and it is not a transient error, the wallet needs to provide the user with a way to extract the information regarding the claim the merchant made. | ||||
| Tags | No tags attached. | ||||
| Not clear how this should look UI-wise, and I'm also not sure what's the best way to test this. For the UI: We could open an in-extension tab that shows a message and a way to save the proof. Should it show up anywhere in the wallet popup, or just in the history? Does this error page provide the user with the option to refresh coins that are not double-spended? Does this happen automatically (probably makes most sense)? Should we have some informal spec that documents these cases before we start implementing? | |
| Moved to 0.3 since we should have at least the facilities to trigger the various error paths (wallet really double-spended / merchant falsely claimed double spending). | |
| Eh, that would be 0.5. That's when the error path triggering is on the roadmap. | |
| Wrong again. 0.6. | |
| In terms of specification, I basically expect that for each possible proof we export a JSON file with: * always top-level: some numeric information about the type of proof * always top-level: some human-readable information about the type of proof Then, type-specific key-value pairs where: key: some string describing the value value: some json object (or array) with structured proof data, i.e. public keys, amounts, signatures, hashes, etc., depending on what the proof is about. We should also have some command-line tool to verify proofs, i.e. I would run: taler-check-proof FILENAME.json and it would: 1) open file, parse the json (make sure JSON was valid) 2) look at the type, use it to load some plugin to verify the proof and 3) output the result of the check ("valid" / "invalid") We need to have an additional options "--extract-contract" that could be used to extract the JSON contract from the overall proof (if present), so that one can use the (generic) contract renderer (which we need to have a standalone-version of) to show the contract. I think that's about it for the overall design, the individual JSON field members for each proof should probably just be speced as the export-logic and proof-validation plugin are implemented. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-04-06 21:34 | Florian Dold | New Issue | |
| 2016-04-06 21:34 | Florian Dold | Status | new => assigned |
| 2016-04-06 21:34 | Florian Dold | Assigned To | => Florian Dold |
| 2016-04-06 22:56 | Christian Grothoff | Product Version | => 0.0 |
| 2016-04-06 22:56 | Christian Grothoff | Target Version | => 0.1 |
| 2016-04-07 13:00 | Florian Dold | Relationship added | child of 0003800 |
| 2016-04-07 22:06 | Christian Grothoff | Severity | minor => feature |
| 2016-04-07 22:11 | Christian Grothoff | Target Version | 0.1 => 0.2 |
| 2016-11-03 19:21 | Florian Dold | Note Added: 0011423 | |
| 2016-11-03 20:51 | Florian Dold | Status | assigned => feedback |
| 2016-11-08 14:01 | Florian Dold | Note Added: 0011451 | |
| 2016-11-08 14:01 | Florian Dold | Target Version | 0.2 => 0.3 |
| 2016-11-08 15:11 | Christian Grothoff | Target Version | 0.3 => 0.5 |
| 2016-11-08 15:11 | Christian Grothoff | Note Added: 0011452 | |
| 2016-11-08 15:11 | Christian Grothoff | Target Version | 0.5 => 0.6 |
| 2016-11-08 15:11 | Christian Grothoff | Note Added: 0011453 | |
| 2016-11-08 15:12 | Christian Grothoff | Relationship added | parent of 0004454 |
| 2017-03-18 23:06 | Christian Grothoff | Note Added: 0011945 | |
| 2017-03-18 23:06 | Christian Grothoff | Status | feedback => assigned |
| 2017-03-20 10:42 | Christian Grothoff | Target Version | 0.6 => 0.9 |
| 2017-10-23 08:48 | Christian Grothoff | Relationship deleted | child of 0003800 |
| 2018-03-27 15:31 | Christian Grothoff | Relationship deleted | parent of 0004454 |
| 2021-06-22 13:35 | Florian Dold | Category | wallet (WebExtensions) => wallet (TS core) |
| 2022-10-20 09:17 | Christian Grothoff | Assigned To | Florian Dold => |
| 2022-10-20 09:17 | Christian Grothoff | Status | assigned => implementing |
| 2022-10-20 09:17 | Christian Grothoff | Target Version | 0.9 => |
| 2023-04-05 16:36 | Florian Dold | Product Version | 0.0 => 0.11 |
| 2023-04-13 18:36 | Florian Dold | Category | wallet (TS core) => wallet-core |
| 2023-04-13 18:53 | Florian Dold | Product Version | 0.11 => |
| 2023-04-13 18:53 | Florian Dold | Target Version | => post-1.0 |
| 2023-04-23 18:21 | Florian Dold | Summary | error handling: exportable proof for e.g. double spending => error handling: exportable proof of e.g. double spending for auditor |
| 2024-08-12 08:00 | Christian Grothoff | Target Version | post-1.0 => post-2.0 |