Formalize mechanism for supporting Content-Negotiation

[David Fuelling]

Overview

Currently, the PaymentPointers spec supports content negotiation for determining which payment types a given endpoint supports.

I would like to formalize a process for getting new definitions into the spec for broader usage. This entails two parts: 1) What are our guidelines for new media types (type, structure, format, etc) 2) What are other media-types that the community supports.

Guidelines for New Media Types

I propose a new page at https://paymentpointers called Payment Method Discovery. This page will outline the discovery process currently details in Flow, but will also detail how to define a new or custom Payment Pointer type.

The most popular new types will make their way into the RFC/spec over time if we properly follow the process in Contributing.

What is needed to support other types?

I propose we attempt to register a new MediaType called application/payment-pointer. For SPSP, the type would be application/payment-pointer+spsp4. This will provide a formal namespace for defining sub-types.

Specifying Sub Types

Question: How should this work?

First New Media-Type

As a first go to dog-food this process, I'd like to formalize an XRPL MediaType. Pending the answer to the above, I think this would be: application/payment-pointer+xrpl+json. But this is kind of ugly.

Vanity or Compliance Use-cases

Also, we should debate/consider how a PaymentPointer should be used, or not used, to indicate additional information, such as anti-spam measures, payment grouping, and possibly a currency indicator for compliance purposes.

For a Receiver

Receivers control who they hand out their payment pointer to. One feature we should consider is similar to gmail addresses where a gmail address [e-mail] can also receive email at [e-mail]. We could consider a similar format for Payment Pointers.

For a Sender

Interledger senders may have compliance reasons to require that their payment terminates in a particular currency. E.g., a US sender might, for tax or compliance/regulatory reasons want to ensure that an Interledger payment to $example.com/alice only work if it terminates in USD. For that to work, a sender (e.g., Bob) might want to pay $example.com/alice+usd and have that payment fail if Alice can't or won't accept USD. This may be an overload of the intended usage for a PaymentPointer, in which case we should clearly identify how users will accomplish this behavior. For example, this might be something that OpenPayments can solve, but we should be clear about how that might happen so everyone feels comfortable if we explicitly make this type of user-facing functionality "out of scope" for payment pointers.

[Adrian Hope-Bailie]

Are we certain that payment method negotiation, based on Content Types is a good idea?

Right now we only have a single protocol defined however we have at least two proposed: XRPL and Open Payments

In Open Payments we've not used this content type negotiation at all.

Can you describe the flow you expect for XRPL and the types of Payment Pointers that would be used?

[David Fuelling]

Are we certain that payment method negotiation, based on Content Types is a good idea

Seems like a good idea if we want Payment Pointers to support varying responses, which I think we do. My proposal widens the resolution to non-ILP cases, but I think even for ILP-specific use-cases, we'll likely have more than SPSP in the future, so in my mind it makes sense to have the ability to negotiate this way, as an option.

Can you describe the flow you expect for XRPL and the types of Payment Pointers that would be used?

The flow would be something like this: Imagine a Wallet that supports sending value using XRPL and ILP. A user on that wallet wants to make a payment to Alice, but only has Alice's PaymentPointer ($money.ilpv4.dev/alice).

The sending wallet would use Payment Pointer resolution (see requests below) to indicate that it prefers to make a payment to Alice using ILP via SPSP.

So, first request to Alice's wallet would look like this:

> curl -X GET -H 'Accept:application/payment_pointer+spsp;q=0.9' \
 -H 'Accept:application/spsp4+json;q=0.8' \
 -H 'Accept:application/payment_pointer+xrpl;q=0.7' \
 http://money.ilpv4.dev/alice -i 

Via content negotiation, the sending wallet has indicated that it prefers SPSP/ILP but just in-case also adds the older SPSP type. If Alice's wallet doesn't support ILP (i.e., neither SPSP content-type is supported via content negotiation), then Alice's server returns the details around how to pay Alice directly on the XRP Ledger (if supported).

