[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
replay.
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
signature.asc
Description: OpenPGP digital signature