RFC 11: IPRs should be Interledger Packets

[emschwartz]

If we formalize the ILP packet JSON format, we should replace the Interledger Payment Request format with a normal ILP packet. Right now we have too many different formats that express basically the same information but in slightly different ways (different names for the same data fields and a slightly different JSON hierarchy).

I would propose that the IPR format look like:

{
  "account": "us.usd.wf.bob",
  "amount": "10",
  "paymentRequest": {
    "id": "d3c11acf-6232-46c4-8104-015c983a0ff3",
    "expiresAt": "2016-12-29T15:09:20.734Z",
    "condition": "cc:0:3:47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU:0",
    "memo": "This is for that thing"
  }
}

The payment request header would include the condition but the spec would say that sending clients SHOULD remove the condition before sending the payment, because it is redundant information.

Receivers would include the fields listed above (minus the condition) in the hash they use for the condition. This means that no other headers would be included in the MAC. I think we could also make the payment request have a string memo (as opposed to including arbitrary JSON) because it's simpler and because the main use case for this is to include some minimal extra information for the receiver to identify what the incoming payment was for.

[sharafian]

The only issue I can think of with this is that you could have a condition and expiry in the payment_request that don't match the condition and expiry of the local transfer.

If the ILP packet you send is strongly encouraged to be a modified version of this Payment Request ILP Packet, isn't that effectively a third format?

[emschwartz]

The expiry in the payment request is a different one than that in the local transfer. The receiver already should use the one in the payment request (that they set originally), not the one in the transfer. If the one in the transfer is too short they'll try to submit the fulfillment and it will fail. If it's too long it doesn't matter. One of the reasons the expiry in the payment request is included in the MAC though is to make sure that no one can tamper with this detail and make the receiver accept the money after they originally said they would.

If the condition can be in the payment request header I would suggest saying that the receiver MUST remove the condition. They need to remove it for hashing the details anyway, and they should only care about the condition of the transfer.

I think that saying one field of the packet is optional is way better than having a completely separate format. Right now the IPR spec has this additional_headers field, but we haven't needed that yet and didn't actually figure out a good way to include other headers. If you were sending a whole ILP packet, we wouldn't need to figure out a separate way to include headers.