[Top][All Lists]

[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: Thu, 7 Jan 2016 21:02:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

Hash: SHA256

On 01/07/2016 08:28 PM, Christian Grothoff wrote:
> 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_.

There might not be a PKI, but we *always* have a merchant public key
in the contract right now anyways.

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

I'm not saying it's easy, but it's probably not as hard as you make it
out to be in that paragraph.  Essentially we could couple the Taler
merchant key pair to the existing TLS PKI by having a /merchant/keys
page that is delivered over TLS and simply gives the wallet the Taler
merchant key(s).  That doesn't sound too messy to me (of course TLS is
a mess, but that's out of our scope here).

> So let's leave something to handle a special corner case that is
> optional + messy for Taler 2.0.

I'm all for keeping things simple, but I don't think having this one
extra signature by the merchant (just with the same key that was used
in the contract) complicates things too much.  Am I missing some
complication here?

While I agree that we might leave the merchant PKI to Taler 2.0, I do
think that we should still have the fulfillment signature, and leave
it for future extensions to couple/integrate it to/with some PKI.

Especially since it doesn't cost us a lot now, but the cost of
migrating the protocol later might be quite high.

What is the harm in having the fulfillment signature right now, which
might be ignored by current wallets, but that might be used by future
wallets that provide merchant PKI support?

- - Florian
Version: GnuPG v2


reply via email to

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