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

[Christian Grothoff]

On 01/24/2016 09:35 PM, Florian Dold wrote:
> Okay, I see, we've been completely talking past each other because of
> different terminology.  Let me explain, with the news article as an example.
> 
> With the old spec, we'd need these URLs:
> 
> * /pay: Here we POST the deposit permissions to the merchant; this might
> require session state (cookies) on the client-side as a server-side
> requirement.  As you've correctly said, it returns JSON with a
> fulfillment link.
> 
> * /exec: Here we GET a page in the domain context of the merchant in
> order to inject the /pay request so that cookies are transmitted; must
> be a "cooperative" merchant page that sends a DOM event with the
> contract hash to the wallet

I thought we had argued this week that allowing the cookie was a bad
idea, and that the /pay-URI should just include all of the state needed?
That way, AFAIK, we don't need /exec at all anymore, right?

> * /fulfillment: To GET the actual result (the article HTML!)
> 
> * /contract?UID=X to GET a response that reinstates session information
> (such as cookies) for replay (this was the one we discussed earlier
> today, you suggested the name)

Again, I thought you argued nicely for cookie-state to be disallowed.
Also, AFAIK /contract was never expected to do much on the session
management side, it was just supposed to return the JSON-formatted
signed contract.

> /pay and /exec (and presumably /contract) are given to the wallet in the
> wrapper around the contact that also contains the H_contract.

Not sure about passing the /contract URI, I thought only the *result* of
/contract is given to the Wallet, not the URI (a merchant may ship the
contract with the main HTML to avoid an extra round-trip, at the expense
of generating and transmitting contracts that are then never needed).

> /fulfillment is returned by /pay.

If you mean to say, the /fulfillment-URI is included in the /pay body,
then yes.

> Do we roughly agree that this is the "currently proposed" model?

Well, I guess I had mentally never eliminated (or never internalized)
what you called /exec ;-).

> Now, with my suggestion it would be a bit simpler, it's just:
> * /fulfillment?UUID=X

What do you plan to replace here? Do you want to combine all 3? (/pay,
/exec and /fulfillment)? Or even also /contract? Very confusing. I can
see doing away with /exec and just having /fulfillment?UUID=X, but we
still should have /pay and (optionally) /contract.

> This page
> * checks if the client has the right state (in most cases a cookie), and
> delivers the article if that is the case

I thought we decided cookies were bad.  If the UUID is OK as-is (refers
to a paid contract, and if the payment is tied to an IP address, the
client's IP is unchanged), then we execute. Now, cookies could
optionally be used as well, but I'm not sure "in most cases" is the
preferred formulation.

> * otherwise asks the wallet to execute the contract that is associated
> with the URL (i.e. serves as the execution page to inject the request in
> the right domain context)

I'd have described this differently: The merchant generates a page that
interacts with the wallet to trigger the payment dialog.  For this, the
merchant frontend may internally fetch /contract and inline that, or
send JS to the browser where the JS then (as usual) fetches the
/contract page. The page may set a cookie (see above). In either case,
we directly interact with the wallet and effectively ask the wallet
would still ask the wallet to issue a POST to /pay.  The wallet can use
the contract-UUID to detect that it already paid on this very contract
and just auto-replay an old /pay (resulting in the browser being
redirected to a now valid fulfillment, see first case), or if this is a
"first-time" contract, interactively prompt the user to approve it (same
as after "checkout" in shopping cart).

> * if this fails (the wallet does not have the contract) it redirects the
> user agent to a page where the user can buy the product, since the user
> must have gotten the link from somewhere without having bought the product.

Your formulation is unclear here. In particular, you write "it
redirects", but who is "it"?  "it" must not be the merchant's JS, as the
merchant's JS must not be able to learn which contracts our wallet has
executed already.  The merchant's JS is always doing just one thing: ask
the wallet to pay for a contract. Thus, the wallet should be the "it"
that makes a choice here.

Also, your formulation is unclear as to what it means to "redirect the
user agent".  The wallet may move the browser to a wallet-controlled
backend-page showing the contract (where the user can accept/reject).
The wallet should not redirect the user agent to some other "shopping"
page generated by the merchant's frontend.

Agreed?

> This seems much simpler, there are no stronger technical requirements or
> more things we need to implement on the wallet side.
> 
> Replay is always equivalent to just typing the URL again in the browser.

What is your notion of equivalence here? And which URL? If we (still)
have /contract, /pay (POST), and /fulfillment, the 'replay' may _look_
the same for the customer for the /fulfillment in my interpretation of
the design. The customer also never sees /contract and /pay URIs, but
they still exist internally. Also, the replay is technically still very
different, as in some cases (cookie/state OK) we immediately deliver the
information, while in others (no cookie/state bad/payment failed
earlier) we have like 3 additional round-trips with requests to /pay
before the content is finally transmitted.  Now, again this may happen
behind the scenes and thus (more or less) invisible to the customer, but
it's not exactly "equivalent".

> And we get bookmarking for free, and there is less confusion, since
> there are less URLs.

If this is about combining /exec and /pay, I'm fine with that. The
result is nice in that there is only one visible URI to the customer
(the /fulfillment URI). Still, having the POST /pay separate is IMO the
right thing, as is having an (optional) GET /contract URI.

signature.asc
Description: OpenPGP digital signature