taler-docs

commit c60c8d0a6009894fdd5fc913cd3321bc419e3e63
parent dbee25597e8c08d792b8a22267d75e16a4eadf4c
Author: Christian Grothoff <christian@grothoff.org>
Date:   Tue, 14 May 2024 10:20:45 +0200

use provider name, not configuration section

Diffstat:
M
core/api-exchange.rst
 | 
31
+++++++++++++++++--------------

1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/core/api-exchange.rst b/core/api-exchange.rst
@@ -1453,7 +1453,7 @@ and freeze or unfreeze accounts suspected of money laundering.
     stop looking (exclusive). If not given, the current date is used.
 
   **Response:**
-  
+
   :http:statuscode:`200 OK`:
     The responds will be an `EventCounter` message.
 
@@ -1479,7 +1479,7 @@ and freeze or unfreeze accounts suspected of money laundering.
     request are not protected by the signature.
 
     This endpoint was introduced in this form in protocol **v20**.
- 
+
   :query limit:
     *Optional*. takes value of the form ``N (-N)``, so that at
     most ``N`` values strictly older (younger) than ``start`` are returned.
@@ -1535,6 +1535,9 @@ and freeze or unfreeze accounts suspected of money laundering.
       // Row ID of the record.  Used to filter by offset.
       rowid: Integer;
 
+      // Justification for the decision.
+      justification: string;
+
       // When was the decision made?
       decision_time: Timestamp;
 
@@ -1615,7 +1618,7 @@ and freeze or unfreeze accounts suspected of money laundering.
       // Custom measures that KYC rules and the
       // ``successor_measure`` may refer to.
       custom_measures: { "$measure_name" : MeasureInformation; };
-      
+
     }
 
   .. ts:def:: KycRule
@@ -1664,7 +1667,7 @@ and freeze or unfreeze accounts suspected of money laundering.
       // measure what to do next.
       // Default (if missing) is false.
       is_and_combinator?: boolean;
-      
+
     }
 
 .. http:get:: /aml/$OFFICER_PUB/attributes/$H_PAYTO
@@ -1673,7 +1676,7 @@ and freeze or unfreeze accounts suspected of money laundering.
   given account.
 
   This endpoint was introduced in protocol **v20**.
-  
+
   **Request:**
 
   *Taler-AML-Officer-Signature*:
@@ -1720,10 +1723,10 @@ and freeze or unfreeze accounts suspected of money laundering.
       // Row ID of the record.  Used to filter by offset.
       rowid: Integer;
 
-      // Name of the configuration section that specifies the provider
+      // Name of the provider
       // which was used to collect the attributes. NULL if they were
       // just uploaded via a form by the account owner.
-      provider_section?: string;
+      provider_name?: string;
 
       // The collected KYC data.  NULL if the attribute data could not
       // be decrypted (internal error of the exchange, likely the
@@ -5450,7 +5453,7 @@ regulatory compliance.
   measure (but this should be irrelevant for the client).
 
   This endpoint was introduced in protocol **v20**.
-  
+
   **Request:**
 
   Basically oriented along the possible formats of a HTTP form being
@@ -5506,11 +5509,11 @@ regulatory compliance.
     is also the place where we could integrate the payment process for the KYC fee
     in the future (since **vATTEST**).
 
-.. http:get:: /kyc-proof/$PROVIDER_SECTION?state=$H_PAYTO
+.. http:get:: /kyc-proof/$PROVIDER_NAME?state=$H_PAYTO
 
   Upon completion of the process at the external KYC provider, the provider
   must redirect the client (browser) to trigger a GET request to a new
-  ``/kyc-proof/$H_PAYTO/$PROVIDER_SECTION`` endpoint.  Once this endpoint is
+  ``/kyc-proof/$H_PAYTO/$PROVIDER_NAME`` endpoint.  Once this endpoint is
   triggered, the exchange will pass the received arguments to the respective
   logic plugin.  The logic plugin will then (asynchronously) update the KYC
   status of the user.  The logic plugin should redirect the user to the KYC
@@ -5523,7 +5526,7 @@ regulatory compliance.
   Specifically, the URL arguments should provide
   information to the exchange that allows it to verify that the
   user has completed the KYC process. The details depend on
-  the logic, which is selected by the "$PROVIDER_SECTION".
+  the logic, which is selected by the "$PROVIDER_NAME".
 
   While this is a GET (and thus safe, and idempotent), the operation
   may actually trigger significant changes in the exchange's state.
@@ -5570,8 +5573,8 @@ regulatory compliance.
     service within a reasonable time period.
 
 
-.. http:get:: /kyc-webhook/$PROVIDER_SECTION/*
-.. http:post:: /kyc-webhook/$PROVIDER_SECTION/*
+.. http:get:: /kyc-webhook/$PROVIDER_NAME/*
+.. http:post:: /kyc-webhook/$PROVIDER_NAME/*
 .. http:get:: /kyc-webhook/$LOGIC/*
 .. http:post:: /kyc-webhook/$LOGIC/*
 
@@ -5579,7 +5582,7 @@ regulatory compliance.
   payment target. They provide information to the KYC logic of the exchange
   that allows it to verify that the user has completed the KYC process.  May
   be a GET or a POST request, depending on the specific "$LOGIC" and/or the
-  "$PROVIDER_SECTION".
+  "$PROVIDER_NAME".
 
   **Request:**