diff options
Diffstat (limited to 'core/api-exchange.rst')
-rw-r--r-- | core/api-exchange.rst | 87 |
1 files changed, 24 insertions, 63 deletions
diff --git a/core/api-exchange.rst b/core/api-exchange.rst index 27886c24..a2e32579 100644 --- a/core/api-exchange.rst +++ b/core/api-exchange.rst @@ -1046,9 +1046,9 @@ exchange. | ReserveClosingTransaction | ReserveRecoupTransaction; - .. ts:def:: AccountHistoryTransaction + .. ts:def:: ReserveHistoryTransaction - interface AccountHistoryTransaction { + interface ReserveHistoryTransaction { type: "HISTORY"; // Fee agreed to by the reserve owner. @@ -1562,7 +1562,7 @@ denomination. | CoinRecoupTransaction | CoinOldCoinRecoupTransaction | CoinRecoupRefreshTransaction - | CoinPursePaymentTransaction; + | CoinPurseDepositTransaction; .. ts:def:: CoinDepositTransaction @@ -1759,10 +1759,10 @@ denomination. new_coin_ev: RsaBlindingKeySecret; } - .. ts:def:: CoinPursePaymentTransaction + .. ts:def:: CoinPurseDepositTransaction - interface CoinPursePaymentTransaction { - type: "PURSE_PAYMENT"; + interface CoinPurseDepositTransaction { + type: "PURSE_DEPOSIT"; // The total amount of the coin's value absorbed // by this transaction. @@ -2432,12 +2432,11 @@ Wallet-to-wallet transfers TODO for the spec: - * add reserve history requests (with fee!) - to reserve history (changes balance!) - * specify new database schema at exchange (add SQL to DD13!) - - something for in-progress kyc vs. completed kyc? - => add kyc_date to reserves? - => or have separate KYC table instead of NULLs in reserves! + * update DD13 eDB SQL: tables for incoming wads! + * do we need some special entry in account/reserve + histories for incoming WAD-transfers vs. other merges, + or do we re-use the existing 'merge' entry and just + generate it from the incoming-wad table? * update wire transfer API to enable WAD IDs (and while we are at it, should probably also write extended version to allow _merchants_ to query for their inbound transfers, so spec @@ -2445,19 +2444,6 @@ TODO for the spec: tell exchange for inbound wire transfers that they are from a partner bank where KYC fees would be waived! -Discussion: - - * when the user POSTs to /kyc for a reserve with a payto URI - that differs from the URI that was used to establish the - reserve, do we 409 conflict or accept? - That seems like an attack vector: - Say I learn your account pub and wire you money from my - bank account, thus blocking you from /kyc'ing your account!) - * when the user POSTs to /kyc for an account with a payto URI - that differs from the URI that was previously used for a - /kyc for the same account, do we allow the KYC to proceed - and update the bank account? Is there an attack vector? - .. http:GET:: /purses/$PURSE_PUB @@ -2551,12 +2537,12 @@ Discussion: :http:statuscode:`200 OK`: The operation succeeded, the exchange confirms that all coins were deposited into the purse. - The response will include a `PursePaymentSuccess` object. + The response will include a `PurseDepositSuccess` object. :http:statuscode:`202 Accepted`: The payment was accepted, but insufficient to reach the specified purse balance. The client should make further purse deposits before the expiration deadline. - The response will include a `PursePaymentAccepted` object. + The response will include a `PurseDepositAccepted` object. :http:statuscode:`401 Unauthorized`: A coin signature is invalid. This response comes with a standard `ErrorDetail` response. @@ -2656,9 +2642,9 @@ Discussion: } - .. ts:def:: PursePaymentSuccess + .. ts:def:: PurseDepositSuccess - interface PursePaymentSuccess { + interface PurseDepositSuccess { // Total amount paid into the purse. total_purse_amount: Amount; @@ -2667,7 +2653,7 @@ Discussion: total_deposit_fees: Amount; // EdDSA signature of the exchange affirming the payment, - // of purpose TALER_SIGNATURE_PURSE_PAYMENT_CONFIRMED + // of purpose TALER_SIGNATURE_PURSE_DEPOSIT_CONFIRMED // Signs over the above and the purse public key and // the hash of the contract terms. exchange_sig: EddsaSignature; @@ -2677,9 +2663,9 @@ Discussion: } - .. ts:def:: PursePaymentAccepted + .. ts:def:: PurseDepositAccepted - interface PursePaymentAccepted { + interface PurseDepositAccepted { // Total amount paid so far into the purse, in this // and previous requests. @@ -2812,32 +2798,6 @@ Discussion: // purse with the payment. contract?: EncryptedContract; - // Array of payments made to pay for the creation of the - // purse. Can be empty, say if no payment is needed. - payments: CreatePurseDeposit[]; - - } - - .. ts:def:: CreatePurseDeposit { - - // Public key of the coin being used to pay for creating a purse. - coin_pub: EddsaPublicKey; - - // Amount to be deposited, can be a fraction of the - // coin's total value. - contribution: Amount; - - // Hash of denomination RSA key with which the coin is signed. - denom_pub_hash: HashCode; - - // Exchange's unblinded RSA signature of the coin. - ub_sig: RsaSignature; - - // Signature of purpose TALER_SIGNATURE_PURSE_PAYMENT. - // made by the customer with the - // `coin's private key <coin-priv>`. - coin_sig: EddsaSignature; - } .. ts:def:: MergeSuccess @@ -2882,6 +2842,8 @@ Discussion: (from wire transfers or merges of purses) already have a sufficient balance to cover the KYC fee. The signature affirms that the KYC fee can and should be charged to the reserve. + The request always updates the payto URI associated with + the reserve, even if the KYC process fails or is not completed. **Request:** The request body must be a `AccountSetupRequest` object. @@ -2900,11 +2862,6 @@ Discussion: the required KYC checks to open the account. Afterwards, the request should be repeated. The response will be an `AccountKycRedirect` object. - :http:statuscode:`409 Conflict`: - The reserve or account was previously associated with a different - payto URI, and changing the associated bank account is not - permitted. FIXME: should we allow it? Should we use PATCH for this? - Or only conflict if this was an account and not a reserve!?? :http:statuscode:`504 Gateway Timeout`: The exchange did not receive a confirmation from the KYC service within the specified time period. Used when long-polling for the @@ -3002,6 +2959,10 @@ wallet-to-wallet payments. Only another exchange should access this endpoint. // Total transfer amount claimed by the exchange. total: Amount; + // Indicative time by which the wad was given to the + // bank to execute the wire transfer. + wad_execution_time: Timestamp; + // Transfers aggregated in the wad. items: WadItem[]; |