RFC-11: Rename ITP to Payment Request Protocol (PRP)

[emschwartz]

Our analogy with IP Transport protocols is imprecise and calling ITP and other such protocols is confusing because they aren't actually "transporting" anything. Unless we can come up with a better name for this layer I would propose changing the name to something more descriptive of the actual functionality, like Payment Request Protocol.

[emschwartz]

cc @justmoon @adrianhopebailie

[adrianhopebailie]

+1 on not using "transport"

I think in this instance the protocol (ITP) is dependent on the receiver providing all the data so it is in effect generating a payment request. On that basis I think Payment Request Protocol sounds good.

[justmoon]

Agree with not using transport. Not a big fan of "payment request protocol" because it doesn't describe how a payment is requested, which is more SPSP's domain. I like "Interactive", because the requirement to talk to the receiver is an important characteristic of this protocol. (As opposed to non-interactive protocols that would use asymmetric crypto.)

Maybe "Interactive Condition Protocol (ICP)"? (And the people using it could be called juggalos... :wink:)

[emschwartz]

I think your point about "interactive" is a good one.

However, I don't think "Interactive Condition Protocol" is right because this protocol isn't just about conditions. The receiver sets all of the parameters of the packet -- address, amount, additional routing info, and the condition. That was why I thought of those packets as payment requests. You're right though that that creates confusion with requests as HTTP requests.

"Interactive Packet Protocol" :/

"Interactive Packet Setup"... Is this a full "protocol"?

[adrianhopebailie]

"Interactive Packet Setup"... Is this a full "protocol"?

Yes and no.

Short of discovery of the receiver's service endpoint this protocol handles everything required to setup the payment right?

What RFC 11 doesn't define is the transport specific for the protocol (e.g. How to do the interaction via HTTP vs JSON RPC vs ?) so it would be useful to understand where this will be defined if not as part of RFC 11 before naming the protocol in RFC 11.

[emschwartz]

This intentionally leaves out discovery and the communication protocol because having something like this is useful when you want to integrate with different communication protocols.

SPSP (built on top of this) specifies using HTTP.

I'm also working on another that would use a different communication method.

[adrianhopebailie]

SPSP (built on top of this) specifies using HTTP.

I'm also working on another that would use a different communication method.

That's what I wanted to clarify. Which suggest that either Interactive Payment Setup Protocol (for this) or OR Simple Payment Setup Protocol (for SPSP) is a bad name.

[emschwartz]

I think "Simple Payment Setup Protocol" is good, because it does describe what that protocol provides.

This is more like the recommended way to generate ILP packets, including conditions + the idea that they will be created by the recipient and sent in binary ILP packet form to the sender, who can then request a quote for it and send the packet to a connector via a ledger transfer.

What that qualifies as, I'm not sure. But it does seem like theres something of a "layer" here.

Another type of protocol that would fit on this layer would be one that uses public keys instead of hash preimages for the condition. In that case, the sender would generate the ILP packet AND would use the receiver's public key to encrypt fields in the packet destined only for the receiver.

Both the hash preimage and public key approaches are useful building blocks if you want to build a full payment protocol on top of ILP, so it seems worthwhile to standardize them.

[adrianhopebailie]

Agree with all of that.

Since SPSP explicitly defines HTTP as the transport should it not be named accordingly? Or will it evolve to include others? I feel like I'm coming full circle to a name with "Web" in it again.

For ITP: I'm +1 for Interactive: Involves both sender and receiver I'm also +1 for Payment Request: The definition of the ILP Packet by the receiver is, in effect, a payment request.

In terms of layering, this is what I was trying to break down in #65. I had thought of "setup" as the phase where the packet is defined but it's also useful as the overarching definition of what is being done prior to the first ILP transfer being sent.

What are we doing by getting the amount, address, condition and timeout?

• Defining/negotiating/brokering/agreeing on the terms of the payment? (Seems a bit commerce heavy vs simply handling payments)
• Creating/defining the ILP packet? (Packet is a very generic term)
• Initiating a payment request?

If we could define a "verb" for that phase then we can re-use it to make it clear that when you are "establishing the ILP Packet"you use one of the "ILP packet establishment protocols" (For want of a better "verb" than establish).

Interactive Payment Request Initiation Protocol (IPRIP) 😄

[emschwartz]

Since SPSP explicitly defines HTTP as the transport should it not be named accordingly? Or will it evolve to include others? I feel like I'm coming full circle to a name with "Web" in it again.

I could get on board with that.

