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

[Florian Dold]

Okay, I see, we've been completely talking past each other because of
different terminology.  Let me explain, with the news article as an example.

With the old spec, we'd need these URLs:

* /pay: Here we POST the deposit permissions to the merchant; this might
require session state (cookies) on the client-side as a server-side
requirement.  As you've correctly said, it returns JSON with a
fulfillment link.

* /exec: Here we GET a page in the domain context of the merchant in
order to inject the /pay request so that cookies are transmitted; must
be a "cooperative" merchant page that sends a DOM event with the
contract hash to the wallet

* /fulfillment: To GET the actual result (the article HTML!)

* /contract?UID=X to GET a response that reinstates session information
(such as cookies) for replay (this was the one we discussed earlier
today, you suggested the name)

/pay and /exec (and presumably /contract) are given to the wallet in the
wrapper around the contact that also contains the H_contract.

/fulfillment is returned by /pay.

Do we roughly agree that this is the "currently proposed" model?


Now, with my suggestion it would be a bit simpler, it's just:
* /fulfillment?UUID=X

This page
* checks if the client has the right state (in most cases a cookie), and
delivers the article if that is the case
* otherwise asks the wallet to execute the contract that is associated
with the URL (i.e. serves as the execution page to inject the request in
the right domain context)
* if this fails (the wallet does not have the contract) it redirects the
user agent to a page where the user can buy the product, since the user
must have gotten the link from somewhere without having bought the product.

This seems much simpler, there are no stronger technical requirements or
more things we need to implement on the wallet side.

Replay is always equivalent to just typing the URL again in the browser.

And we get bookmarking for free, and there is less confusion, since
there are less URLs.

- Florian


On 01/24/2016 09:15 PM, Christian Grothoff wrote:
> 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