Re: [dispatch] draft-dold-payto-03

[Christian Grothoff <[e-mail]>]

On 2/14/19 5:26 PM, Richard Barnes wrote:
> A couple of comments based on a quick review:
> 
> - It would be useful to know whether there are people interested in
> using this specification, i.e., payers that would parse these URLs and
> use them to initiate payments, and/or payees that would like to publish
> payment coordinates in this way.

Well, we have implemented this in GNU Taler and I have talked to several
banks that today have often their own proprietary format and was told
that if this were a standard, they would support it in their payment apps.

> - What value is there in having a common "payto" URI scheme with a
> payment-type switch underneath it, vs. just having independent URI
> schemes for each payment system?  After all, this document just defiens
> a container; it doesn't provide any functionality that works across
> payment systems.

That depends on what you mean by "payment system". The URI scheme
identifies accounts, but the same bank account can often be accessed
using various payment systems. TARGET, TARGET2, HSBC, FinTS are just
_some_ of the ways interactions can happen with European bank accounts.
My understanding is that in the US, you can often choose between ACH and
Wire Transfers.

So like "http(s)://" no longer uniquely identifies one protocol with
http/2 and http/3 using the same scheme, payto:// is expected to be
independent of the access method and simply identify the resource, not
how to get there.

> - It's unclear to me what the use case is for the query parts.  I can
> understand using the authority and path to identify a payment target. 
> But things like "amount" and "message" seem like things that would be
> added by client software in between parsing a URL and initiating a payment.

When I receive an invoice, it usually includes an amount and an
identifier so that the shop that I am paying can associate the payment
with the transaction that is being paid for.  The payto://-URI
represents a pro-forma invoice, and as such specifying an amount is
usually part of the URI. In fact, I do expect this to be the most common
case, as the client software is usually some banking app that verifies
the users intent and possibly authenticates the user.  Entering the
amount into such apps as is common today is error prone and should be
avoided, just like payto:// reduces the chance of typing in the wrong
account number (even with a 1-digit checksum in IBANs typos cannot be
ruled out).

> - While it's nice that you've created a registry for different payment
> types, they seem a little underspecified.  Even assuming it's clear if I
> just track down all the references, it would be helpful to at least have
> an example of each one.

Good suggestion. We'll add an example for each one in the next draft.

> - I don't think you actually want the whole `authority` production in
> the authority portion.  If you're just going to put a payment type
> identifier there, then you don't need things like a port number.

This was put to follow the general URI scheme of RFC 3986 as much as
possible, but I agree this could be simplified to:

      authority = ALPHA *( ALPHA / DIGIT "-" / "." )

(not even sure if we want to keep allowing "." in this case). So we are
happy to change that.