Re: [Taler] transaction history UX and fulfillment URL semantics

[Florian Dold]

On 01/24/2016 10:43 PM, Christian Grothoff wrote:
> On 01/24/2016 09:51 PM, Florian Dold wrote:
>> And I should mention that with the second suggestion, we still DO have
>> the /pay page, but it is not part of the contract wrapper anymore, the
>> wallet does not need to persistently store it.
> 
> Agreed, if /fulfillment is *required* to auto-redirect to /pay if
> needed, we only need the /fulfillment URI in the contract. In that case,
> it should probably become part of the signed JSON, not just some
> external thing (which is what I think you mean by "contract wrapper").

I've thought about that as well, but we need to be careful when we want
to use the contract hash as UUID, because then we need to do the signing
a bit differently.  Should we allow this?

>> Whenever the /fulfillment?UUID=X page detects that the session state is
>> missing / wrong, it just asks the wallet to POST the coins to the
>> merchant-specific correct URL.
> 
> Sure. Still, here I think the merchant should _always_ replay the full
> contract, as we should not allow Web pages to interrogate the Wallet
> about its contracts in any way.

Hmm I can see what your concern is, but what we want to do here (and in
may other parts of the protocol) depends largely on whether we want to
support session state in the first place or not.

So we should reach consensus on that first ...

Keep in mind though that the fulfillment page

http://blog.demo.taler.net/fulfillment?UUID=FOO

can only query whether the contract with this exact fulfillment URL has
already been purchased or not, so the interrogation is rather limited.

- Florian

signature.asc
Description: OpenPGP digital signature