For example, if money.ilpv4.dev were only to support SPSP and native XRPL payments, then the response would be the following:

HTTP/1.1 200 OK
content-type: application/payment_pointer+spsp
date: Wed, 12 Feb 2020 23:14:11 GMT
vary: Origin,Access-Control-Request-Method,Access-Control-Request-Headers
{
  "destination_account":"test.jc.money.alice.U7HwDgQiS6jg6Gjr1sjXQGy-",
  "shared_secret":"gd8..."
}

However, one can imagine that money.ilpv4.dev doesn't support ILP (an admittedly strange example considering the domain, but go with me here...) then the server can pick the most appropriate response (depending on the preferred weighting indicated by the client in the Accept headers). In this secondary example, the Payment Pointer would resolve to an XRPL address.

HTTP/1.1 200 OK
content-type: application/payment_pointer+xrpl
date: Wed, 12 Feb 2020 23:14:11 GMT
vary: Origin,Access-Control-Request-Method,Access-Control-Request-Headers
{ 
  "address": "rGk23MmvA24c5dnbDM1Xcpp6kwJjBDRT51",
  "destinationTag":"123456789"
}

Because the sending wallet knows what it supports, it can negotiate the best mechanism to pay Alice, whatever the response from the server.

From my perspective, this actually improves the reachability of Alice from any arbitrary sender, especially in a world where ILP is not yet broadly accepted. Were we to restrict the payment_pointer spec to only support ILP, then in my hypothetical examples above, Alice would be unreachable if her wallet only supported payments over XRPL. However, with this extended flow, Alice is now reachable on the XRPL path.

I would argue that this is in the spirit of Interledger, which has extended reach as one of its underlying ethos foundations.

