Updates to support Open Payments

[adrianhopebailie]

Removed references to SPSP Deprecated the receipt attribute of monetization event

The major change here is for the UA to use Open Payments to send payments rather than directly creating a STREAM connection.

The presumption is that the user has configured two services in the UA, a WM Provider (e.g. Coil) and their Open Payments enabled wallet (e.g. Uphold).

• The WM Provider provides the configuration for how much to pay, who to pay etc
• The wallet exposes Open Payments APIs and during enrolment the browser stores access tokens that it can use to invoke these APIs on behalf of the user (e.g. to create an outgoing payment from the user's account).

The flow would be something like this:

1. User visits a website and the UA parses the Open Payments account endpoint (Payment Pointer) that was extracted from a link tag on the page.
2. Based on the WM Provider configuration the UA determines it should send 50c to the website at that endpoint.
3. UA calls out to the wallet to create an outgoing payment where the receivingAccount is the Payment Pointer and the sendAmount is 50c.
4. The wallet calls out to the monetization receiver (where the website has its account) and creates an incoming payment with no fixed amount. It gets back a new unique URL for that incomingPayment resource.
5. The wallet updates the outgoing payment resource's receivingPayment property to be equal to the URL of the new payment it has just created. (There is an exception condition if the receiver is a legacy wallet and only supports SPSP. This described below)
6. The UA emits the monetization event with the amount of 50c and the URL of the incoming payment created at the monetization receiver as a new property: incomingPayment. The receipt property is deprecated.
7. The website can choose to: 7.1 Trust the UA has sent the payment and act accordingly based on an amount sent of 50c. 7.2 Poll the incoming payment to determine the amount received

This seems the best balance for UX and privacy too.

• The website will get the monetisation event sooner (as soon as the payment is created by the UA at the user's wallet but not waiting for it to be sent and confirmed).
• The website can be optimistic and assume it has been paid but also asynchronously verify how much it actually received.
• The UA can emit the amount in whatever currency it wishes based on user preference (e.g. if it creates an AUD denominated outgoing payment at the user's wallet it could apply a conversion and emit an event in USD) as this is just an indicative value for the website. Using a standard currency or adapting the currency to the locale of the website protects the privacy of the user and possibly helps the website.
• The website can provide UX that makes sense to the user irrespective of the fees and exchange rate that might be applied (i.e. The user sent USD 0.50 so a thank you message of "thanks for the 045 EUR tip" would be kind of weird).

[AlexLakatos]

I'm not a fan of pushing for OP to be the only way to do WM. I'd like to keep supporting both and not be overly restrictive. Many potential nodes(and receivers) in an Interledger future will probably not implement OP (i.e. legacy banks). Can we make this an additive PR instead of replacing receipts entirely? I don't think receipts are going away from raw ILP, and Monetization Providers could be using raw ILP if they chose to.

[marcoscaceres]

@adrianhopebailie, looks like you might need to rejoin the WICG?

[sublimator]

While I'm a fan of the reduction of spec surface that moving to only OP would entail, I don't think we should merge this just yet until OP has been developed/prototyped a bit more.

[adrianhopebailie]

I'm not a fan of pushing for OP to be the only way to do WM

Why not? OP is the successor to SPSP. We should be pushing everyone in the ecosystem to implement it or we risk never having interoperability.

In terms of backwards compatibility, this spec doesn't prevent receivers using SPSP or force them to use OP. Nothing in the WM spec is prescriptive about how the UA actually sends the payments to the receiver.

However, if the UA is forced to use SPSP then the website has no way to verify payments. This is a good ecosystem incentive. Websites have commercial relationships with their receiver. If they want to be able to verify payments under this next version of the standard then they should put pressure on their service provider to support OP.

Many potential nodes(and receivers) in an Interledger future will probably not implement OP (i.e. legacy banks).

I would put the chances of any new participant in the network implementing SPSP and not OP at about 0.0000001%.

Note that supporting SPSP doesn't mean supporting receipts. The two are at different layers of the stack so it's possible to support SPSP and still not expose receipts. (The fact that they are at different layers of the stack is the whole reason we want them taken out.)

IMHO including receipts in a new version of the spec is just additional confusion and implementation burden with no benefit. There are currently 2 receivers in the network, for them to implement OP (at least enough to support incoming payments) would be a minor update from supporting SPSP.

On the server side, how will the incoming_payment be used across sessions. How will it know when fresh payment has come and it's not looking at an amount for services/content already provided etc. Will it need to keep to some state somewhere?

The incoming payment resource will continue to be updated and the receivedAmount will increase as the receiver receives new payments. The website or server can poll this resource to check for increases whenever it gets a website event. It may need to maintain some state to track the receipts across pages but that's just standard session state.

[sublimator]

@adrianhopebailie

There were a few points that came up in the WM meeting yesterday:

• Privacy concerns (SPSP only ever reveals some transient address, vs OP payment pointers revealing account names (even though they don't necessarily have to be associated with the KYC name configured at a wallet))
• OP2 is not ready yet and moving to OP2 only would derail momentum (ILF has someone working on docs for link_rel WM2)
• Talked about at the least incorporating source amounts, perhaps even both

I was hoping to try out hooking up the extension to incoming_payments and play around with your ideas on Monday, but unfortunately have been ill. Will get to it ASAP.

As far as the extension goes, I've talked with Travis and we agreed it probably makes sense to feature flag WM2 (as per the link_rel branch). We could perhaps even restrict the new API to only certain domains (i.e. origin trial). That way we can continue down that path without making it too hard to move to a OP2 only spec.

[AlexLakatos]

I think this merge was a bit premature. We were holding off on having an actual Open Payments implementation before putting that into the WM spec.