View Issue Details

IDProjectCategoryView StatusLast Update
0007656Talerexchangepublic2024-01-12 14:05
Reportersebasjm Assigned Tosebasjm  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.9.2Fixed in Version0.9.2 
Summary0007656: exchange cant find logic when there business and individual defined
DescriptionIf a comment out every kyc-legitimization-bus* it works again.

[kyc-provider-sauron02]
COST = 1
LOGIC = oauth2
USER_TYPE = BUSINESS
PROVIDED_CHECKS = sauron_business_withdraw
<the rest of the oauth2 config for this provider>

[kyc-provider-sauron07]
COST = 1
LOGIC = oauth2
USER_TYPE = INDIVIDUAL
PROVIDED_CHECKS = sauron_individual_withdraw
<the rest of the oauth2 config for this provider>

[kyc-legitimization-ind_withdraw]
OPERATION_TYPE = WITHDRAW
REQUIRED_CHECKS = sauron_individual_withdraw
THRESHOLD = ARS:10
TIMEFRAME = 1h

[kyc-legitimization-bus_withdraw]
OPERATION_TYPE = WITHDRAW
REQUIRED_CHECKS = sauron_business_withdraw
THRESHOLD = ARS:10
TIMEFRAME = 1h

<more legitimization and providers and stuff>


curl 'https://exchange-kyc.taler.ar/kyc-check/1/NQXJ7FYSZ1FY021Y8JPRSM6QTG2JAW8ZKB1MHCKHJM1ZP8VZS1YG/individual'
{
  "code": 1932,
  "hint": "The request requires a logic which is no longer configured at the exchange.",
  "detail": "sauron_individual_withdraw sauron_business_withdraw"
}

Something I notice here: https://git.taler.net/exchange.git/tree/src/kyclogic/kyclogic_api.c?id=d7382879539fef81a6870b7535f0ebeb08fb2a2f#n1000

It does not check for the user_type
TagsNo tags attached.

Activities

Christian Grothoff

2023-01-31 20:25

manager   ~0019725

Eh, please see src/kyclogic/kyclogic_api.c it clearly looks for USER_TYPE there.
Also, there is the 'ut' argument for TALER_EXCHANGE_kyc_check().
Finally, note the:

  ekr->kyc = TALER_EXCHANGE_kyc_check (
    eh,
    ekr->exchange_kyc_serial,
    &h_payto,
    /* FIXME: get from settings! */
    TALER_KYCLOGIC_KYC_UT_BUSINESS,
    kc->timeout,
    &exchange_check_cb,
    ekr);
in taler-merchant-httpd_private-get-instances-ID-kyc.c -- hard-coded to BUSINESS right now. So yes, it's an open issue to get this from the settings ...

sebasjm

2023-02-02 16:54

developer   ~0019735

The error changed in this new version

taler-exchange-httpd v0.9.1-git-d7382879

curl https://exchange-kyc.taler.ar/kyc-check/17/4N50F3HKQGH03YRD8P3V974KM5V2ES87BVNB36G9911Q5CGEF360/individual
{
  "code": 1932,
  "hint": "The request requires a logic which is no longer configured at the exchange.",
  "detail": "sauron_business_withdraw"
}

querying for individual, tries to find business

sebasjm

2023-02-02 17:18

developer   ~0019736

This is what the database has in the table legitimization_requirements

"legitimization_requirement_serial_id" "h_payto" "required_checks"
1 "binary data" "sauron_individual_withdraw sauron_business_withdraw"
17 "binary data" "sauron_business_withdraw"

Looks like both requirements are getting triggered but after completing kyc process just one of them are marked as solved

Christian Grothoff

2023-02-02 17:22

manager   ~0019737

In particular configurations, it is possible that a user may need to finish multiple KYC processes (idea: collecting different data!) before the action is unlocked. Could this be the case here? If you ask, are you now redirected to the 2nd KYC challenge?

sebasjm

2023-02-02 18:18

developer   ~0019738

The http request that I pasted above has a return status code of 500

< HTTP/1.1 500 Internal Server Error
< Server: nginx/1.18.0 (Ubuntu)
< Date: Thu, 02 Feb 2023 17:09:56 GMT
< Content-Type: application/json
< Content-Length: 147
< Connection: keep-alive
< Access-Control-Allow-Origin: *
< Access-Control-Expose-Headers: *
<
{
  "code": 1932,
  "hint": "The request requires a logic which is no longer configured at the exchange.",
  "detail": "sauron_business_withdraw"
}

If query to the same kyc-check URL with business instead of individual the exchange give me the kyc url to complete the step.
Like this

curl https://exchange-kyc.taler.ar/kyc-check/17/4N50F3HKQGH03YRD8P3V974KM5V2ES87BVNB36G9911Q5CGEF360/business

