[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: Florian Dold
Subject: Re: [Taler] impossibility of payment replay with the current spec
Date: Sun, 24 Jan 2016 12:37:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 01/24/2016 10:05 AM, Christian Grothoff wrote:
> 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'm not sure I understand what you mean by UUID in this context.  Every
contract already has its hash, why would we need a separate UUID?  So
that there's more implementation flexibility for shops?

Thinking about it again, you're right, we do need the payment to be
executed in the context/origin of the merchant, and not of the
wallet/background page, since we need to set cookies there (so that the
fulfillment page has access to them).  This means we can't throw away
the execution page mechanism entirely, but we need to adapt it to allow

Another question is, do we want to implement the mapping from
UUID<->contract in the demo merchant frontend?  Would it not be easier
if the wallet would just send the whole contract, and the fronted would
pass that to the backend?

- Florian

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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