This specification has been deprecated.
The Interledger network, since adopting v4 of the protocol, has moved to a model where individual payments are almost always broken up into multiple smaller packets making it impractical to use IPR. As such this spec has been deprecated.
The Interledger Payment Request (IPR) transport protocol is an end-to-end protocol in which the receiver of an Interledger payment first communicates a request for payment to the sender. This document also recommends a method for receivers to generate payment requests such that they can verify incoming payments without storing all outstanding requests.
The Interledger Protocol uses holds based on cryptographic conditions and expiries to ensure a sender's funds are delivered to the destination or returned to the sender's account.
One approach is for conditions to be generated and fulfilled by the receivers of Interledger payments. When the sender of the payment receives the fulfillment, they can be certain that the receiver received the payment.
Receiver-generated conditions are also useful in building non-repudiable application layer protocols. The receiver would generate the condition and cryptographically sign a statement that the preimage of the specified hash indicates the sender has settled a particular debt. The receiver would only disclose the hash preimage upon receipt of payment. Once the sender gets the preimage, they would be able to demonstrate to third parties that they paid the receiver using the preimage and the original signed statement.
In most cases, non-repudiability is unnecessary, as it is sufficient for the sender to get proof that the receiver received the payment even if that proof cannot be used to convince third parties. In such cases, the Pre-Shared Key transport protocol is recommended because it does not require end-to-end communication for every payment.
This document defines a suggested format for representing payment requests and an approach for receiver-generated conditions. Protocols built on top of IPR MAY use the format provided here, though they can use any format they choose instead.
While this document also provides a recommendation for generating transfer conditions, conditions are often opaque to all parties aside from the receiver. Receivers MAY use any condition they choose, however this specification includes best practices that receivers SHOULD take into consideration.
This document does not specify how payment requests are communicated from a receiver to a sender.
Interledger Payment Requests are intended to be used in higher-level protocols as follows:
amountfrom the packet but they MUST treat the
dataas opaque. The sender MUST NOT modify the packet at all, or the receiver will reject the payment.
It is RECOMMENDED that receivers use an implementation of the Pre-Shared Key transport protocol to generate the packet and condition, because it will already include the best practices for generating conditions and enable the receiver to avoid keeping state of all outstanding payment requests.
Note the receiver's method for generating the condition or encoding data in the ILP packet does not matter to the sender. The sender treats the
data in the ILP packet as opaque and uses the condition from the payment request without needing to know how the fulfillment is generated.
The Pre-Shared Key protocol uses the payment condition as a MAC of the payment details by setting the fulfillment to be an HMAC of the ILP packet with a key derived from a secret shared between the sender and receiver. In IPR there is no shared secret and the condition is only generated by the receiver. Nevertheless, an IPR receiver can use the same methods to generate the condition and regenerate the fulfillment on receipt of the incoming transfer.
To use a PSK implementation, the receiver follows these steps:
Receivers MAY use any method they choose for generating the condition, such as using a random fulfillment for each request. The receiver MUST be able to identify and verify the ILP Packet for every outstanding payment and produce the corresponding fulfillment. A PSK implementation handles these requirements without storing every fulfillment and packet in a database, by using the condition as a Message Authentication Code (MAC) of the payment request.
Receivers SHOULD follow these guidelines if implementing a custom system:
Here is a summary of the fields in the Interledger Payment Request format:
||OCTET STRING||ILP Payment packet including the destination address and amount|
||UInt256||Execution condition for the payment|
UInt8 ::= INTEGER (0..127)
IPR version. This document specifies version 2.
OCTET STRING (SIZE(0..65535))
The ILP Payment Packet.
In IPR the sender only uses the
amount from the ILP packet and MUST treat the
data as opaque.
The sender MUST NOT modify the ILP packet at all, or the receiver will reject the payment.
UInt256 ::= OCTET STRING (SIZE(32))
The ILP payment condition, which is the SHA-256 hash of the fulfillment that will be used to trigger the execution of the payment.