[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Grothoff
Subject: Re: [Taler] transaction history UX and fulfillment URL semantics
Date: Mon, 25 Jan 2016 08:14:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]