From 1a295029028853507c0a833864e2840f3512a678 Mon Sep 17 00:00:00 2001 From: Marcello Stanisci Date: Thu, 12 Nov 2015 23:24:34 +0100 Subject: adding interaction wallet-bank (#4047) --- api-merchant.rst | 14 +----- api-mint.rst | 1 - banks.rst | 147 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ index.rst | 1 + 4 files changed, 149 insertions(+), 14 deletions(-) create mode 100644 banks.rst diff --git a/api-merchant.rst b/api-merchant.rst index e82fd158..daf94c4f 100644 --- a/api-merchant.rst +++ b/api-merchant.rst @@ -252,25 +252,13 @@ for example by updating the DOM to enable the respective button. The following events are needed when one of the two parties leaves the scenario. -First, if the Taler extension is unloaded while the user is +If the Taler extension is unloaded while the user is visiting a checkout page, the page should listen for the .. js:data:: taler-unload event to hide the Taler payment option. -Secondly, when the Taler extension is active and the user closes or navigates -away from the checkout page, the page should listen to a - - .. js:data:: taler-navigating-away - -event, and reply with a - - .. js:data:: taler-checkout-away - -event, in order to notify the extension that the user is leaving a checkout -page, so that the extension can change its color back to its default. - The following source code highlights the key steps for adding the Taler signaling to a checkout page: diff --git a/api-mint.rst b/api-mint.rst index 02a06a29..81f000a5 100644 --- a/api-mint.rst +++ b/api-mint.rst @@ -718,7 +718,6 @@ Administrative API: Bank transactions :>json string error: the error message (`permission denied`) :>json string hint: hint as to why permission was denied - ------------ The Test API ------------ diff --git a/banks.rst b/banks.rst new file mode 100644 index 00000000..27ab6bc0 --- /dev/null +++ b/banks.rst @@ -0,0 +1,147 @@ +=================================== +Interaction with banks Web portals +=================================== + +This section describes the interactions that should occur between +a wallet and a bank which chooses to adapt its Web portal to interact +with the Taler wallet. This interaction is supposed to occur when +the user is sending a SEPA transfer to some mint (i.e. he is creating +a new reserve). + + .. note:: + For its being in early stage of development, the following protocol is + implemented inside the mint code, through a ad-hoc website. + +Through this interaction, the wallet can generate a new reserve's public +key and insert it into the 'subject' field of the transfer without manual +copy&paste. Secondly, the wallet is then able to fetch the amount to be +tranferred to the mint directly from the Web form, in order to poll the mint +to check if the desired amount has been transferred. + +---------------------- +Mutual acknowledgement +---------------------- + +The mutual acknowledgement between a wallet and a bank portal occurs when +the user is on the page which hosts the SEPA form, and is realized by the +mean of JavaScript signals issued on the `body` HTML element. + +When the bank wants to notify to a wallet, it sends the following event: + + .. js:data:: taler-wire-probe + +This event must be sent from a callback for the `onload` event of the +`body` element, otherwise the extension would have not time to +register a listener for this event. It also needs to be sent when +the Taler extension is dynamically loaded, like when the user activates +the extension while he is on the SEPA form page. This is done by +listening for the + + .. js:data:: taler-load + +event. If the Taler extension is present, it will respond with a + + .. js:data:: taler-wallet-present + +event. The handler should then activate its mechanism to trigger the generation +of a new reserve key in the wallet, for example by updating the DOM to enable a +dedicated button. + +If the Taler extension is unloaded while the user is visiting a SEPA form page, +the page should listen for a + + .. js:data:: taler-unload + +event, in order to hide the previously enabled button. + +------------------------- +How to trigger the wallet +------------------------- + +This interaction will make the wallet generate a new reserve public key as +well as paste this information inside the SEPA form. Lastly, it allows the +wallet to fetch the desired amount to be transferred to the mint from the +SEPA form. Typically, it is initiated by the user pushing a button. + +The wallet listens to a + + .. js:data:: taler-create-reserve + +event, through which it expects to receive the following object: + +.. sourcecode:: javascript + {input_amount: input-amount-id, + input_pub: input-pub-id} + +`input-amount-id` is the `id` attribute of the HTML `input` element which +hosts the amount to wire to the desired mint. Please note that the wallet will +only accept amounts of the form `n[.x[y]] CUR`, where `CUR` is the ISO code +of the specified currency. So it may be necessary for the bank's webmaster to +preprocess this data to give it to the wallet in the right format. The wallet +will fetch this element through the following event, triggere by the `onsubmit` +attribute: + + .. js:data:: reserve-submitted + +`input-pub-id` must be the `id` of the `input` element which represents this +SEPA transfer's "subject". + +The following source code highlights the key steps for adding the Taler button +to trigger the wallet on a SEPA form page: + +.. sourcecode:: javascript + + function has_taler_wallet_callback(aEvent){ + // This function is called if a Taler wallet is available. + // suppose the radio button for the Taler option has + // the DOM ID attribute 'taler-wallet-trigger' + var tbutton = document.getElementById("taler-wallet-trigger"); + tbutton.removeAttribute("disabled"); + }; + + function taler_wallet_load_callback(aEvent){ + // let the Taler wallet know that this is a SEPA form page + // which supports Taler (the extension will have + // missed our initial 'taler-wire-probe' from onload()) + document.body.dispatchEvent(new Event('taler-wire-probe')); + }; + + function taler_wallet_unload_callback(aEvent){ + // suppose the button which triggers the wallet has + // the DOM ID attribute 'taler-wallet-trigger' + var tbutton = document.getElementById("taler-wallet-trigger"); + tbutton.setAttribute("disabled", "true"); + }; + +.. sourcecode:: html + + + ... + + +Finally, the following snippet shows how to trigger the wallet to make it +fetch the amount from the DOM + +.. sourcecode:: html + +
+ .. +
+ + diff --git a/index.rst b/index.rst index 597bb96d..991da528 100644 --- a/index.rst +++ b/index.rst @@ -31,6 +31,7 @@ Protocol Specification: api-mint api-merchant + banks Implementation: -- cgit v1.2.3 From 6442b830e572026247abfa44127784d2202b9c07 Mon Sep 17 00:00:00 2001 From: Jeff Burdges Date: Fri, 13 Nov 2015 17:47:39 +0100 Subject: Fix the logical OR between auditors or mints --- api-merchant.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/api-merchant.rst b/api-merchant.rst index daf94c4f..22d8b148 100644 --- a/api-merchant.rst +++ b/api-merchant.rst @@ -145,11 +145,13 @@ successful response to the following two calls: :>json object merchant: the set of values describing this `merchant`, defined below :>json base32 H_wire: the hash of the merchant's :ref:`wire details `; this information is typically added by the `backend` :>json base32 H_contract: encoding of the `h_contract` field of contract :ref:`blob `. Tough the wallet gets all required information to regenerate this hash code locally, the merchant sends it anyway to avoid subtle encoding errors, or to allow the wallet to double check its locally generated copy - :>json array auditors: a JSON array of `auditor` objects. The wallets might concievably insist on sharing using only a mint audited by certian auditors. + :>json array auditors: a JSON array of `auditor` objects. Any mints audited by these auditors are accepted by the merchant. :>json string pay_url: the URL where the merchant will receive the deposit permission (i.e. the payment) - :>json array mints: a JSON array of `mint` objects. The wallet must select a mint that the merchant accepts. + :>json array mints: a JSON array of `mint` objects that the merchant accepts even if it does not accept any auditors that audit them. :>json object locations: maps labels for locations to detailed geographical location data (details for the format of locations are specified below). The label strings must not contain a colon (`:`). These locations can then be references by their respective labels throughout the contract. + The wallet must select a mint that either the mechant accepts directly by listing it in the mints arry, or for which the merchant accepts an auditor that audits that mint by listing it in the auditors array. + The `product` object focuses on the product being purchased from the merchant. It has the following structure: :>json string description: this object contains a human-readable description of the product -- cgit v1.2.3 From 7e64fec21d4f89391ee4587fad7970279e3bebcc Mon Sep 17 00:00:00 2001 From: Marcello Stanisci Date: Sat, 14 Nov 2015 23:29:51 +0100 Subject: adjustments addressing #4047 --- banks.rst | 52 ++++++++++++++++++++-------------------------------- 1 file changed, 20 insertions(+), 32 deletions(-) diff --git a/banks.rst b/banks.rst index 27ab6bc0..602e638a 100644 --- a/banks.rst +++ b/banks.rst @@ -58,10 +58,12 @@ event, in order to hide the previously enabled button. How to trigger the wallet ------------------------- -This interaction will make the wallet generate a new reserve public key as -well as paste this information inside the SEPA form. Lastly, it allows the -wallet to fetch the desired amount to be transferred to the mint from the -SEPA form. Typically, it is initiated by the user pushing a button. +This interaction will make the wallet generate a new reserve public key, +as well as allowing the user to choose his wanted mint. Finally, the wallet +will directly paste this information inside the SEPA form and submit it. +Lastly, it allows the wallet to fetch the desired amount to be transferred +to the mint from the SEPA form. Typically, this trigger is initiated by the +user pushing a button while he is on the page which hosts the SEPA Web form. The wallet listens to a @@ -70,21 +72,25 @@ The wallet listens to a event, through which it expects to receive the following object: .. sourcecode:: javascript - {input_amount: input-amount-id, - input_pub: input-pub-id} -`input-amount-id` is the `id` attribute of the HTML `input` element which + {form_id: sepa-form-id, + input_amount: input-amount-id, + input_pub: input-pub-id, + mint_rcv: receiving-money-mint} + +`input_amount` is the `id` attribute of the HTML `input` element which hosts the amount to wire to the desired mint. Please note that the wallet will only accept amounts of the form `n[.x[y]] CUR`, where `CUR` is the ISO code of the specified currency. So it may be necessary for the bank's webmaster to -preprocess this data to give it to the wallet in the right format. The wallet -will fetch this element through the following event, triggere by the `onsubmit` -attribute: - - .. js:data:: reserve-submitted +preprocess this data to give it to the wallet in the right format. -`input-pub-id` must be the `id` of the `input` element which represents this -SEPA transfer's "subject". +`input_pub` must be the `id` attribute of the `input` element within the form +which represents this SEPA transfer's "subject". +`form_id` must be the `id` attribute of the SEPA `form` element (needed by the wallet to +call `submit()` on it). +Finally, `mint_rcv` is the `id` attribute of the `input` element within the form +from which the server side handler of the SEPA form will fetch the mint base URL to issue +`/admin/add/incoming` on. The following source code highlights the key steps for adding the Taler button to trigger the wallet on a SEPA form page: @@ -127,21 +133,3 @@ to trigger the wallet on a SEPA form page: };"> ... - -Finally, the following snippet shows how to trigger the wallet to make it -fetch the amount from the DOM - -.. sourcecode:: html - -
- .. -
- - -- cgit v1.2.3 From 8af7e16fc536f64838e15bad1af6a994c8ca5e25 Mon Sep 17 00:00:00 2001 From: Marcello Stanisci Date: Mon, 16 Nov 2015 10:43:15 +0100 Subject: little changes for #4047 --- api-mint.rst | 1 + banks.rst | 8 ++------ 2 files changed, 3 insertions(+), 6 deletions(-) diff --git a/api-mint.rst b/api-mint.rst index 81f000a5..f7890507 100644 --- a/api-mint.rst +++ b/api-mint.rst @@ -651,6 +651,7 @@ interception. :>json object sign_info: Public part of the signing key :>json base32 sign_priv: Private EdDSA key +.. _add-incoming: ------------------------------------- Administrative API: Bank transactions diff --git a/banks.rst b/banks.rst index 602e638a..c6565261 100644 --- a/banks.rst +++ b/banks.rst @@ -8,10 +8,6 @@ with the Taler wallet. This interaction is supposed to occur when the user is sending a SEPA transfer to some mint (i.e. he is creating a new reserve). - .. note:: - For its being in early stage of development, the following protocol is - implemented inside the mint code, through a ad-hoc website. - Through this interaction, the wallet can generate a new reserve's public key and insert it into the 'subject' field of the transfer without manual copy&paste. Secondly, the wallet is then able to fetch the amount to be @@ -89,8 +85,8 @@ which represents this SEPA transfer's "subject". `form_id` must be the `id` attribute of the SEPA `form` element (needed by the wallet to call `submit()` on it). Finally, `mint_rcv` is the `id` attribute of the `input` element within the form -from which the server side handler of the SEPA form will fetch the mint base URL to issue -`/admin/add/incoming` on. +from which the server side handler of this form will fetch the mint base URL to issue +`/admin/add/incoming` on; see :ref:`add-incoming`. The following source code highlights the key steps for adding the Taler button to trigger the wallet on a SEPA form page: -- cgit v1.2.3 From 3bb33cefa9226230244957b1c4e82c8b44b1a275 Mon Sep 17 00:00:00 2001 From: Marcello Stanisci Date: Thu, 19 Nov 2015 16:18:50 +0100 Subject: Indicating redirection to fullfillment page --- api-merchant.rst | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/api-merchant.rst b/api-merchant.rst index 22d8b148..647b603f 100644 --- a/api-merchant.rst +++ b/api-merchant.rst @@ -413,10 +413,7 @@ cookies to identify the shopping session. **Success Response:** - :status 200 OK: the payment has been received. - :resheader Content-Type: text/html - - In this case the merchant sends back a `fullfillment` page in HTML, which the wallet will make the new `body` of the merchant's current page. It is just a confirmation of the positive transaction's conclusion. + :status 301 Redirection: the merchant should redirect the client to his fullfillment page, where the good outcome of the purchase must be shown to the user. **Failure Responses:** -- cgit v1.2.3 From e640b72ef66e14e533793939bd6dad5d76aee75b Mon Sep 17 00:00:00 2001 From: Marcello Stanisci Date: Thu, 19 Nov 2015 23:12:43 +0100 Subject: 'amount' field in deposit permission sent to backend --- api-merchant.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/api-merchant.rst b/api-merchant.rst index 647b603f..93aba42e 100644 --- a/api-merchant.rst +++ b/api-merchant.rst @@ -389,6 +389,8 @@ cookies to identify the shopping session. :status 500 Internal Server Error: In most cases, some error occurred while the backend was generating the contract. For example, it failed to store it into its database. +.. _deposit-permission: + .. http:post:: /taler/pay Send the deposit permission to the merchant. Note that the URL may differ between @@ -460,7 +462,7 @@ The following API are made available by the merchant's `backend` to the merchant :reqheader Content-Type: application/json - The `frontend` passes the deposit permission received from the wallet, by adding the field `max_fee` (see :ref:`contract`) and optionally adding a field named `edate`, indicating a deadline by which he would expect to receive the bank transfer for this deal + The `frontend` passes the :ref:`deposit permission ` received from the wallet, by adding the fields `max_fee`, `amount` (see :ref:`contract`) and optionally adding a field named `edate`, indicating a deadline by which he would expect to receive the bank transfer for this deal **Success Response: OK** @@ -468,5 +470,5 @@ The following API are made available by the merchant's `backend` to the merchant **Failure Responses:** - The `backend` will return verbatim the error codes received from the mint's :ref:`deposit` API. If the wallet made a mistake, like by double-spending for example, the `frontend` should pass the reply verbatim to the browser/wallet. This should be the expected case, as the `frontend` cannot really make mistakes; the only reasonable exception is if the `backend` is unavailable, in which case the customer might appreciate some reassurance that the merchant is working on getting his systems back online. + The `backend` will return verbatim the error codes received from the mint's :ref:`deposit ` API. If the wallet made a mistake, like by double-spending for example, the `frontend` should pass the reply verbatim to the browser/wallet. This should be the expected case, as the `frontend` cannot really make mistakes; the only reasonable exception is if the `backend` is unavailable, in which case the customer might appreciate some reassurance that the merchant is working on getting his systems back online. -- cgit v1.2.3 From f39296194956d83fb77a5cc0db3c747d11b72eef Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Thu, 26 Nov 2015 13:35:17 +0100 Subject: should also include auditor URI and must include public key --- api-merchant.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/api-merchant.rst b/api-merchant.rst index 6555a494..973b3459 100644 --- a/api-merchant.rst +++ b/api-merchant.rst @@ -178,6 +178,8 @@ successful response to the following two calls: The `auditor` object: :>json string name: official name + :>json base32 auditor_pub: public key of the auditor + :>json string uri: URI of the auditor The `mint` object: -- cgit v1.2.3 From 824f2d8b9fed9918c66861eb5ee0ce91c68bb0b5 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Thu, 26 Nov 2015 13:53:41 +0100 Subject: clarify API, expand return code 400 for 'bad mint' --- api-merchant.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/api-merchant.rst b/api-merchant.rst index 75720b1b..541dd640 100644 --- a/api-merchant.rst +++ b/api-merchant.rst @@ -59,7 +59,7 @@ wallet active in his browser. So the notification is mutual: We acknowledge that notifying the website leaks the fact that Taler is installed, which could help track or deanonymize users. We believe the usability gained by leaking this one bit represents an acceptable trade off. It would rapidly become -problematic though if several payment options take this approach. +problematic though if several payment options take this approach. Furthermore, there are two scenarios according to which the mutual signaling would succeed. For a page where the merchant wants to show a Taler-style payment @@ -145,7 +145,7 @@ successful response to the following two calls: :>json object merchant: the set of values describing this `merchant`, defined below :>json base32 H_wire: the hash of the merchant's :ref:`wire details `; this information is typically added by the `backend` :>json base32 H_contract: encoding of the `h_contract` field of contract :ref:`blob `. Tough the wallet gets all required information to regenerate this hash code locally, the merchant sends it anyway to avoid subtle encoding errors, or to allow the wallet to double check its locally generated copy - :>json array auditors: a JSON array of `auditor` objects. Any mints audited by these auditors are accepted by the merchant. + :>json array auditors: a JSON array of `auditor` objects. Any mints audited by these auditors are accepted by the merchant. :>json string pay_url: the URL where the merchant will receive the deposit permission (i.e. the payment) :>json array mints: a JSON array of `mint` objects that the merchant accepts even if it does not accept any auditors that audit them. :>json object locations: maps labels for locations to detailed geographical location data (details for the format of locations are specified below). The label strings must not contain a colon (`:`). These locations can then be references by their respective labels throughout the contract. @@ -470,7 +470,11 @@ The following API are made available by the merchant's `backend` to the merchant :status 200 OK: The mint accepted all of the coins. The `frontend` should now fullfill the contract. This response has no meaningful body, the frontend needs to generate the fullfillment page. - **Failure Responses:** + **Failure Responses: Bad mint** + + :status 400 Precondition failed: The given mint is not acceptable for this merchant, as it is not in the list of accepted mints and not audited by an approved auditor. - The `backend` will return verbatim the error codes received from the mint's :ref:`deposit ` API. If the wallet made a mistake, like by double-spending for example, the `frontend` should pass the reply verbatim to the browser/wallet. This should be the expected case, as the `frontend` cannot really make mistakes; the only reasonable exception is if the `backend` is unavailable, in which case the customer might appreciate some reassurance that the merchant is working on getting his systems back online. + **Failure Responses: Mint trouble** + + The `backend` will return verbatim the error codes received from the mint's :ref:`deposit ` API. If the wallet made a mistake, like by double-spending for example, the `frontend` should pass the reply verbatim to the browser/wallet. This should be the expected case, as the `frontend` cannot really make mistakes; the only reasonable exception is if the `backend` is unavailable, in which case the customer might appreciate some reassurance that the merchant is working on getting his systems back online. -- cgit v1.2.3 From a926dfe58dc6ea7a7d45279ba75f33e0818b64f9 Mon Sep 17 00:00:00 2001 From: Marcello Stanisci Date: Thu, 10 Dec 2015 14:16:52 +0100 Subject: micro --- api-merchant.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/api-merchant.rst b/api-merchant.rst index 541dd640..7f003cd5 100644 --- a/api-merchant.rst +++ b/api-merchant.rst @@ -146,7 +146,7 @@ successful response to the following two calls: :>json base32 H_wire: the hash of the merchant's :ref:`wire details `; this information is typically added by the `backend` :>json base32 H_contract: encoding of the `h_contract` field of contract :ref:`blob `. Tough the wallet gets all required information to regenerate this hash code locally, the merchant sends it anyway to avoid subtle encoding errors, or to allow the wallet to double check its locally generated copy :>json array auditors: a JSON array of `auditor` objects. Any mints audited by these auditors are accepted by the merchant. - :>json string pay_url: the URL where the merchant will receive the deposit permission (i.e. the payment) + :>json string pay_url: the relative URL where the merchant will receive the deposit permission (i.e. the payment) :>json array mints: a JSON array of `mint` objects that the merchant accepts even if it does not accept any auditors that audit them. :>json object locations: maps labels for locations to detailed geographical location data (details for the format of locations are specified below). The label strings must not contain a colon (`:`). These locations can then be references by their respective labels throughout the contract. -- cgit v1.2.3 From a41b6cb04d4bd18c8a1e1eb54999dfe2e9c5331f Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Thu, 10 Dec 2015 17:28:42 +0100 Subject: Describe canonical base URLs. --- wallet.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/wallet.rst b/wallet.rst index c8e4c528..836e178e 100644 --- a/wallet.rst +++ b/wallet.rst @@ -11,6 +11,22 @@ The Wallet Reference This section explains how to set up a wallet. It is worth noting that there are two versions for this componenet - one browser based and the other implemented as an `app` for mobile systems. +------- +General +------- + +Mints and merchants have a base URL for their service. This URL *must* be in a +canonical form when it is stored (e.g. in the wallet's database) or transmitted +(e.g. to a bank page). + +1. The URL must be absolute. This implies that the URL has a schema. +2. The path component of the URL must end with a slash. +3. The URL must not contain a fragment or query. + +When a user enters a URL that is, technically, relative (such as "alice.example.com/mint"), wallets +*may* transform it into a canonical base URL ("http://alice.example.com/mint/"). Other components *should not* accept +URLs that are not canonical. + -------------------- Browser based wallet -------------------- -- cgit v1.2.3 From f3d6a0f46238e918e383bca15c76ad96a2c1f50a Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Thu, 10 Dec 2015 17:44:08 +0100 Subject: Rationale for canonical base URLs. --- wallet.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/wallet.rst b/wallet.rst index 836e178e..eaf71c17 100644 --- a/wallet.rst +++ b/wallet.rst @@ -27,6 +27,10 @@ When a user enters a URL that is, technically, relative (such as "alice.example. *may* transform it into a canonical base URL ("http://alice.example.com/mint/"). Other components *should not* accept URLs that are not canonical. +Rationale: Joining non-canonical URLs with relative URLs (e.g. "mint.example.com" with "reserve/status") +results in different and slightly unexpected behavior in some URL handling libraries. +Canonical URLs give more predictable results with standard URL joining. + -------------------- Browser based wallet -------------------- -- cgit v1.2.3 From 46f52c76d015e58adb76efb0b9171da67f11f69d Mon Sep 17 00:00:00 2001 From: Marcello Stanisci Date: Wed, 23 Dec 2015 17:02:47 +0100 Subject: adapting to new contract specs --- api-merchant.rst | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/api-merchant.rst b/api-merchant.rst index 7f003cd5..752b167f 100644 --- a/api-merchant.rst +++ b/api-merchant.rst @@ -132,7 +132,8 @@ successful response to the following two calls: .. http:post:: /contract Issued by the frontend to the backend when it wants to augment its `proposition` with all the - cryptographic information. + cryptographic information. For the sake of precision, the frontend encloses the following JSON inside a `contract` + field to the actual JSON sent to the backend. :>json object amount: an :ref:`amount ` indicating the total price for the transaction. Note that, in the act of paying, the mint will subtract from this amount the deposit fees due to the choice of coins made by wallets, and finally transfer the remaining amount to the merchant's bank account. :>json object max_fee: :ref:`amount ` indicating the maximum deposit fee accepted by the merchant for this transaction. @@ -147,6 +148,7 @@ successful response to the following two calls: :>json base32 H_contract: encoding of the `h_contract` field of contract :ref:`blob `. Tough the wallet gets all required information to regenerate this hash code locally, the merchant sends it anyway to avoid subtle encoding errors, or to allow the wallet to double check its locally generated copy :>json array auditors: a JSON array of `auditor` objects. Any mints audited by these auditors are accepted by the merchant. :>json string pay_url: the relative URL where the merchant will receive the deposit permission (i.e. the payment) + :>json string exec_url: FIXME :>json array mints: a JSON array of `mint` objects that the merchant accepts even if it does not accept any auditors that audit them. :>json object locations: maps labels for locations to detailed geographical location data (details for the format of locations are specified below). The label strings must not contain a colon (`:`). These locations can then be references by their respective labels throughout the contract. @@ -379,9 +381,11 @@ cookies to identify the shopping session. :status 200 OK: The request was successful. :resheader Content-Type: application/json - :>json base32 contract: a :ref:`JSON contract ` for this deal. + :>json base32 contract: a :ref:`JSON contract ` for this deal deprived of `pay_url` and `exec_url` :>json base32 sig: the signature of the binary described in :ref:`blob `. - :>json base32 h_contract: the base32 encoding of the field `h_contract` of the contract's :ref:`blob ` + :>json string pay_url: relative URL where the wallet should issue the payment + :>json string exec_url: FIXME + :>json base32 H_contract: the base32 encoding of the field `h_contract` of the contract's :ref:`blob ` **Failure Response** -- cgit v1.2.3