Re: [Taler] impossibility of payment replay with the current spec

[Christian Grothoff]

Hi Florian,

I can see the point in your analysis: we should simply require the
merchant to produce a URI which encodes "everything" for /pay, and is
re-playable.

So basically, in contrast to the existing minimalistic /pay frontend
logic, there'd be the "extra" work of "session" recovery, where say
"/pay?contract=$UUID would resolve $UUID to the contract before passing
the payment request to the backend.

I think that's an acceptable requirement, given that we really need
post-expiration (session cookies, etc) replay here.


My 2 cents

Christian

On 01/24/2016 05:37 AM, Florian Dold wrote:
> Hi all,
> 
> a while ago we added a mechanism to the wallet so that payments are
> executed from a cooperative merchant page (which the merchant has to
> provide in addition to the contract), so that the POST request to /pay
> is from the same origin as the earlier parts of the purchase, and thus
> session cookies will be delivered.
> 
> I think this approach is wrong, and the merchant's /pay should never
> rely on session cookies or any unspecified request parameters.
> 
> Instead, we must have a well-defined API for /pay across merchants,
> which only takes the contract and the deposit permissions.
> 
> This has two reasons:
> 
> 1. It obsoletes the cooperative execution page, and makes the spec
> clearer and simpler.  This is a minor reason though
> 
> 2. More importantly, without a well-defined /pay API for merchants, it
> is impossible to replay contracts in general.
> 
> Basically, if I have a contact and the deposit permissions, I should
> *always* be able to submit that to the merchant, *independent* of any
> session state that the merchant has.
> 
> Right now, payment replay for the demo shop is technically impossible
> due to the way the merchant is implemented (even though it follows the
> spec), no matter what the wallet does.  The /pay page requires a session
> that stores the contract hash we're about to pay for, and there is no
> general way for the wallet to achieve this state.
> 
> Now, we could add another kludge and require some "session reinstatement
> page" (which is again a cooperative page from the merchant that gives us
> the session that's required to pay), but I don't see any good arguments
> for that, in fact it seems rather insane.
> 
> Any thoughts?
> 
> - Florian
>

signature.asc
Description: OpenPGP digital signature