View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007929 | Taler | specification | public | 2023-08-28 13:47 | 2023-09-23 13:09 |
| Reporter | sebasjm | Assigned To | sebasjm | 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 | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.9.3 | Fixed in Version | 0.9.3 | ||
| Summary | 0007929: extract totp from template | ||||
| Description | details below [1] add TOTP management endpoints [2] add "require_offline_validation" in order creation [3] remove totp configuration from template, and allow more than one template to use the same device after this, merchant backoffice will have * a section for device management * devices will be selected from drop down instance of copy/paste keys [1] add totp device POST [/instances/$INSTANCE]/private/totp interface TotpDeviceAddDetails { // Device ID to use. device_id: string; // Human-readable description for the device. device_description: string; // A base64-encoded key pos_key: string; // Algorithm for computing the POS confirmation. pos_algorithm: "simple" | "include-price" } PATCH [/instances/$INSTANCE]/private/totp/$DEVICE_ID interface TotpDeviceAddDetails { // Human-readable description for the device. device_description: string; // A base64-encoded key pos_key: string; // Algorithm for computing the POS confirmation. pos_algorithm: "simple" | "include-price" } GET [/instances/$INSTANCE]/private/totp interface DeviceSummaryResponse { // List of devices that are present in our backend. devices_list: DeviceEntry[]; } interface DeviceEntry { // Device identifier. device_id: string; // Human-readable description for the device. device_description: string; } GET [/instances/$INSTANCE]/private/totp/$DEVICE_ID interface DeviceDetails { // Human-readable description for the device. device_description: string; // A base64-encoded key of the point-of-sale. pos_key: string; // Algorithm for computing the POS confirmation. pos_algorithm: "simple" | "include-price" } DELETE [/instances/$INSTANCE]/private/totp/$DEVICE_ID [2] POST [/instances/$INSTANCE]/private/orders interface PostOrderRequest { .... // optional // value must be a valid totp validator // backend will create text to be shown to the point-of-sale staff as a proof of // payment for this order require_offline_validation?: string; } [3] POST [/instances/$INSTANCE]/private/templates interface TemplateAddDetails { // Template ID to use. template_id: string; // Human-readable description for the template. template_description: string; // totp device id // This parameter is optional. device_key?: string; // Additional information in a separate template. template_contract: TemplateContractDetails; } | ||||
| Tags | No tags attached. | ||||
| Ok, I now thought of an actually good reason to do this, which is if we support counter-based OTP, we really need this in a separate table (for the counter) if multiple templates are to share the same OTP generator. | |
| Implemented in backend, assigning to sebastian for SPA work. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-08-28 13:47 | sebasjm | New Issue | |
| 2023-08-28 13:47 | sebasjm | Status | new => assigned |
| 2023-08-28 13:47 | sebasjm | Assigned To | => Christian Grothoff |
| 2023-08-29 10:43 | Christian Grothoff | Note Added: 0020451 | |
| 2023-08-29 10:49 | Christian Grothoff | Target Version | post-1.0 => 0.9.4 |
| 2023-09-01 12:29 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2023-09-01 12:29 | Christian Grothoff | Note Added: 0020465 | |
| 2023-09-01 12:29 | Christian Grothoff | Target Version | 0.9.4 => 0.9.3 |
| 2023-09-11 19:19 | sebasjm | Status | assigned => informing |
| 2023-09-11 19:19 | sebasjm | Resolution | open => fixed |
| 2023-09-23 13:07 | Christian Grothoff | Fixed in Version | => 0.9.3 |
| 2023-09-23 13:09 | Christian Grothoff | Status | informing => closed |
| 2024-01-12 13:02 | Christian Grothoff | Category | merchant backend API (HTTP specification) => specification |