But I expected this kyc just to
a) require kyc check for individual (not business)
b) mark as completed both requirements when doing the first one

I think a) is better but the exchange need to know in advance if the payto is business or individual, right?

That what I was mentioning in my first comment, this function here
> https://git.taler.net/exchange.git/tree/src/kyclogic/kyclogic_api.c?id=d7382879539fef81a6870b7535f0ebeb08fb2a2f#n1000

"TALER_KYCLOGIC_kyc_test_required" add all requirement without checking the user_type of the payto.

Maybe all payto can be treated as individual by default (when doing kyc_test_required) with a "upgrade" procedure to mark the account as "business" (with higher threshold)

sebasjm

2023-02-02 19:18

developer   ~0019739

or c) returns another 4xx code implying that kyc for this user_type is OK but the user should check another user_type.

That will be enough information for the wallet to know it will be not able to withdraw before doing another kyc step.

Christian Grothoff

2023-02-03 10:48

manager   ~0019740

Oh, I think I see now what is going wrong. You're misunderstanding completely how you are supposed to configure the KYC checks. Let me rewrite your config for you:


[kyc-provider-sauron02]
COST = 1
LOGIC = oauth2
USER_TYPE = BUSINESS
PROVIDED_CHECKS = fullname address phone

[kyc-provider-sauron07]
COST = 1
LOGIC = oauth2
USER_TYPE = INDIVIDUAL
PROVIDED_CHECKS = fullname address

[kyc-provider-sauron42]
COST = 1
LOGIC = oauth2
USER_TYPE = INDIVIDUAL
PROVIDED_CHECKS = phone

[kyc-legitimization-ind_withdraw]
OPERATION_TYPE = WITHDRAW
REQUIRED_CHECKS = fullname
THRESHOLD = ARS:10
TIMEFRAME = 1h

[kyc-legitimization-bus_withdraw]
OPERATION_TYPE = WITHDRAW
REQUIRED_CHECKS = address phone
THRESHOLD = ARS:100
TIMEFRAME = 1h


Is that better? :-)

sebasjm

2023-02-03 14:16

developer   ~0019742

ACK, this worked.

So the 500 problem can be solved by adding a start up verification checking gathering all the required_check (in your config address, phone and fullname) and then check that for every one of them exists a kyc-provider that can be used.

Am I getting this right?

Christian Grothoff

2023-02-03 14:23

manager   ~0019743

Well, you are right to say that in this case is the 500 is pointing to a *configuration error*. However, it cannot be solved as easily as you say by a start-up check, as we do want to ALLOW some checks to not be defined! That's an open feature for me, which is "hard thresholds": by setting a rule that cannot be satisfied, we can categorically prohibit certain amounts! Plus, even without that it's not this easy, as we may prohibit for individuals but not for businesses.

So in the end, yes, we MAY want to change this from a 500 to a special type of 451 unsatisfiable. But as I said, this part is still work-in-progress ;-).

sebasjm

2023-02-03 14:43

developer   ~0019744

good enough for me

Issue History

Date Modified Username Field Change
2023-01-31 19:29 sebasjm New Issue
2023-01-31 19:29 sebasjm Status new => assigned
2023-01-31 19:29 sebasjm Assigned To => Christian Grothoff
2023-01-31 20:25 Christian Grothoff Note Added: 0019725
2023-02-01 13:15 Christian Grothoff Assigned To Christian Grothoff => sebasjm
2023-02-01 13:15 Christian Grothoff Status assigned => feedback
2023-02-02 16:54 sebasjm Note Added: 0019735
2023-02-02 17:18 sebasjm Note Added: 0019736
2023-02-02 17:22 Christian Grothoff Note Added: 0019737
2023-02-02 18:18 sebasjm Note Added: 0019738
2023-02-02 18:19 sebasjm Assigned To sebasjm => Christian Grothoff
2023-02-02 19:18 sebasjm Note Added: 0019739
2023-02-02 19:18 sebasjm Status feedback => assigned
2023-02-03 10:48 Christian Grothoff Note Added: 0019740
2023-02-03 10:49 Christian Grothoff Assigned To Christian Grothoff => sebasjm
2023-02-03 10:49 Christian Grothoff Status assigned => feedback
2023-02-03 14:16 sebasjm Note Added: 0019742
2023-02-03 14:23 Christian Grothoff Note Added: 0019743
2023-02-03 14:43 sebasjm Status feedback => resolved
2023-02-03 14:43 sebasjm Resolution open => fixed
2023-02-03 14:43 sebasjm Note Added: 0019744
2023-02-21 16:39 Christian Grothoff Fixed in Version => 0.9.2
2023-02-21 16:39 Christian Grothoff Status resolved => closed
2024-01-12 14:05 Christian Grothoff Category exchange API (C) => exchange