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

[Florian Dold]

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 ;-).
>>
>

signature.asc
Description: OpenPGP digital signature