Re: [Taler] transaction state/history; fulfillment

[Florian Dold]

-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWjsQ+AAoJENLk8A8p0CpL5IoH/2byU6JDTrxaDtBwK/W3EGTZ
XNXPq54skrTcamRpsMsRmn4uaXdIi3GuNdUjDhfmRDaXEr15CFKgCX5/2uAm1/83
/8RW6W/6zSPSO0/GMViMEb9xHO7qDxZR6xeCwHjH8XGzaaOIpv4f6J8fl5T5uWzt
EiEJ7uGpUOW3ch2xkmCgEkXT3cyIXEOZIv3dCT5HBZBRbVeodrBNKLtJ1AS0OBEY
m/k3/hswxdrI3GjoKe2O9q16EDXLuDPqi8nv3C6Mjja3CFj7A43blHSeZeoxwBAE
ZFY7Q4YYgN1QkbkExY2yKaXbc4epjwntuoJV2bcsSxqUnveoLt76OQTSJSdDs0s=
=9ri0
-----END PGP SIGNATURE-----