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

Florian Dold <florian.dold@inria.fr> Wed, 11 April 2018 11:21 UTC

Return-Path: <florian.dold@inria.fr>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E57126D0C for <uri-review@ietfa.amsl.com>; Wed, 11 Apr 2018 04:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcZ6rKBCPu5H for <uri-review@ietfa.amsl.com>; Wed, 11 Apr 2018 04:21:30 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E64E124BE8 for <uri-review@ietf.org>; Wed, 11 Apr 2018 04:21:29 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,435,1517871600"; d="scan'208";a="322315548"
Received: from 37-173-47-117.coucou-networks.fr (HELO [192.168.43.176]) ([37.173.47.117]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 11 Apr 2018 13:21:27 +0200
To: uri-review@ietf.org
References: <496f8300-4df8-2ca9-751b-e7b481203175@inria.fr> <5ACDBCFE.4030706@ninebynine.org>
From: Florian Dold <florian.dold@inria.fr>
Openpgp: preference=signencrypt
Message-ID: <1257488c-6d8a-a915-57e7-27f035aee991@inria.fr>
Date: Wed, 11 Apr 2018 13:21:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <5ACDBCFE.4030706@ninebynine.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/tvcq506oF0lU5KAr6SZIEzrLNEw>
Subject: Re: [Uri-review] Review request for payto URI scheme, draft 01
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2018 11:21:33 -0000

On 4/11/2018 9:45 AM, Graham Klyne wrote:
> I'm struggling to understand what this idea gains from being a URI (as
> opposed to a string that happens to conform to URI syntax).
> 
> Specifically, what resource is a payto: URI actually intended to
> *identify*?

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.

> And what protocol, if any, is it associated with?

As I understand RFC7595, URIs do not have to be associated with a protocol.

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.

> The idea of using the authority component of a URI to determine a
> processing method seems rather strange to me (and, though here I must
> defer to other experts, I'm not sure that browsers would be able to
> respond appropriately to this:  I understand that the URI scheme itself
> is more commonly used for selecting separate applications to be launched).

There are already cases where browsers behave differently depending on
the authority part of the URI.  It is common for apps on mobile
platforms (such as Android) to register themselves as a handler for a
domain.  If the user clicks a URI with a matching authority, the browser
launches the associated app instead of navigating to the URI.

It would not be an acceptable solution to register a separate URI for
each payment system (such as sepa:, ach:, bitcoin:, paypal:, vemmo:,
...) because the URIs themselves would be very similar (modulo renaming
and minor details), and more importantly it would be a big effort for
applications each time a new payment scheme would be added.  I would
want to be able to click on a payto URI in an electronic invoice that I
received, but my email client or messenger should not have to add
support for each new payment method that is defined.

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

> So here is a thought:  why is this URI scheme specific to making
> payments?  Why not a generic scheme for invoking a local application,
> with parameters, which might happen to be a payment app?  The question
> here is mainly rhetorical, underscoring a dissonance with the web
> architecture principle that a URI should be opaque with respect to the
> type of resource that it references (cf.
> http://www.w3.org/TR/webarch/#uri-opacity).  A URI scheme specifically
> to identify payment-related resources seems at odds with this principle
> (as opposed to a scheme that indicates how to obtain access to a
> resource representation).

Your concern about URI opacity seems to be specific to the Web and maybe
even to HTTP, it is not something that applies to URIs in general.  I
would, for example, expect that a geo: URI actually represents a
geographic location as opposed to a video or spreadsheet.

Just using a generic "app invocation URI" would not be acceptable for
two reasons:  It raises security concerns, and it does not cover use
cases unrelated to the Web or "apps".

Best,
Florian