[Kincaid O'Neil]

This proposal extends payment pointers to wallets that don't support ILP, enabling them to setup payments when the sender and recipient share the same ledger. David articulated that the objective is to help get around Interledger's chicken-and-egg problem, so I'll frame my thoughts in terms of that objective:

1. Inferior experience vs ledger-specific setup protocols. Many ledger-specific payment setup protocols have already gone through extensive iteration, and may not map well on to this simple flow. We don't have expertise to define the best protocol for every ledger, and it's unclear how we'd engage community members from other ecosystems to contribute to this.
2. Still succumbs to chicken-and-egg problem. I think it would prove challenging to sell wallets on using non-ILP payment pointers, since other ledger-specific identity protocols are already much more widely adopted and have a significant network effect.
3. Does not improve wallet interoperability. This requires both the sender and recipient to hold assets on the same ledger, but... so do existing setup protocols. It does help if the sender or recipient hold multiple assets, but I believe (?) most wallet users only hold an account in a single asset, whether we're talking about fiat wallets--e.g. Venmo--or crypto wallets, so this may not be a huge selling point.
4. Significantly degrades the Interledger experience. Interledger payment pointers should--if the network graph is highly connected--successfully work > 95% of the time. If non-ILP payment pointers (which appear the same!) get adopted, they wouldn't "just work," but rather, if they're widely used to setup payments for more than one ledger, they'd likely fail a majority of the time!

[David Fuelling]

This proposal extends payment pointers to wallets that don't support ILP

Reading IL-RFC-26 a bit more closely, Payment Pointers already support Content Negotiation, and the RFC explicitly delegates content-type definitions to payment setup protocols (see here).

Originally I thought that PaymentPointers should define a namespace for content-types, but I'm now seeing this is probably unnecessary. So, I'm going to close this issue because I don't think any changes to Payment Pointers are needed to support what was contained in this proposal.

If non-ILP payment pointers (which appear the same!) get adopted, they wouldn't "just work," but rather, if they're widely used to setup payments for more than one ledger, they'd likely fail a majority of the time!

I'm often perplexed by this concern because the alternatives to it are either the same or worse than what you're suggesting might happen.

Consider two alternate realities: The first reality is one where PaymentPointers do not support anything except ILP, and the second reality is the inverse: PaymentPointers support non-ILP and ILP payment networks.

Given prior art on the Internet (e.g., email addresses, twitter handles, etc) it's likely there will be a near-universal standard for user-facing payment identifiers in a digital payments world. It's coming soon because it's a pain-point for wallets and FIs.

Thus, in the first reality above, it's highly likely that PaymentPointers lose because some other standard becomes dominant. The reason I believe that assertion is because a universal payment identifier can become widely adopted much more quickly than a universal payment system (like ILP).

Thus, it's highly likely that we'll see a universal payment identifier become widely adopted much before ILP becomes widely adopted. IMO, our only path forward here is the second world so that PaymentPointers can win this battle. If we wait for ILP, then it's likely PaymentPointers will never see widespread adoption due to network effects.

So, coming back to UX: if the primary worry is that a user might see a "Payment Failed", I think this worry doesn't align with any reality that a Wallet user will experience -- it's a non-worry.

Consider Alice's experience when Bob gives Alice his PaymentPointer. In the world where PaymentPointers are an ILP-only thing, and Alice's wallet doesn't support ILP, then she'll either have bad human-UX (e.g., "Bob, what the heck is this thing? My wallet doesn't support that") or she'll have bad Wallet-UX (e.g., Alice will enter $example.com/bob into her wallet and see something like "invalid destination"). In other words, the fear you express is already going to happen if we restrict PaymentPointers to ILP. "Payment Failed" is just going to be a natural thing that happens in either world. I submit it will happen less in the liberalized PaymentPointer world.

For proof, consider the alternative experience available to Alice if we embrace PaymentPointer support of non-ILP networks. When Bob gives Alice his PaymentPointer, Alice might still say, "Bob, what the heck is this thing? My wallet doesn't support that" (same experience as above); or, if Alice's wallet supports Payment Pointers but Alice has Bitcoin and Bob has XRP, then Alice will see "Invalid destination" in her wallet (again, same experience as above). However, if Alice and Bob have the same ledger asset type (e.g., XRP), then Alice will be able to enter Bob's payment pointer and actually make a payment.

The liberalized Payment Pointer world always gives Alice either the same or more reachability when it comes to making payments. In other words, liberalized PaymentPointer support never decreases reachability nor increases the instances of "Payment Failed."

I'd love to hear other rationale, but my opinion is that the actual reason people object to this proposal is because there is fear that it will discourage overall ILP adoption by making layer-1 payments more easy from Wallet to Wallet (thus diminishing the value prop of ILP). However, ILP's core value-props are reachability and scalability. Allowing PaymentPointers to resolve to an XRPL address or whatever doesn't fundamentally change this value prop -- so nothing to fear here.

What we should fear is some other universal payments identity system becoming widely deployed. This is coming from someone -- we can either help make that thing PaymentPointers, or we can let something else win. But if something else wins, then chances are slim that the world is going to ever adopt PaymentPointers.

[Kincaid O'Neil]

The liberalized Payment Pointer world always gives Alice either the same or more reachability when it comes to making payments. In other words, liberalized PaymentPointer support never decreases reachability nor increases the instances of "Payment Failed."

I'm not saying it decreases reachability. But it doesn't increase it either (*assuming most users only hold a single currency).

What it does do is hurt is the user experience:

Flow where Bob's wallet supports payment pointers, Alice's doesn't, but both use the same currency:

1. Bob: "Alice, do you support payment pointer?"
2. Alice: "No."
3. Bob: "Alice, do you support XRP?"
4. Alice: "Yes!"
5. Bob: "Great, here's my XRP address."
   😄

(Note that asking for a payment pointer is just an extra/unnecessary step.)

Flow where Bob's wallet supports payment pointers, Alice's doesn't, but they use different currencies:

1. Bob: "Alice, do you support payment pointer?"
2. Alice: "No."
3. Bob: "Alice, do you support XRP?"
4. Alice: "No, I only support BTC."
   😟

(Note that the extra step of asking for payment pointer support was unnecessary, and it would've been faster if Bob just asked if Alice supported XRP directly.)

Flow where both wallets support payment pointers, but use different currencies:

1. Bob: "Alice, do you support payment pointer?"
2. Alice: "Yes!"
3. Bob: "Great, here's my payment pointer."
4. [Payment fails]
   😟

Flow where neither wallet supports payment pointers, but use different currencies:

1. Bob: "Alice, do you support XRP?"
2. Alice: "No, I only support BTC."
   😟

(Just like the previous example, the payment still fails, but it fails faster, and there was no expectation that it was going to work, but there is if both share/support payment pointers.)

Flow where both wallets support payment pointers, and use the same currency:

1. Bob: "Alice, do you support payment pointer?"
2. Alice: "Yes!"
3. Bob: "Great, here's my payment pointer to pay me."
   😄

Flow where neither wallet supports payment pointers, and use the same currency:

1. Bob: "Alice, do you support XRP?"
2. Alice: "Yes!"
3. Bob: "Great, here's my XRP address."
   😄

(Note that this is the same number of steps if both wallets supported payment pointers and they used the same currency, so there's no improvement.)

What we should fear is some other universal payments identity system becoming widely deployed. This is coming from someone -- we can either help make that thing PaymentPointers, or we can let something else win. But if something else wins, then chances are slim that the world is going to ever adopt PaymentPointers.

Maybe. Two pointers (pun intended):

1. I think we're vastly overstating how useful user-readable identifiers are to setup payments. Manually entering an identifier is a bad UX. It should all be automatic, e.g. using PaymentHandler or URIs for digital payments, or using e.g. NFC or high-pitch chirps for in-person payments. And if all payment setup becomes automatic, the backend infra matters more than the user-facing identity solution.
2. If it's true that no one will adopt Interledger if another universal identity solution is adopted, then we're screwed. Because for all the reasons outlined above, I don't think there's a compelling value proposition for this identity solution for it to gain adoption.

[Adrian Hope-Bailie]

Re-opening this for discussion at the next community call.

Also, after discussion with @sappenin I believe I need to update my changes made in 34cae64 but there is not yet consensus in the community on what the change should be.

[David Fuelling]

Thanks @adrianhopebailie - I guess we do have a bit more to talk about here. Loosely, the topics in my mind reduce to the following (plz suggest more and I'll edit this comment):

1. What's the intention of the PaymentPointers RFC?
   1. A tool limited to discovery of Interledger Setup protocol endpoints?
   2. A generic metadata lookup mechanism for Payments?
   3. A way to help users identify each other on the Interledger? On other Payment Networks?
2. Should we care if others use the RFC for some other purpose (assuming conformance to the RFC)?
3. Which user-facing problems does PaymentPointer solve for, and which user-facing problems does it explicitly not solve for.

[Adrian Hope-Bailie]

On agenda for 1 April community call: https://forum.interledger.org/t/community-call-april-1st-2020/972/2

[Adrian Hope-Bailie]

@sappenin - apologies that I never captured the outcome of this call.

My recollection is that the call was split between folks that felt Payment Pointers should be generic (i.e. not specific to ILP) and those that felt they should be specific to ILP.

The rationale for being specific is to provide a guarantee to clients/users that is if you support ILP and consume a Payment Pointer from a counter-party then you will be able to make a payments (i.e. you're both on the same network, ILP)

Given that PayID has forked and is now using a different format for the generic purpose are you happy to close this.

[David Fuelling]

Given that PayID has forked and is now using a different format for the generic purpose are you happy to close this.

Yep, makes sense to me to close. Thanks for closing the loop here.