If we could define a "verb" for that phase then we can re-use it to make it clear that when you are "establishing the ILP Packet"you use one of the "ILP packet establishment protocols" (For want of a better "verb" than establish).

I like where you're going with this.

Interactive Payment (or Packet) Creation... ILP-IPC... creation, construction, generation, composition...

Maybe we don't need "protocol" at the end because it's not a full protocol, just how the packets are constructed.

[adrianhopebailie]

Maybe we don't need "protocol" at the end because it's not a full protocol, just how the packets are constructed.

I was also thinking that. So what is it then? A "scheme", "algorithm", "flow"?

[emschwartz]

Scheme might be a decent way of describing it. So we would have the following:

(Names credit to @bensharaf)

Scheme	Packet Created By	Condition Type	Fulfillment Based On	Non-repudiable?
Receiver Initiated Packet Scheme (RIPS)	Receiver	Preimage-Sha256	HMAC of ILP header using Receiver's secret	Yes
Sender Initiated Packet Scheme (SIPS)	Sender	Ed25519 (or RSA)	Receiver signature on ILP header	Yes
Sender Preimage Initiated Packet Scheme (SPIPS)	Sender	Preimage-Sha256	HMAC of ILP header using Sender secret, which is then encrypted using the Receiver's public key and included in the packet (note this uses public key crypto but does not require all ledgers in the path to support public key conditions)	No (Sender knows the fulfillment so it could have been them that submitted it)

Also note that it is actually not just a packet/condition creation scheme. In all of these cases the Receiver needs to recognize which one the incoming transfer is using in order to take the appropriate action to fulfill it. This might be an argument for having a header in the packet to indicate which scheme was used. Or maybe that would just be inferred from the context (e.g. in SPSP it's always RIPS).

[emschwartz]

@justmoon made a good point about "scheme" referring to higher level payment network rules. So... need a replacement term for that.

[halindrome]

Potential replacements for "scheme": strategy, system, layout, plan

[emschwartz]

Setup?

[halindrome]

I thought about "setup" but.... it felt like this was doing more than the initial handshaking. Which is what I think of when I think of "setup" for a network communication.

[sharafian]

Arrangement, Agreement, Exchange?

[adrianhopebailie]

Strategy is a well understood term in programming (certainly it's used in OO programming) when referring to a "pluggable algorithm" so it seems appropriate to me.

X Packet Definition Strategy

[halindrome]

Yeah - I should have said that I listed my proposed alternatives in preference order. +1 to strategy from me.

[emschwartz]

Another thought: what if we just leave off that last word? The way I would expect these to be used is that one would be chosen for a given higher level protocol, so you could just say "SPSP uses Receiver Initiated Packets" (initiated sounds a bit weird there, but it could be something like "created" instead).

Otherwise, strategy is not terrible

[justmoon]

You didn't mention what your rationale was for "Receiver Initiated *", but I don't think it's a good idea because:

SPSP uses Receiver Initiated Packets

SPSP is sender-initiated.

I was looking at the ITP spec and it consists of two pieces. The "Model of Operation" and the "Specification". The "Specification" is a data format for a payment request.

Rather than "protocol" or "strategy", what if we think of it as just a spec for a data format? The actual protocol, i.e. how you get somebody to make you a piece of data in that format isn't fully specified in the spec anyway. We could still keep it (the "Model of Operation") in the spec, as an implementation guideline, i.e. "if you want to use a payment request based flow, you should probably do something like this."

So I would rename the spec "Interledger Payment Request (ILPR)" or something like that. I'd flip the order to put the format first, i.e. "here is a format for requesting an ILP payment". And then show the "Model of Operation" as a protocol example.

ITP also specifies the condition generation, but specifying that in the Payment Request format spec makes sense imo.

The SPSP spec would then say:

In response to the Setup call, SPSP sends an Interledger Payment Request (ILPR)...

[emschwartz]

So I would rename the spec "Interledger Payment Request (ILPR)" or something like that. I'd flip the order to put the format first, i.e. "here is a format for requesting an ILP payment". And then show the "Model of Operation" as a protocol example.

This sounds fine to me.

ITP also specifies the condition generation, but specifying that in the Payment Request format spec makes sense imo.

If we take the condition out of the packet, how do you think we should express the ILPR? Should it have its own ASN.1 spec that is just a SEQUENCE OF the ILP Packet and Crypto Condition?

Also, what do you think about the 2 other... things... in the table above? What would you call them? Or would you say it doesn't matter right now because we're not going to use them yet anyway?

[adrianhopebailie]

If we take the condition out of the packet, how do you think we should express the ILPR? Should it have its own ASN.1 spec that is just a SEQUENCE OF the ILP Packet and Crypto Condition?

Yes (and the timeout?), although maybe a logical model first and then decide on encoding. In this case it may make sense to define both JSON and binary formats as they will make sense in different cases depending on the "transport".

So it sounds like an ILP Payment Request contains:

1. an ILP Packet (binary, base64 encoded if the packet is JSON) which is the amount and address
2. a condition (which is validated against the packet)
3. a timeout

[emschwartz]

Pretty much.

If the request contains two binary things it may not make sense to have a JSON version. Also note though that ASN.1 is an abstract notation, not an encoding. There are JSON encoding rules, it just so happens that we are choosing to go with OER for most uses.

The timeout is an open question. I put that in there originally because I thought that a) you might want requests to expire and b) the receiver should be stateless. Note that this value is different from the ILP payment expiry, which is set implicitly by the expiry on the first transfer. It's possible that the logic for setting the payment expiry may completely ignore the request expiry. @justmoon made a comment that senders may just use the same expiry for all payments, and this would be a lot simpler. If a receiver specifically wants to ignore requests after a certain timeout they could keep state to track that. Or if requests are relatively short-lived because they are coming for example from a process that's doing a couple of things in memory, the receiver could use a process-specific address and HMAC secret so incoming requests that arrive after the process has died would simply not be fulfilled.

