[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Florian Dold
Subject: Re: [Taler] transaction history UX and fulfillment URL semantics
Date: Sun, 24 Jan 2016 21:51:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

And I should mention that with the second suggestion, we still DO have
the /pay page, but it is not part of the contract wrapper anymore, the
wallet does not need to persistently store it.

Whenever the /fulfillment?UUID=X page detects that the session state is
missing / wrong, it just asks the wallet to POST the coins to the
merchant-specific correct URL.

- Florian

On 01/24/2016 09:35 PM, Florian Dold wrote:
> 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 ;-).

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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