Yeah, I agree with all of your points.
I think we should prioritize documenting and implementing this properly as we just discussed it (seems like many other issues depend on it), do you agree?
On Jan 24, 2016 13:37, "Christian Grothoff" <
address@hidden> wrote:
On 01/24/2016 12:37 PM, Florian Dold wrote:
> 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?
Yes, because some shops may have an internal UUID for the contract that
is not the hash of the JSON-formatted contract Taler expects.
Naturally, in the simplest case this is the hash of the Taler contract,
but we should allow the shop frontend to generate a URI freely and
expect the wallet to pass it through, hence I used UUID to avoid
confusing it with the Taler contract hash.
Note, that, for example, the UUID could be the Merchant's
transaction_id! But again, we should simply not put unnecessary
restrictions here, even that it is "?contract=UUID" is just an example.
> 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.
Yep, this is all frontend-pay logic.
> 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?
Waste of bandwidth. We just downloaded the contract from the merchant
(usually), why send it back? Especially given that the contracts may be
long (tons of items, shipping details, etc.), we should safe bandwidth
by only sending the hash (for Taler) and the UUID (for the merchant's
frontend). That's ~128 bytes, which will be WAY shorter than the
contract --- and most importantly, should also be faster for the
merchant to process, as the merchant developer can design the URI/UUID
mechanism in a way that is easy for the merchant frontend to resolve.