Re: [Taler] replay and merchant backend/frontend protocol

[Christian Grothoff]

On 01/25/2016 11:15 PM, Florian Dold wrote:
> Hi!
> 
> if my understanding is correct, there is currently a deficit in the
> backend/frontend protocol.
> 
> The information we get from /backend/pay is not sufficient to restore
> the client's session state, since the response is empty on success.

I see. So your point is that this forces the frontend to parse the
payment data *and* to resolve the contract hash to a contract, which is
more mess than we'd like in the frontend.  So the "deficit" is that the
frontend is no longer as trivial as it should be, right?

> For example in the donation shop demo, the missing information would be
> the payment amount and the payment receiver ("taler", "tor", "gnunet").
> 
> Of course there are other possibilities to get this information, but for
> our case it seems very convenient to just have the whole contract as a
> response to /backend/pay in the frontend.

I don't think the backend currently even keeps the whole contract, so
doing so would add extra storage and logic to the backend.

We did also discuss that a future version might want to return a message
signed with the private key of the merchant, so that the wallet has
proof that the merchant was paid (and when).  We had a discussion about
the need for a merchant-PKI around feature, and it was not yet implemented.

Still, it might make sense to return basically two things: the signature
over the contract (having the merchant affirm that payment was made) and
the contract.

> For both our demos, the information that the frontend needs from the
> backend can be assembled from the contract (and if not, there should be
> an "extra" field in the contract for the merchant to store
> machine-readable, small pieces of information).

I guess that's a key question: full contract (which may get serveral kb
big and would have to be parsed by the frontend to find the relevant
information) or some kind of summary.  I'd tend to keep it simple,
especially for the first iteration, and just return the full contract
and let the frontend deal with it. However, only the signature should be
sent to the wallet, not the full contract again (because there bandwidth
may matter).

> Now you could argue that always returning the full contract on
> /backend/pay is overhead, but consider that we're talking about loopback
> here in practice, and that it would make the implementation quite easy.

I don't care about the bandwidth here, but the extra database work that
would have to be done and the parsing.  However, I agree that we need to
log the contracts *somewhere*, and having each frontend implement that
logic isn't helpful at making frontends cheap to implement.

> Thoughts?
> 
> Christian or Marcello:  Any volunteers to implement this in the backend,
> while I hack on the wallet and the shop frontend?

Let's make sure we agree on the spec first, and then discuss how/when to
implement it.  I guess this is another issue that 'blocks' you?

-C

signature.asc
Description: OpenPGP digital signature