Re: [Taler] transaction state/history; fulfillment

[Christian Grothoff]

On 01/07/2016 07:58 PM, Florian Dold wrote:
> On 01/07/2016 04:05 PM, Christian Grothoff wrote:
>> Well, but the protocol says that the merchant replies with a "200
>> OK" if (and only if) the payment was successful.  Oh, and there is
>> a reason why there is no signed message here: we don't have a way
>> to reasonably get a public key from the merchant (beyond TLS /
>> X.509), and sigs by just any random key are somewhat useless.  We
>> could introduce it, as the contract contains the merchant's public
>> key (but that's for refunds and thus different). But legally it
>> buys us nothing as the merchant can always say: "that was not my
>> public key, you made this up".
> 
> No, I strongly disagree with you on that point.  Your argument might
> work for the "immediate fulfillment" case that we have with NFC tokens
> and online news articles.  But it does not work in other scenarios,
> where we would also like to use Taler.
> 
> Let's say Alice needs a new $GADGET quickly, so she buys it online
> using Taler; the contract mentions that the merchant will deliver the
> $GADGET within 24 hours to Alice.
> 
> 24h later, Alice's $GADGET still hasn't arrived.  She calls the
> merchant, who tells her "Oh, your payment didn't go through.
> Unfortunately $GADGET was on a limited offer, but we can offer you
> $EXPENSIVE_ALTERNATIVE, which will arrive in 24 hours if you order now!"
> .
> 
> Alice doesn't have a way to prove that the merchant received her coins
> and pledged to fulfill the contract.

Actually, she might. She could have tried a refresh and then gone with
the resulting double-spending error (proving that the merchant got the
coins!) to a timestamping service. Regardless, the mint also might have
timestamps (of the /deposit operation) and hence proof of the mischief
of the merchant.

But, you are of course right that this makes it way trickier for Alice.
Still, the lack of a merchant PKI makes this not really possible, and I
think for various practical reasons we do not want to require a PKI for
merchants.

And, we already provide WAY more evidence to the customer than any
existing system, so I think this is a feature that goes a bit beyond
what I'd *require*. However, I could imagine a future revision of the
protocol to _optionally_ provide such a signature. But really not for 1.0.

> If the protocol would have included a fulfillment signature, she could
> use it against the merchant, who might have to pay her damages for the
> late/missed delivery of $GADGET.  When she pays but the merchant
> doesn't send her the fulfillment signature, Alice can always escalate
> this and/or go shopping somewhere else, so that she receives her
> $GADGET in time.
> 
> There might be an alternative to handle this case (without fulfillment
> signatures), but we definitely need to consider it!
> 
> IANAL, but AFAIK with e.g. German law, the "contract" would just count
> as a "invitatio ad offerendum" [1, 2nd. bullet point "Einzelfaelle"].

Nope, in Taler the merchant's signature signifies that the offer is
an "Angebot" (offerte) in the legal sense, and the coin signatures are
both "Annahme" (acceptio) and payment.  The user clicking "checkout" in
the shopping cart could be seen as asking for an offer.

> 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?

The risk you construct here for the merchant doesn't really exist, as he
can theoretically expire the contract after 5 minutes or for whatever
time a lock really doesn't hurt him.

> 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.

signature.asc
Description: OpenPGP digital signature