Hi - I read the rationale behind using HTTP over TLS and it’s very persuasive.
I have some questions and concerns, specifically around forcing a payment receiver to host an HTTP endpoint. I think this is how it is already today. While, it’s very convenient for software development, might face some challenges in point of sale systems specifically in areas with limited connectivity around the globe.
Also, do you feel like HTTP is the final destination or a temporary hop for developing your own? HTTPS does over the convenience of masking the intricacies of DH and whatnot. With clearly more effort I do think you’re better off on the long run building a light protocol over TLS. I think it’s smart to kick off with something widely used like HTTP to bootstrap initial adoption. Overall, the design in the medium article by Evan is pretty solid.
There have definitely been discussions on how to do secure handshakes over Interledger but that requires PKI which makes things really tricky.
In point-of-sale situations you can actually circumvent the need for an HTTP server. The client’s device could communicate to the point of sale terminal with NFC (or with BTLE or with Lasers). They exchange the same information they’d be exchanging over HTTP, and the payment can be completed.
Of course if we’re imagining a scenario where there’s no internet, this becomes trickier. The client would have to send an authorization token of some kind (see the discussion on this forum on pull payments) and the merchant would then pull money at a later time using that token.
3 Likes
Thank you for the answers, Ben. I think it’s smart to keep the payment pointers flexible and not lock the protocol down to a specific path of requests. We’re keeping a close eye on Interledger and will likely be asking more questions.
I think it’s smart to keep the payment pointers flexible and not lock the protocol down to a specific path of requests.
This is where the use of a protocol stack really comes in handy. We can say that payment pointers/SPSP build on top of ILP and they use a specific set of requests over HTTP. But because that’s just an end-to-end concern (i.e. the network isn’t aware of SPSP, only the sender/receiver are) any two parties can use a different protocol to coordinate an ILP payment. This means you can do a lot of experimentation with application protocols on top of Interledger
3 Likes