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

From: Christian Grothoff <[email-masked]>
Date: Sat, 9 Feb 2019 14:30:43 +0100

Dear all,

Ekr suggested I should e-mail this list and ask for dispatch/processing
of the payto:// URI draft.

The draft was previously reviewed on uri-review (twice) and adopted
according to feedback received on uri-review as well as from an IANA
selected anonymous expert.

We would like to see it advance towards RFC status. However, Ekrsaid the
draft was insufficiently trivial for him to accept RFC 7211 AD
sponsorship, and also could not identify a better WG than DISPATCH for
it. So here we are.

As usual, constructive feedback is welcome and we'll also be at IETF 104
for hopefully conclusive discussions after 2 years in the pipeline...

Best regards,

Christian

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 9 Feb 2019 09:13:25 -0800

> The draft was previously reviewed on uri-review (twice) and adopted

Note, I believe you mean "adapted".

-Ekr

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 14 Feb 2019 08:26:05 -0800

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.

- 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.

- 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.

- 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.

- 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.

---

From: Christian Grothoff <[email-masked]>
Date: Sat, 16 Feb 2019 23:06:56 +0100

On 2/14/19 5:26 PM, Richard Barnes wrote:
> - 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.

> 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.

> 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).

> 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.