Re: [Taler] transaction state/history; fulfillment

[Sree Harsha Totakura]

On 01/07/2016 08:28 PM, Christian Grothoff wrote:
>> Now you could say that Taler merchant contracts are legally binding
>> > offers (with an expiration date), but do (a) merchants really want the
>> > risk associated with this and (b) wouldn't the customer still need
>> > assurance that the merchant received the contract in time?

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.

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.

>> > Having fulfillment signatures is IMHO beneficial to the customer (who
>> > as more assurances / can react more timely) and to the merchant (since
>> > contracts are less binding).  
> I don't think offer from the merchant becomes any less binding, it
> should be just as binding as before, as once the consumer accepted&paid,
> the merchant cannot go back on the offer.  Adding a signature by the
> merchant really just makes it easier for the customer to prove that he
> did indeed accept&pay on time, without needing the help of the mint.
> Regardless, the key issue here is that there is no acceptable PKI for
> the merchants to make such signatures meaningful, so we certainly cannot
> require this _always_. And even in the cases where there is a PKI, this
> gets really messy to implement (try hacking the backend to take the
> server's private TLS keys to sign the contract, and then hack the wallet
> to grab the server's public TLS keys to verify the contract, and store
> the certificate chain; yes, it can be done, but it's MESSY.).  So let's
> leave something to handle a special corner case that is optional + messy
> for Taler 2.0.

Clearly, without the PKI, the merchant could use any key and like before
he can deny receiving the order.  So, it all then boils down to the
previous protocol I wrote at the beginning of the mail.

To summarize, the merchant could cause inconvenience for a customer by
accepting the payment, but not depositing to the mint.  This will also
cause the customer to loose some fraction as he then has to melt the
coin to find out if the merchant played foul.

But why would merchants do that? They are there to make business and
they will lose trust if it happens.  I see that this probably happens if
something were to go wrong technically at the merchant.  OTOH, if the
merchant has deposited the coin at the mint, then the auditing process
will confirm the wrong doing.  This will be a costly endeavour for the
customer, but the legal process will favour the customer in this case.

Regards,
Sree