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

Florian Dold <> Wed, 11 April 2018 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B331126D3F for <>; Wed, 11 Apr 2018 11:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pQIsAhl02c9L for <>; Wed, 11 Apr 2018 11:11:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D345126CD8 for <>; Wed, 11 Apr 2018 11:11:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,437,1517871600"; d="scan'208";a="261715480"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES128-SHA; 11 Apr 2018 20:11:35 +0200
To: Adrian Hope-Bailie <>
References: <> <> <> <>
From: Florian Dold <>
Openpgp: preference=signencrypt
Autocrypt:; prefer-encrypt=mutual; keydata= xsBNBFLwJVABCAC10yX1gNFICGMqqrNrVxSu5RcxRJRrpkqQ5k5X8aOrbL3zjjRNQwV0FR5Y paPR8NLh4FkeAxk8OrkIuNzLPZwcZxhahZx3+IMo/WQldeCHIh7/DSz76jIGzcWSQiP8nJeT rqKBjGiv7mbGFfLfnLjYe4qtJspoZD3DC/F8K100nURckSkog49EZIkOePGhTp2g/EydPJU9 xXnBVsjhXiP2R4fhVqBDC6oi+/9vsycEAy1CyKzuXFaMoskVg1+DtV2JUX6bU+my4LRShrwQ XM7welwTDgetXxNkzOvI59nhTUIklQIhhmjoE+NZ2wIdtLrs/y66cicLFXdkm6EYCKzFABEB AAHNGkZsb3JpYW4gRG9sZCA8ZmxvQGRvbGQubWU+wsCOBBMBCAA4FiEExyDYmq52EZu3XeRZ 0uTwDynQKksFAllF5oUCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQ0uTwDynQKkuC Igf/cDySMmnM6HPqO4yrF30al6Z6lsW3XrcnGnEU+vVgCqvDllpvtM/zskxpvDwSb+gpbFid HoBYDoa15oMh6RWufeXJkQ7Iob6nbX+reD4Z8bkn16Q51nfXIMupj+DGj2cFRMlku2xzbD90 RWPp9Q8aR+vkXHCWbZxooCnmghz4V5VGdmgyYGZ21B1zNjUelynrLZChLNQFZXOxaV1eHVdC pGsWSupgLU10PCnfYoNEBaffSLorFOfVPuMxghYefrLY2hvslk6gDpOkockcJYz2b1WsprMU s/HUVbWA6HcvZoKgQ5sDv1Ot4A04CHMd8U/MLBQ9/H4Lkr+JJbBRWgLwt87ATQRS8CVQAQgA 1CFraC8IOniXUhWaOfUVVjMPpb661WWClfxUcHgMMj7n9vjVbT+6sfT/qoudIJbDswaucz0G dyeZH004PQtZphFFgupEAYKTfP5dt0AXeAPWYbLvKDKHCUzSweQ8dB9l05ab5r6LE1YSyUfg O+vf2JY35oGS/p7heeMuMCYDG9FK9+Ay32vXnBiFmZB77yVBmi2ERtwECBhx4gWp4VuX/MaL 6jABypo1SiRTSO0ZlB5NZHJeyopfE+DCx+YKuLkhvfHM9/GwYh3I18iv5Un623Fo2XmsF3gr 4kKkY5FcnFsmmtdAMlAjfDCWFu+e95PRVjFQ+6dQk77XZBKWDpaapwARAQABwsBfBBgBAgAJ BQJS8CVQAhsMAAoJENLk8A8p0CpL9lAH/1hgJ9Vay7tKDOxxWzQQ4HZ+Ej5gUAIFBlLtdrMv e7JT2KON2x+NYu1MxiPK3jfiIhVSiappJi4l2Uue2b4+Ko5W4TeRsyvJnm2HcxZxwCGvnnH6 uk/w0rYHLJBoaZEEpgOUXz++ttG4UJujaobRExSk41u/EEEWFRC0oQpH+g2wNTEujIyY2K7a RlMfm3ztjqEqrcm9PcS5pXe/cW+jRe8PmiQtVbeaxRzTqwjAOMoMQ0ws9SXdkDtXo3QxpD7s X/oYatZE2oxLd21j0o3zr4vBeO4o8VM+SJUgE0RQFbSRbEzlVsUVfRFcZJDuXfLwy5OY0l/1 GyrC8fvp7XUruTM=
Message-ID: <>
Date: Wed, 11 Apr 2018 20:11:35 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Uri-review] Review request for payto URI scheme, draft 01
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Apr 2018 18:11:42 -0000

On 04/11/2018 06:39 PM, Adrian Hope-Bailie wrote:
> 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/

We have initially considered this.  There are some payment methods,
however, (such as the Indian UPI) that have an "@" character in the
identifier of a user's account, which makes this syntax less attractive
(since "@" is simply forbidden in the userinfo).

Thus we'd have to define an additional encoding for some characters in
the userinfo part of the URI.  When we use the "query parameters" for
this, the encoding is already handled in a standard way.

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

I'd also be happy for the two concepts to align, and I think it's
possible without too many problems.  So far the only fixed payment
method in the WPWG's "Payment Method Identifiers" CR is "basic-card",
where payto would not work, since the money isn't "pushed" to some
target address but "pulled" from the user's credit card.

The URI-based payment methods are restricted to "https" and tied to
particular services on the Web.

An easy way to consolidate the payto URI scheme with the WPWG's work
would be to simply allow payto URIs as payment methods.  This would
preserve backwards compatibility and not interfere too much with the
existing "Payment Method Identifiers" spec.

> 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();

Yes, the ability to initiate payments without JavaScript would be great
(and sought after by privacy conscious users with NoScript browser
extensions).  The processing of the payment in the browser could then
still use the same machinery as defined by the Payment Request API and
related standards.

> Perhaps we can adopt the same payment method registry?

That would work for some payment methods, but not for all.  The payment
methods supported by the Payment Request API are a superset of what can
be supported by payto.  You can't, for example, "address" a merchant's
account with payto in order to pay them via your credit card.

Simply allowing payto URIs (of course without the specific
amount/currency) as payment method identifiers would solve this nicely.

> Finally, I'd like to make you aware of some related work we're doing in
> the Interledger community.
> 1. 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.

Interesting!  I do see the need for such a short identifier that's not
coupled to a particular payment system, and I understand your point
about payto/mailto not being a good analogy.

Though I'd say that payto is completely orthogonal to payment pointers,
and _intended_ to address specific payment methods, even legacy or more
uncommon ones.

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

Certainly, I'll include it in the next draft after I've gathered all the

Thanks for these interesting points!