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

Christian Grothoff <christian@grothoff.org> Sat, 16 February 2019 22:07 UTC

Return-Path: <christian@grothoff.org>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE00128D52 for <dispatch@ietfa.amsl.com>; Sat, 16 Feb 2019 14:07:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Omr0MPnxhwik for <dispatch@ietfa.amsl.com>; Sat, 16 Feb 2019 14:07:27 -0800 (PST)
Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C44127598 for <dispatch@ietf.org>; Sat, 16 Feb 2019 14:07:26 -0800 (PST)
Received: from fencepost.gnu.org ([2001:470:142:3::e]:46686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <christian@grothoff.org>) id 1gv876-0001Z4-OK; Sat, 16 Feb 2019 17:07:16 -0500
Received: from [2001:1620:fe9:0:52a9:7e19:f0bd:5dd6] (port=35606) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <christian@grothoff.org>) id 1gv86y-0001Vh-7l; Sat, 16 Feb 2019 17:07:06 -0500
To: Richard Barnes <rlb@ipv.sx>, Eric Rescorla <ekr@rtfm.com>
Cc: DISPATCH <dispatch@ietf.org>, Florian Dold <Dold@taler.net>
References: <7eac2997-ad7d-8b21-328d-7c80ab4eb730@grothoff.org> <CABcZeBOkZSerTGV3Qkuut3iDsQuufkZg76GRpDPbdHeNoxduxg@mail.gmail.com> <CAL02cgTXHKpHEf_HLVbeHZnX9r6Rq_=hOcyLqg1RDiqMxNhDyQ@mail.gmail.com>
From: Christian Grothoff <christian@grothoff.org>
Openpgp: preference=signencrypt
Autocrypt: addr=christian@grothoff.org; prefer-encrypt=mutual; keydata= mQINBFSG/g0BEADfUtc2WA8+OWiNVuNuaU5CIFB/6Netaem0tXAc5VF8c/Dr/BbteSG4ZAWg CGioO/sqQ08XbYSdot1/zybFqAaD2Tlz99+GFLDYSMSDv6SkaAww0cGbobjkAO3h1ojeR8gw j2+V2DuM9VLsmB0ITH3zXlLg1wbDUeIpOtk12DWqOTFN0v6xhV3JVdFsMmiM21iyo14FIxZm RTJulrwQFi/LcrUR7kDSjuwv3GzmVy6KSArri6fSZec4os6WJM69+N3kV3SwoWxjikfUodaF +kOMXRyfEDX2ebyvveIvMl2BxNu7JUnFY0AHXnxeNbfkpLCuFnH4cVvK14I+hHOa/JTnF77f 7sWb+E0588YLL7geWucJfw94OzM1z4l/BLSyYiY3PJWRUHwkY7FV3cQGgTfrvbX3afa9Vi2b KHbgsgnOpe55FFJTRhZlGJMrgeNsoRKeivFaSa3HLhkV56VG268IM7iao+soVfeWKTOOSQGV eG6VrY7MUjhNfBbYfuSOW9CdF3p3XbI8DF68id0OQRUIihS42+kSGCZVY31Mx8+bZj+7+Qhs hZrARdrdmDg5IvJykEpn7aKpfyhf1sCfu/gwrpZ90IcaYoeafk6qWcf8JL+5VYHewWjfZ7pF tlurt+hlrdNbqDQ9oHtIsevbgsPlh40BZ0kv2vLK5b+hQ5gd3QARAQABtCtDaHJpc3RpYW4g R3JvdGhvZmYgPGNocmlzdGlhbkBncm90aG9mZi5vcmc+iQI4BBMBAgAiBQJUhv4NAhsDBgsJ CAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCTnmvh4p/DzBgKEACH0CAulDnMvk5hh9Ndu2Qv HDAfKWtoj2NsMFw8YCC+Jb5PqmDL8DdnddRWrVxEfYf2DnHQI/wiy0HUJaZQstyHUbENtC2k C+HtQAiQlZyb6qL2ByuQfg8ZbSJYc7hdwSPRt52qXTMh6TPAzoHEWeEWUmYtQTsRna55A6Zo 8HnKzLmspq03kx8wMjO/xtfRzToQNNTNh3Yg5F59sMUqiycrJxuF+y2L3jQLphEWg+yXjak3 ruX3Rc4HpBqdPV36LQ5K+BZp8bzb0Ph2BDZ3t7SFI3SzCAlPl+R+lBtElwe367db+rRo4YPA bPchWXgZ7GIq+t7mVr4dffePEkdFVP8obR8mRtnnhx9Jvsi+6HYSsiBZ/csj1kROXdtTrY56 nc0maWLqVdvrwDlfrWNZxc7doUWBz0nB7VenzDIuBPCiV+jbafXNtNludrjt0RYGvmnad3TM XxQbJsSmpDjSPAeZfaPtZC77BKt4yY2TvQJL9ZuPh7v59UXBwjJAiEP1YacANHExTqk1ShTV y6QNALN0eGifWkogmCtve5rQ1gkqN9TmqnCPGeyZNVzz4j1W/imMRq7+MOVJcpBv0SWDpeFt 13efnajdy4xFPUNXVhuIzE2CzcwdAq4fKG8QLvFnMN5yUo7kcjxAf4WMFkeuo8ofQNHMcFFv BaqMFWR1I0b347kCDQRUhv4NARAAoi0SvMUnd5XSZVSmbwfge2p9KeGVVcaz99fgrUTgCwfo vVd1MEXh8FCtxja4xZiuwSGUARuPAXpzhcK1L9vai25GV+y4SALp3wg1/GrsHtEsm+wm7AeI q0utXnjfnUzfliIIKwt0aGW/zGp/8rHNKh7JVUo0mPSMQfe+6tE2XOnuGDHj1ZyZalmBjVLJ YMwsI0tfAzU1fa0MOSnhvyP5TFFj6PWKSajEOsFuIR/zceZFtJbN24lbXYwohBDBY2Ajb0y8 uYBi/h350UY2mwjKHYM3mxJD3AogWIBz5HD+ueWGUTBpKwLYmN7zVxDMdL7FqGonSw9NV1Xx J3IN1DYPPdFKStRIUiSMzyj/pp6410ms+N1MtPXDIDdcOcmNHqcnkWqBYHXGi+sYyFpe+825 N75dotpEipCnIcTCBjn3RdqFOzT4+airtL7eOkzmooqtPwvNO+4Uza8+W1PLibXqXWqD0uyi 1Wn29asF+uOEfNA4TpTXT6Df5B1X88eoHccCpPUhiNqs7dX1ye78m9oicD9IoXj3PZ0le2tH XuFclXjuffpOW6Wt+rbqMrFp4LA4H4UXafai9B5F1JMp+xdK+V0YUT0aQSZwdHyvNsGReRnu uZKHbe0xokpVM+ndra2EpsV0C3csoDOWyu7yjUyFeTfAlYBb8rn8WuLnT8xzSJEAEQEAAYkC HwQYAQIACQUCVIb+DQIbDAAKCRCTnmvh4p/DzKGQD/wLhO70IEI06MqaP41im4X7suk4zGOA cBXAcsZONq450CA/WHvoMKFoCPHfoC4e1jsoifG8+emfTQhWKwW3a5G/H90a8lY8pH9tqkVU Pds5m6fbWf16xkWUQpH8QQyLwhBIF8onclrDWAHPflpnWp+wso1vxN+WRh5vL1k8dpQLUkOB mE1ovl79/z1zzOYDkOWdQ1crU2EbOXalCmOASmiFhWiYk2aosBxbzGX0JKX5NyIUzz56i9vD YqjkDFYcMMx1Z9YXsvTjglMwnIfwPmvBBgQlwqg+LOts7XF0ZoBZ3NBLpIES0wheVjXtG/T7 kZey7XABVbxK2B4mIRFIvXnHbTEGzSyY7hLCshyCMQTDCoHDOKiNZmteqhHU4zXVgyhrxkYG 9iIDj9yb6PCjaFwgp42rz0lLqTgmpDEIrz1MaCglhTB68wTsHYx3SH+ClNGmgWTa8dS+l/s0 hgE+WknVGn6ShMkdyYLn3QxTRhZSmRv2hG7AYSemtLxi4lLoJ3kDHLMYAponhzxLYOtc8IyN rrRU4Tj4keG2ssHSkC9kDIMqzX53ObGkVWN6Rvu+pmZ9iumrNqI/4PyrPi3mOE7ooIkh1L/M Eu2cLNWaTG5QmOK0VtYN+3G2qzcjKEpQPIDgRdZ6i7fO6jgb0iy1UJUbAoLQgUTaX99KUKey CuiGUA==
Message-ID: <55e82138-eb51-de97-621e-08d0361f0a93@grothoff.org>
Date: Sat, 16 Feb 2019 23:06:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CAL02cgTXHKpHEf_HLVbeHZnX9r6Rq_=hOcyLqg1RDiqMxNhDyQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="asBpdmM0saAPK6FoNxjkIDVtFCx9HQl0Y"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/CspNbLQ-6ocs1qrG-1LXmkfhFOs>
Subject: Re: [dispatch] draft-dold-payto-03
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Feb 2019 22:07:29 -0000

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.