[adrianhopebailie]

If the request contains two binary things it may not make sense to have a JSON version. Also note though that ASN.1 is an abstract notation, not an encoding. There are JSON encoding rules, it just so happens that we are choosing to go with OER for most uses.

Right, so we can use the JSON encoding rules for ASN.1 but I was more concerned about what this would look like in an SPSP response for example.

If the connector and ledger both understand string encoded conditions then you force the connector to convert from binary.

I can imagine a JSON ILP Payment Request in a response to an SPSP POST looking like:

{
  "ilpPacketHeader": "ab23de...", //Base64 encoded 
  "condition": "cc:1:" //String encoded condition
}

You could argue the sender might not even need the ability to unpack the ILP packet header because it was generated based on an amount they sent in the POST and the amount the sender will send is based on a quote from that amount.

[halindrome]

As an aside, one of the things we have been exploring with Verifiable Claims and the Web Payments Core Messaging spec is defining data models in prose and then mapping them into various encodings. If you are planning on doing something similar here, you might find the approach in http://www.opencreds.org/specs/source/claims-data-model/ useful.

[justmoon]

@justmoon made a comment that senders may just use the same expiry for all payments, and this would be a lot simpler.

Just to be clear - I was talking about the ILP header. I think the expiry could be optional there, because the sender's intention is clear from the expiry they put on the local ledger transfer that contains the ILP packet.

I think a payment request SHOULD include an expiry to indicate how long the sender may expect the provided payment request to be valid, since the receiver's intent is not otherwise visible. (You could be a purist and use HTTP cache headers, but I think the expiry may be used more explicitly than just for caching the payment request, so I think it's good to make it explicit in the data.)

[justmoon]

If the request contains two binary things it may not make sense to have a JSON version.

Interesting. I was leaning the other way, i.e.:

{
  "account": "ilpdemo.red.alice",
  "amount": "10.0",
  "condition": "cc:...",
  "expiresAt": "2015-01-01...",
  "extraHeaders": "sjwze9AdzAysww..." // optional
}

Let the sender construct the ILP packet. Pro: Much more readable what the hell is going on. Con: Requires the sender to canonically construct the ILP header. (Doesn't seem terribly difficult if all it contains is account and amount.)

There is definitely some tension arising from using binary format on the lower levels and JSON on the higher levels. Right now I feel strongly about using JSON on the higher levels - efficiency doesn't really matter much for an end-to-end protocol, but since that's the thing that I (developer) am going to work with every day, I need that to be very readable and easy to work with.

As for the lower levels I think it still makes sense to use binary there. You don't want to decode and re-encode packets over and over. Latency is money.

There is some precedent for this in IP world. I type in 127.0.0.1:3921 as the thing to connect to and my computer will construct an IP header with 0f000001 as the address and a TCP header with 0F51 as the port.

If all that's going into the ILP header is account and amount - those are both very easy to translate.

I would like to spend some more time with you guys to think about binary vs JSON for the ILP layer. I know we've discussed it to death, but this is the last chance to change our minds and it's such a crucial aspect influencing both efficiency and ease of adoption.