interledger / rfcs

Specifications for Interledger and related protocols

Home Page:https://interledger.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Idea: Non-repudiable payment receipts for chunked payments

emschwartz opened this issue · comments

The original idea for the Interledger Payment Request (IPR) (and this update) was to provide non-repudiable payment receipts that a sender could use to prove that they had paid the receiver. PSK-style payments, including STREAM, enable sending multiple packets but don't provide non-repudiability -- or so we thought.

We could make an application layer protocol that provides non-repudiable receipts for streaming / chunked payments. For each chunk the receiver gets, they update and sign a receipt indicating how much they have received from the sender. This is unrelated to the conditions used within ILP, so this could be built using any PKI. The receiver's public key would probably be somewhat well-known so that the sender could demonstrate to 3rd parties that the sender paid the receiver.

If the receiver does not sign an updated receipt for a given chunk, the sender would not send any more. Either side could theoretically cheat the other side for the value of a single packet, but just like chunked payments reduce the risk for intermediaries, sending small chunks would reduce the value of this risk to some negligible amount.

Is anyone interested in collaborating on this? I think this would be neat to build on top of STREAM, and it seems like it would be useful for e-commerce use cases @adrianhopebailie @sappenin

It would be interesting to explore a standard for using the same key pair to setup the shared key used by STREAM and then also sign the receipts.

I also wonder if we couldn't harden SPSP a little by using certificates so that SPSP responses provide more guarantees about who the receiver is claiming to be or somehow use the same cert from the TLS connection (which smells a bit but maybe it's okay)?

commented

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat.