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

[Florian Dold <[e-mail]>]

On 4/12/2018 12:54 PM, Graham Klyne wrote:
>> 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.
> 
> That doesn't really work for me.  URIs that differ in their query
> parameters are _different URIs_, and as such notionally represent
> different resources.  (Query parameters aren't just decorators applied
> to a URI, they are part of the URI.)  So when you say that
> 
>   payto://sepa/CH9300762011623852957?amount=EUR:200.0&message=hello
> 
>   payto://sepa/CH9300762011623852957?amount=EUR:100.0&message=hello
> 
> Both identify the same target, then the query parameters have no role as
> part of the resource identifier.
> 
> It could work for me if a payto: URI were intended to represent
> something like a "pro forma invoice", which could be part of a request
> for payment to some particular account.  If that is your intent, it
> would help to draw this out in the description (and I think many of my
> other comments would fall away).

Thank you for that suggestion! "Pro forma invoice" is indeed very close
to the intention of payto.  I'm worried, however, that it might be a bit
too restrictive, since "pro forma invoice" implies a fixed price and
something that's agreed upon.

One use case on the Web might be a donation link. Let's say I'm running
a charity and want to accept bank transfers to a SEPA bank account.
With payto, I'd include a link

 <a href="payto://sepa/FR-CHARITY-DONATION-ACCOUNT?message=Donation">
   Donate via SEPA transfer
 </a>

In this case there would be no fixed amount, in some cases there might
not even be a fixed message.

I think "a partially filled out transfer form" would describe best what
a payto URI actually identifies.

> In summary, I am unclear how it is that a payto: URI can be said to
> identify whatever it identifies.  (Though I can imagine several
> possibilities.)

Further using the analogy of a partially filled out transfer form (where
only the receiver and type of payment is mandatory), a payto URI would
provide an encoding of exactly that resource.

As shown by the example above as well as many other cases (such as
having clickable links in text messages or emails) there is utility in
encoding this resource as a URI.

>> 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.
> 
> It wasn't my intent to suggest that use of URIs should be restricted to
> the Web, but that if you are using URIs (as opposed to strings that
> happen to look like URIs) then they should be meaningful and consistent
> _if_ they are used in the Web.

I completely agree with your concern, and I do think that payto URIs are
meaningful and consistent if used on the Web, if the default operation
is defined as invoking a dispatcher to a payment handler.

payto URIs with certain payment methods (or "target account types" if
you prefer) can be handled entirely in the browser, by "Payment
Handlers" that use the same machinery as the W3C's Web Payment Working
Group defines.

For other types, processing must be dispatched to another application,
such as your bank's banking application for SEPA payments.

> I wasn't aware of that.  (If they do this, is that domain-based
> registration applicable for *all* URI schemes?)

It depends on the platform.  Android specifically allows applications to
install domain-based handlers for all URI schemes.

> I would guess this is the intent of the "Payment Method registry" [5].
> Could that be positioned instead as a "Payment target account type
> registry" (e.g. focusing on what is identified rather than some
> "method") - might there not be multiple methods to make payment to a
> common account type;  e.g. I would expect that a "sepa" account type
> could be targeted in various ways (e.g. direct instruction to my bank,
> or by a CHAPS transfer instruction to my bank, or by an instruction to
> some third party payment provisioning service, or...)
> 
>   [5] https://tools.ietf.org/html/draft-dold-payto-01#section-9

Yes, I think "Payment target account type" might a better name, and it
also would not clash with the W3C's slightly different concept of
"Payment Method Identifiers".

>>> 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.
> 
> I don't really know where to start here.  Getting confirmation is
> clearly pretty important.   I'm not a security expert, but it seems to
> me that this proposal needs, and has not yet received, some serious
> scrutiny by such.
> 
> But, for example, if the ultimate intent is to activate some third party
> application to handle the payment, then it seems to me that the
> activator ought to be pretty damn sure that the right application is
> being activated.  I can imagine some pretty tricky phishing scenarios
> might be constructed around this.
> 
> OTOH, if the identified resource is framed as something like a pro-forma
> invoice, or a request for payment, then the onus for what one does with
> it is shifted to the application.

To me it seems that the dangers of phishing with payto URIs are no
different from e.g. https URIs.

The only additional danger I see is that payto URIs can invoke your
banking application, and these applications must take care to consider
payto URIs as potentially untrusted and adversarial input.  Furthermore,
invoking payto URIs should not result in any other state change or
action within the banking applications other than showing this
(partially) pre-filled transfer form.

> I'm not really seeing what security concerns (other than "get user
> confirmation first") are being addressed by payto: that could not be
> addressed by a more generic application invocation mechanism.  And a
> generic app mechanism would surely be just as applicable to non-Web
> contexts as payto: would be.

"Application invocation" does not capture the intention of payto URIs,
if seen as a resource that represents a partial transfer form.

Regarding security, the capability to invoke applications generically is
certainly more dangerous than being only allowed to invoke applications
registered as payment handlers.

> (Your comment about non-app scenarios is puzzling to me - I struggle to
> see why a URI is useful in situations where there isn't some "web" or
> "app"-like notion in play.)

What I meant to say was that using the URI syntax to represent
destinations for payments across different payment systems is also
useful for applications outside the Web, as it would be a standardized
format.

> I'll finish by suggesting an alternative approach to payment that I
> believe would play better in Web contexts.  (I don't know about the
> non-web contexts you envisage, so I can't say how it might apply to them).
> 
> 1. Starting point is a URI that identifies a "payment request".  It
> could use *any* URI scheme (maybe even a payto:).
> 
> 2. Dereference the payment request to get a representation of it.  The
> representation would be associated with a Content-type which would in
> turn indicate how the request could be handled.  Different payment
> mechanisms would correspond to different content-types.
> 
> 3. Invoke the appropriate content handler to do something with the
> payment request.
> 
> I proposing this, I note that the intent of the "payto:" scheme might be
> viewed as a way to *represent* payment requests.  If that is the intent,
> we already have a URI scheme that can do that (given an appropriate MIME
> content-type): it is "data:".

What you're describing sounds similar to Payment Pointers
(https://interledger.org/rfcs/0026-payment-pointers).

It is an orthogonal, higher-level concept.  Important use cases are not
covered by it.  If I want to include my SEPA (or some other
existing/legacy payment system) donation link in an electronic document,
a text message, Web site or email, I can't do this with Payment Pointers
unless I first establish this resource than can be dereferenced.

Using data URIs would make many other existing schemes "obsolete" (such
as "geo:", which could easily represented by data).  Using data: for
everything would obscure intent, and results in ugly, unreadable URIs,
which is especially bad when directly visible to the user.

I'd say that more users can tell what a "payto" URI represents when they
receive it via a text message, than an opaque "data" URI that could mean
pretty much anything.

Best,
Florian