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

[Christian Grothoff]

On 01/25/2016 12:09 AM, Florian Dold wrote:
> 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?

Ah, good point. Can't have the hash of the contract be *in* the contract
;-).  But we could allow a format string, like
"fulfillment_uri":"https://merchant.com/uuid=%s"; and specify that a "%s"
is replaced with the Crockford Base32 encoding of the contract's hash.
By not putting %s, the merchant can put its own custom UUID, and via the
replacement mechanism we get a simple way to avoid the circular dependency.

>>> 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.

As I said in my last e-mail, I'm super-paranoid on this one.  I really
want the automatic information flow back to the pages to be at most 1
bit: is the wallet present or not.  Even that 1 bit should be avoided,
and we can get that via world domination (wallet always present) or
bunding (i.e., wallet always present with Tor users).

signature.asc
Description: OpenPGP digital signature