Re: [Taler] transaction history UX and fulfillment URL semantics

[Christian Grothoff]

On 01/24/2016 08:54 PM, Florian Dold wrote:
> On 01/24/2016 08:42 PM, Christian Grothoff wrote:
>> Let me explain why the simplification for replay from the transaction
>> history does not work: One of the key reasons for replay from
>> transaction history is that the network (or either endpoint) may fail
>> during a transaction. So suppose the wallet issued /pay, but the
>> merchant didn't get it (or at least failed to commit to disk). In this
>> case, the merchant must not enable the fulfillment page, as payment has
>> not yet happened.
> 
> Yes.  The merchant must always detect whether the user may access the
> "real" fulfillment page.  I don't see why this does not work with the
> simplification.

Ok, I guess we're not clear on terminology here.  I distinguish between
the /pay page, which the wallet accesses with a POST where we send the
coins, and upon which the merchant response with a confirmation to the
wallet which then redirects the browser to the fulfillment page, and the
fulfillment page, which the browser obtains with a GET and where the
response is purchase-specific and might be a PDF or anything else
understood to represent the deliverable.

We cannot bookmark the /pay page to be accessed via POST, but that POST
is what we need to enable the customer to replay from the wallet in case
we experience failures between the original POST and completing the "GET".

>> The point of the replay from transaction history is now that the user
>> can replay the payment, thereby *possibly* completing or replaying it it
>> (remember: we just don't know when the network/merchant/client died).
>> Having two different mechanisms (replay vs. direct fulfillment) would be
>> confusing, so the GUI should only have one link.
> 
> That was the main point of my original message, that this distinction
> would be confusing.

Sure, but internally we must distinguish between the POST 'pay' and the
GET 'fulfillment'.  The fact that we hide the POST action from the
customer doesn't mean the distinction is not relevant.

>> We could of course streamline this and replace the 'replay' link with a
>> direct link to the fulfillment page if we ever got the fulfillment page
>> for this transaction before (thus know that the transaction did
>> complete) -- if we also know that the merchant supported the
>> bookmarking.  Still, that's an _optimization_ which would make the
>> wallet more complicated, not simpler, as the replay from transaction
>> history must support full replay of the payment in any case.
> 
> The merchant *has* to support what you call bookmarking for the
> execution page (to allow the WebEx wallet to re-play) anyways. 

I'm not sure what the 'execution' page is (I have a /pay page and a
fulfillment page).

a) If 'execution' refers to '/pay', the merchant has to support POST
being submitted twice (idempotent), by not actually shipping some
physical order twice, but for example an implementation that just sets a
'paid' flag in the DB is already fine and doesn't need to do anything
special. But this does NOT enable bookmarking, as (1) it's a POST
operation and (2) the user never sees this URL anyway.

b) If 'execution' refers to fulfillment, then no, it is conceivable for
the merchant to only show the fulfillment page for a few minutes after
payment and to require the user to replay the payment to get to it
later. The merchant may also limit the fulfillment page by IP, and
thereby deliberately break a link being forwarded. All of these might
make sense as a way to weakly authenticate (!) the user accessing the
fulfillment page.

The "disabled" fulfillment page can of course (as we discussed) interact
with the wallet, re-propose the contract, and thereby cause the wallet
to (auto) replay the POST.

> My suggestion just streamlines the spec, by combining the fulfillment page
> and execution page into one.

I'm either not sure what the 'execution' page is (POST /pay, something
else?) or I fail to see how you plan to combine the POST (wallet) with
the GET (browser).

> Maybe we're not agreeing on terminology.  You could just say that the
> execution page shows a link to the fulfillment page if the payment
> succeeds, that is equivalent to my suggestion (but keeps your definition
> / semantics for the fulfillment page).

In my understanding, the response to the POST for /pay is a JSON which
contains a link for the wallet to redirect the browser to to get the
fulfillment.

> Again, either we're disagreeing just about terminology, or your
> suggestion wouldn't support replay (if I'm not missing something else ...).

I'm thinking the same about your suggestion ;-).

signature.asc
Description: OpenPGP digital signature