Re: [Taler] repurchase detection

[Christian Grothoff]

On 02/19/2016 02:00 PM, Florian Dold wrote:
> Hi,
> 
> we introduced the concept of repurchase detection to avoid the following
> scenario:
> 
> 1. Alice buys the essay from the store
> 2. She reads it
> 3. She deletes her cookies and/or local storage for some reason, but
> keeps the wallet state
> 4. She now wants to read the article again.  When she goes to the essay
> store front page to click on it (or a friend sends her a deep link),
> she's asked to pay for the article again, even though she already did.
> 
> Our solution was to add a repurchase_correlation_id to contracts
> (selected by the merchant, could e.g. be the article name itself), so
> that the wallet detects (on taler-confirm-contract) that the user has
> already bought a contract that's equivalent modulo transaction id and
> fulfillment URL (which usually contains the transaction id).
> 
> However it's not clear what the full key for detecting equal contracts
> (modulo tid / fulfillment_url) should be.
> 
> If it's just the correlation ID, what if it clashes for two merchants?
> 
> Should we use the hostname of the fulfillment URL?  The hostname of the
> site that offered the contract (with taler-confirm-contract) in the
> first place?  What if the merchant's hostname changes?

It's much simpler. The contract proposals are signed by the merchant's
public key, so just include the merchant's public key.

> Should we let the user know that it's a re-purchase?  Should they have
> the ability to say "no, I really want to pay for it again"?

If a re-purchase makes sense, then the fulfillment page of the merchant
should have a "re-purchase" button that gives the wallet another
contract with a different correlation ID.  As re-purchase really never
makes sense for media (image, pdf, video), the fulfillment page will be
HTML and so placing such a button is trivial for the merchant.

Happy hacking!

Christian

signature.asc
Description: OpenPGP digital signature