Re: [Taler] transaction state/history; fulfillment

[Christian Grothoff]

On 12/26/2015 08:00 PM, Florian Dold wrote:
> Hi all,
> 
> I'm currently implementing the transaction history in the WX wallet, so
> that it is actually possible to view the transactions you've made.
> 
> We should talk about when a transaction is considered completed.  I
> think that basically a transaction should count as completed once the
> merchant deposited the coins.  But there is currently no good way to
> certainly know this, since
> 
> * the merchant does not give us a signature that they "accepted" our coins

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

Anyway, IMO this is fine as the "200 OK" is then supposed to give us a
page with all of the fulfillment details or even the product (if we
bought an article), I think this is OK.  I mean, as the wallet we also
don't really care if the merchant succeeded cashing in the coins or not
-- we care that the merchant will give us the goods. And that's what 200
OK should do/signify.  We rely on TLS to authenticate the shop and to
build our cart, it should suffice for the confirmation from the
merchant. Similarly, when you pay with NFC, you better have the goods in
hand afterwards, so again I see no need for a signature.

> * AFAIK it is not possible to request the state of a coin, e.g. the
> transactions a coin was involved in, except when double spending is
> attempted.

And IMO that's a good thing.  See my "5 reasons not to provide a coin
status" on Mantis: https://gnunet.org/bugs/view.php?id=4116

> So we should either require the merchant to sign that they successfully
> deposited our coin, or have an explicit API for the coin state.

Sorry, I still fail to see the need for either.

> Since we need the ability to request infos about coins anyway (when we
> have multiple synchronized wallets with shared coins), we might also use
> this for probing the state of a transaction.
> 
> But should the merchant also give us a signature after payment?

I don't see a real need, or a way to make it truly meaningful here.
(Sure, you may make it a bit meaningful by signing with the TLS server
key, but that's (1) very messy, and (2) won't work if you have NFC
payments or any other kind of future Taler communication channel that
may not tie into DNS+TLS+X.509).

> Also the current demo merchant fulfillment URL is a bit strange, since
> the URL does not contain the necessary information to actually view your
> "purchase"; that information is in the PHP session cookie and not known
> to the wallet.  Should we require that the fulfillment URL contains all
> necessary information (maybe modulo authentication)?  Do we need more
> than a URL?

As we discussed, we should minimize the assumptions we make about how
the Web shop's logic operates. Some shops may track by URL, some by
cookie, some by other means.  I think we should for now support URL *or*
cookie (and thus preserve both, and specify that we preserve both) to
maximize our chances that things work "out of the box" (with minimal
integration effort).

> In theory we can always recover the state that's not included in the
> fulfillment URL by submitting the same contract with the same deposit
> permission again.  But do we want to rely on that?

That's what re-submission from the transaction history is supposed to
do, and we must require from merchants that this works as there may be
network failures (i.e. several hour power outages) that may otherwise
prevent the customer from receiving the confirmation (if they happen at
exactly the wrong time).

0xE29FC3CC.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature