[Top][All Lists]

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

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

From: Christian Grothoff
Subject: Re: [Taler] impossibility of payment replay with the current spec
Date: Sun, 24 Jan 2016 10:05:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

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

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


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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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