Re: [Uri-review] Review request for payto URI scheme, draft 01

[Adrian Hope-Bailie <[e-mail]>]

This seems a very sensible idea to me. A few questions and comments:

How should userinfo and port data in the authority be interpreted in this
scheme? Are they allowed at all?
Would it not be more appropriate to have the method-specific account
identifier in the userinfo?
Example: payto://CH9300762011623852957@sepa/

I'd also like to see if we can align your concepts of payment method with
those being defined in the W3C Web Payments APIs such that there is a clear
mapping between the URI and the payment APIs.

This would make it possible to use these URIs as a declarative way of
invoking the API.
Example:

Clicking an element like <a href="payto://CH9300762011623852957@sepa/
?amount=EUR:10">Pay by SEPA transfer</a> would invoke the same browser
processing as calling the API from Javascript.

new PaymentRequest(
  [{supportedMethods: "sepa", data: {account: "CH9300762011623852957"}}],
  {total:{amount:{currency: "EUR", value: "10.00" }}},
  {}).show();

Perhaps we can adopt the same payment method registry?

Finally, I'd like to make you aware of some related work we're doing in the
Interledger community.

1. Payment Pointers

https://interledger.org/rfcs/0026-payment-pointers/

These are intended to be the equivalent of email addresses for payment
accounts.

I don't entirely agree with your analogy between payto and mailto which is
why we invented payment pointers.

Mailto was an after-thought and a way turn an existing identifier into a
URI form.
Email addresses on their own are very recognizable as such so the URI for
is only useful in machine-read contexts.

The purpose of payment pointers is to create a similar concept for payments.
I.e. An identifier that is simple to exchange and easily recognizable as,
a) not an email address and b) a pointer to a payment account.

That is not to say there is not a need for the payto URI but I don't think
the payto/mailto comparison is a good one or explains the purpose of payto
well.

2. Interledger Addresses

I'd like to request that you add Interledger to your payment method
registry.
The authority would be an ILP Address as defined in:
https://interledger.org/rfcs/0015-ilp-addresses/



On 11 April 2018 at 04:21, Florian Dold <[e-mail]> wrote:

> On 4/11/2018 9:45 AM, Graham Klyne wrote:
> > I'm struggling to understand what this idea gains from being a URI (as
> > opposed to a string that happens to conform to URI syntax).
> >
> > Specifically, what resource is a payto: URI actually intended to
> > *identify*?
>
> It identifies a target for a payment (such as a bank account or a
> bitcoin wallet address) in a unified way.  The options in the URI
> specify further details for making a payment to that target.
>
> > And what protocol, if any, is it associated with?
>
> As I understand RFC7595, URIs do not have to be associated with a protocol.
>
> The application associated with a payto URI is typically a banking
> application (or an electronic wallet app) that allows to make payments
> to the target.
>
> Its use should not be restricted to the Web or "apps", it may also be
> used by financial back-end applications.  You could imagine a library
> that makes payments to targets identified by a payto URI, with different
> plugins handling different payment methods.
>
> > The idea of using the authority component of a URI to determine a
> > processing method seems rather strange to me (and, though here I must
> > defer to other experts, I'm not sure that browsers would be able to
> > respond appropriately to this:  I understand that the URI scheme itself
> > is more commonly used for selecting separate applications to be
> launched).
>
> There are already cases where browsers behave differently depending on
> the authority part of the URI.  It is common for apps on mobile
> platforms (such as Android) to register themselves as a handler for a
> domain.  If the user clicks a URI with a matching authority, the browser
> launches the associated app instead of navigating to the URI.
>
> It would not be an acceptable solution to register a separate URI for
> each payment system (such as sepa:, ach:, bitcoin:, paypal:, vemmo:,
> ...) because the URIs themselves would be very similar (modulo renaming
> and minor details), and more importantly it would be a big effort for
> applications each time a new payment scheme would be added.  I would
> want to be able to click on a payto URI in an electronic invoice that I
> received, but my email client or messenger should not have to add
> support for each new payment method that is defined.
>
> > The security considerations seem a bit thin to me, for something as
> > security critical as making payments.
>
> Do you have any suggestions for what's missing?  The most important
> aspect to me seems to be that no transaction is made until after the
> user can review the details and confirms the payment.  Other aspects are
> inherent to the specific payment system, and would be out of scope for
> this specification.
>
> > So here is a thought:  why is this URI scheme specific to making
> > payments?  Why not a generic scheme for invoking a local application,
> > with parameters, which might happen to be a payment app?  The question
> > here is mainly rhetorical, underscoring a dissonance with the web
> > architecture principle that a URI should be opaque with respect to the
> > type of resource that it references (cf.
> > http://www.w3.org/TR/webarch/#uri-opacity).  A URI scheme specifically
> > to identify payment-related resources seems at odds with this principle
> > (as opposed to a scheme that indicates how to obtain access to a
> > resource representation).
>
> Your concern about URI opacity seems to be specific to the Web and maybe
> even to HTTP, it is not something that applies to URIs in general.  I
> would, for example, expect that a geo: URI actually represents a
> geographic location as opposed to a video or spreadsheet.
>
> Just using a generic "app invocation URI" would not be acceptable for
> two reasons:  It raises security concerns, and it does not cover use
> cases unrelated to the Web or "apps".
>
> Best,
> Florian
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>