Enables SPSP for pull payments

[sabineschaller]

Following the discussions in #499 and with @sharafian, this addition adds the possibility for pull payments to the protocol.

[sabineschaller]

After some discussions and taking the comments above into consideration, I updated the response body fields, taking Paypal Subscriptions as an example. However, I tried not to over-complicate things, using as little fields as possible.

[sabineschaller]

Use balance for both push and pull. Negative means the client is expected to be a sender.

I really like that idea.

[sabineschaller]

It shouldn't need asset details like scale and code because these are shared when the STREAM connection is established. Having them in the SPSP response may be useful but then we need to define how a client should behave if it gets different info via SPSP and STREAM.

I do believe we need that because the server could be in XRP, the client in ETH, but the pull agreement was made in a fiat currency, e.g. USD. They both need to use this to adjust their sendMax and receiveMax.

[adrianhopebailie]

My recommendation would be to view SPSP more like HTTP - a general-purpose baseline that is very extensible for different use cases.

In that vein, maybe the ilp address and secret shouldn't be returned in the response but rather in headers.

This frees up the response to be a regular HTTP response and have different types.

i.e. SPSP is simply a spec for augmenting any HTTPS response with two standard headers?

[sabineschaller]

i.e. SPSP is simply a spec for augmenting any HTTPS response with two standard headers?

This would mean making the SPSP spec slimmer and introducing two new specs, one for push and one for pull payments over SPSP, @adrianhopebailie?

[adrianhopebailie]

@sabinebertram yes, that's my proposal but interested to hear from @sharafian @justmoon and @emschwartz too. We've all talked in circles around SPSP for some time and it came up on the community call yesterday too.

My proposal, concretely, is this:

• Any HTTPS request can be treated as an SPSP request by a web server. (By default a Payment Pointer is resolved to a URL and client performs a GET on that URL but this is specified in the Payment Pointer spec not the SPSP spec.)
• The HTTP response should contain headers that carry the ILP address and the shared secret to use to establish the STREAM connection.
• The definition of the HTTP response body and content-type can be defined in another spec (and possibly even leverage existing standards for eInvoices etc)
• This could also be leveraged by websites as an alternative to a Web Monetization <meta> tag in the page (@sharafian @justmoon ?).

A proposal on the header format is to follow the same pattern as the authorization header: <protocol> <details>. Here <protocol> could be STREAM and <details> could be the base64 string that decodes to : (to avoid case changes in-flight)

Aside: I drafted a spec for the IETF a while back that proposed bringing the payment request from the W3C into HTTP: https://tools.ietf.org/html/draft-dold-payto-02

I think that this proposal is a better option than the previous IETF draft because it doesn't need to carry the details of the payment in the header, just the details of the counter-party and how to establish a secure "payment connection" with them.

If we can settle on a spec for this we should consider also submitting to IETF.

[emschwartz]

This discussion is moving beyond the scope of the original PR. I'd suggest opening a separate issue to discuss changing SPSP to be just headers.

FWIW, I'm hesitant to make any breaking changes that aren't very substantive (like moving the STREAM secret and address from the body of a given request to the headers), but this would mean effectively merging SPSP and the HTTP-ILP specs, which doesn't sound terrible. I'm still doubtful how important this is for pull payments because it seems like the main issues are a) how to get the token that you'll use to make the SPSP request or get the STREAM details and b) the format of that token (rather than how to query details about the parameters of the token once you have it).

[sabineschaller]

After discussions with @sharafian and @wilsonianb, I made the SPSP spec backwards compatible by leaving the destination_account and the shared_secret in the body, however, removing the notion of push and pull payments form the spec. It only defines how to request these information and that they are used for creating a stream connection. I created two new specs called SPSP Push Payments and SPSP Pull Payments that concentrate on the payments and the parameters in the response body.

[sabineschaller]

I updated the basic SPSP spec and the pull payment spec according to our discussions on the Forum (Pull Payments and Push Payments and Invoices). The invoice spec still needs work but there have not been any further discussions.

[sabineschaller]

I'm closing this PR and will open individual ones for the new 'basic SPSP' spec as well as the stand-alone pull payment spec. I may also open one on invoices but there have not been any further discussions regarding that spec on the forum so it is on pause.