taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] transaction state/history; fulfillment


From: Florian Dold
Subject: Re: [Taler] transaction state/history; fulfillment
Date: Fri, 8 Jan 2016 18:07:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 01/08/2016 05:19 PM, Sree Harsha Totakura wrote:
> It is expected that the merchant would give the customer an order number
> via HTTP 301 redirection to an order/checkout confirmation page after
> the payment has been processed.  If the customer hasn't received it, it
> means that the order is not processed/confirmed by the merchant.

First of all, we don't use HTTP 301 anymore (but HTTP 200 with a JSON
body), due to limitations in some of the environments where we want to
implement a wallet (in particular the WebExtensions API, where we must
use an XMLHttpRequest that handles redirects transparently and in a
different context than the merchant's page).

> If the customer gets the order number, then he can follow up on the
> merchant for not fulfilling the contract.  But then the merchant could
> simply say that the order confirmation is not given by him.  At this
> point the customer: 1. will lose some trust in the merchant and 2. can
> try to melt the coin.  If the customer succeeded in melting the coin,
> then it is just a case of something going awry at Merchant.  If not, it
> means that the merchant played foul and hence it this cloud be legally
> challenged.  I believe our auditor mechanisms help the legal proceedings.

There's always more complex alternatives (using the refreshing protocol
to check that coins were used, or using some time-stamping service), but
the fulfillment signature provides a very simple way for the customer to
prove that they payed in time *once* the contract's key can be
associated with the merchant's long term key.  That association might
only be available in future versions of Taler.  You're right in that
currently the merchant_pub in the contract could be an ephemeral key.

Without the fulfillment signature, it's much harder for the customer to
know that "I paid the merchant, the merchant knows that and I can sue
him if he doesn't deliver".  If Taler contracts are legally binding,
then they will have to have a short expiration time, and the merchant
would be able to claim "the customer didn't pay before the contract
expiration" and the customer has nothing to counter that claim.

I don't see why we should leave out this possibility when it costs us
basically nothing (one Ed25519 signature).

Here's why I insist on including it:  There is no harm that comes from
it, and it is very hard to evolve a protocol later when your
requirements and assumptions change.  Just consider the changes that we
had to make to the protocol when implementing the wallet for the
WebExtensions API, which broke assumptions about the client that the
protocol made.


- Florian



reply via email to

[Prev in Thread] Current Thread [Next in Thread]