View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009154 | Taler | exchange KYC SPA | public | 2024-09-02 19:42 | 2024-10-15 19:11 |
| Reporter | Christian Grothoff | Assigned To | Florian Dold | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | assigned | Resolution | open | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 0.14 | ||||
| Summary | 0009154: generic form | ||||
| Description | We need a generic form in the KYC SPA where the AML officer can provide basically arbitrary instructions via the context. I'm thinking of something where the context can specify: * The instructions to show ("instructions":"TEXT") * The fields to show ("$KEY": { "type" : "radiobutton", "choices":{"cat","dog","elephant"}, "default":"dog"}) Initially I'd go for some of the very common HTML form fields, like "text" (line of text), "radiobutton", "checkbox" and "upload", plus maybe some super-common bank-specific types like "password" (with blind double-entry), "date", "address" (simple spec for complex form) and "country" (searchable drop-down list). Maybe "text" should have options to constrain the input ("numeric"). This will be useful for any deployment (definitively needed for TOPS) as it is the ultimate fall-back for AML staff. | ||||
| Tags | No tags attached. | ||||
| parent of | 0009252 | assigned | Florian Dold | fail to trigger second kyc, wallet core should move tx to kyc state |
| Not all the children of this issue are yet resolved or closed. | ||||
|
|
What is the estimate on how long this will still take? |
|
|
it's getting hard to test https://bugs.gnunet.org/view.php?id=9252 right now i'm trying this scenario 1.- trigger kyc 2.- officer mark as good for now 3.- wallet complete withdraw 4.- officer ask for more information 5.- wallet tries to withdraw more 6.- wallet is redirected to the custom form 7.- complete custom form 8.- officer allows or freeze account based on values I can't reach step 6 due to 0009252 in step (4) officer is using measure "ask" but unable to trigger the custom form in the kyc spa yet [kyc-measure-ask] CHECK_NAME = askContext CONTEXT = {} PROGRAM = customForm [kyc-check-askContext] TYPE = FORM VOLUNTARY = NO FORM_NAME = from_context DESCRIPTION = "Use the next form to answer what officer ask" OUTPUTS = all_info FALLBACK = gatheringProblem [aml-program-customForm] COMMAND = aml-custom-form.sh DESCRIPTION = "officer gatther info" ENABLED = YES FALLBACK = programProblem |
|
|
Sebastian: are you now unblocked? What is the ETA on this one? |
|
|
No, i'm still blocked by 0009252. I need an environment where I can run this scenario. In the AML Spa the officer is setting the custom form in the properties of the new measure. This needs to be picked up by the KYC SPA as the form that is going to be shown. For that I have a generic dynamic form which i'm not able to test (step 7). If I have an working environment where I can make all the 8 steps (but without the custom form) I think I can make this in one day of two. I should be easy but I'm still having some doubts on how the properties of the measure (set by the officer who wants to ask for more information) is going to communicate the form to the KYC spa. This is more testing intensive. |
|
|
Why can't you do this much simpler scenario: 1.- trigger kyc (say wallet-balance too high, or withdraw limit, or whatever) 2.- officer ask for more information 3.- wallet is redirected to the custom form 4.- complete custom form 5.- officer allows or freeze account based on values |
|
|
AFAIK the officer don't see the account in the AML spa in step (2) but I will try to simplify this |
|
|
update: I can make this by using the "search account" feature after step (1)... that is making a decision for an account that the exchange doesn't yet knows. It is useful as a workaround. |
|
|
1.- can't read the context in AML programs https://bugs.gnunet.org/view.php?id=9254 while that's being fixed (i can workaround it by creating a static form instead a officer defined one) i'm blocked by this 2.- context if static based on the measure configuration after update docs.git :: f1fa1193..9ab882ea the `kyc-info` can returns the `context` value but there is no way to update it from the AML Program so: - aml officer can set the form configuration in `properties: AccountProperties` part of `aml/$OFFICER_PUB/decision` - aml program can read context and properties part of AmlProgramInput - KYC SPA customer can read `context?: Object` part of `kyc-info/$ACCESS_TOKEN` but there is no way for the aml program to use the input to build the form that the KYC SPA will use. maybe we can have a new_context in AmlOutcome and if it's not undefined then replace it all |
|
|
Use custom measures, define context as part of the measure. |
|
|
Measure with CHECK_NAME = SKIP fail, I made a integration test 1. creates withdrawal which triggers measure m1 2. check kyc-info endpoint (ok) 3. officer makes decision with measure m3 (which have check = skip) 4. check kyc-info endpoint and fail (http status 500) expected `kyc-info` to return the result of the program associated with measure m3 can be reproduce with # taler-harness run-integrationtests kyc-skip-expiration |
|
|
I think that the problems is that when a officer post a decision with a Measure that contains a CHECK_NAME = SKIP I expect the program to run instantly and as far as i'm reading the code legitimization_check_run is only called when an KYC event is triggered so it's also need to be called when the officer makes a decision (to handle the case when the measure being posted is an instant measure) |
|
|
Yes, it *should* run instantly, likely something the code simply doesn't check for yet on AML decisions. |
|
|
@florian: it would be great if you could look into this one... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-09-02 19:42 | Christian Grothoff | New Issue | |
| 2024-09-02 19:42 | Christian Grothoff | Status | new => assigned |
| 2024-09-02 19:42 | Christian Grothoff | Assigned To | => sebasjm |
| 2024-10-06 23:58 | Christian Grothoff | Note Added: 0023458 | |
| 2024-10-07 05:47 | sebasjm | Note Added: 0023460 | |
| 2024-10-07 10:41 | Christian Grothoff | Relationship added | parent of 0009252 |
| 2024-10-08 00:03 | Christian Grothoff | Note Added: 0023477 | |
| 2024-10-08 13:59 | sebasjm | Note Added: 0023478 | |
| 2024-10-08 16:53 | Christian Grothoff | Note Added: 0023479 | |
| 2024-10-08 18:02 | sebasjm | Note Added: 0023480 | |
| 2024-10-08 18:51 | sebasjm | Note Added: 0023482 | |
| 2024-10-10 17:17 | sebasjm | Note Added: 0023504 | |
| 2024-10-10 17:22 | sebasjm | Note Edited: 0023504 | |
| 2024-10-10 17:22 | sebasjm | Note Edited: 0023504 | |
| 2024-10-10 17:23 | sebasjm | Note Edited: 0023504 | |
| 2024-10-10 17:23 | sebasjm | Note Edited: 0023504 | |
| 2024-10-10 17:23 | sebasjm | Note Edited: 0023504 | |
| 2024-10-11 22:28 | Christian Grothoff | Note Added: 0023523 | |
| 2024-10-15 03:40 | sebasjm | Note Added: 0023528 | |
| 2024-10-15 03:40 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
| 2024-10-15 16:52 | sebasjm | Note Added: 0023529 | |
| 2024-10-15 19:10 | Christian Grothoff | Note Added: 0023532 | |
| 2024-10-15 19:10 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-10-15 19:11 | Christian Grothoff | Note Added: 0023533 |
