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

[Graham Klyne <[e-mail]>]

Hi,

I'll respond first to a later point in your message, because it colours my 
responses to other points:

On 11/04/2018 12:21, Florian Dold wrote:
 > 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.

My concern _is_ with respect to the Web, but is not at all specific to HTTP.

The URI spec is one of the core specifications of the World Wide Web, so it 
seems to me reasonable that other specifications that use URIs should do so in a 
way that is consistent with Web architecture.  (I agree with your comment about 
geo: - I don't see any inconsistency there.)

One of the core notions of web architecture is separation of concerns (e.g., 
[1]). Specifically, identification, interaction and representation are handled 
by separate elements of the whole.

   [1] http://www.w3.org/TR/webarch/#cpi

The role of URIs in Web is to identify resources [2] (and, by implication, not 
to encode an interaction beyond what is needed to identify the resource; e.g. 
[3]).  This intent is also reflected in sectiuon 1 of the URI spec [4].

   [2] http://www.w3.org/TR/webarch/#pr-use-uris

   [3] http://www.w3.org/TR/webarch/#lc-uri-chars

   [4] https://tools.ietf.org/html/rfc3986#section-1


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

That doesn't really work for me.  URIs that differ in their query parameters are 
_different URIs_, and as such notionally represent different resources.  (Query 
parameters aren't just decorators applied to a URI, they are part of the URI.) 
  So when you say that

   payto://sepa/CH9300762011623852957?amount=EUR:200.0&message=hello

   payto://sepa/CH9300762011623852957?amount=EUR:100.0&message=hello

Both identify the same target, then the query parameters have no role as part of 
the resource identifier.

It could work for me if a payto: URI were intended to represent something like a 
"pro forma invoice", which could be part of a request for payment to some 
particular account.  If that is your intent, it would help to draw this out in 
the description (and I think many of my other comments would fall away).

>
>> And what protocol, if any, is it associated with?
>
> As I understand RFC7595, URIs do not have to be associated with a protocol.

Yes, that was sloppy of me.  Let me try to do better.

In order to identify a resource, many URIs do so by indicating a protocol and 
associated protocol elements to be used in order to interact with that resource 
(e.g., http:).  Others do so by indicating some locally defined mechanism and 
values for interacting with the resource (e.g. file:, mailto:).  Others do so by 
indicating an intermediate authority (e.g. URNs).  Others do so by providing an 
encoding of a resource representation (e.g.data:, geo:).  Others do so by 
incorporating a value that is uniquely associated in some defined way with the 
intended resource (e.g. ni:).

The intent of payto: appears to fall into one of the first two categories, 
except it's not clear what kind of mechanism is intended.  The "authority" 
element could be regarded as a URN-style intermediate authority, which makes the 
payto: scheme look more like a URN.

In summary, I am unclear how it is that a payto: URI can be said to identify 
whatever it identifies.  (Though I can imagine several possibilities.)

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

It wasn't my intent to suggest that use of URIs should be restricted to the Web, 
but that if you are using URIs (as opposed to strings that happen to look like 
URIs) then they should be meaningful and consistent _if_ they are used in the Web.

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

I wasn't aware of that.  (If they do this, is that domain-based registration 
applicable for *all* URI schemes?)

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

I can appreciate that.  Assuming authority-based delegation to some application, 
then I would be looking for greater clarify about how the delegation is chained.

I would guess this is the intent of the "Payment Method registry" [5]. Could 
that be positioned instead as a "Payment target account type registry" (e.g. 
focusing on what is identified rather than some "method") - might there not be 
multiple methods to make payment to a common account type;  e.g. I would expect 
that a "sepa" account type could be targeted in various ways (e.g. direct 
instruction to my bank, or by a CHAPS transfer instruction to my bank, or by an 
instruction to some third party payment provisioning service, or...)

   [5] https://tools.ietf.org/html/draft-dold-payto-01#section-9


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

I don't really know where to start here.  Getting confirmation is clearly pretty 
important.   I'm not a security expert, but it seems to me that this proposal 
needs, and has not yet received, some serious scrutiny by such.

But, for example, if the ultimate intent is to activate some third party 
application to handle the payment, then it seems to me that the activator ought 
to be pretty damn sure that the right application is being activated.  I can 
imagine some pretty tricky phishing scenarios might be constructed around this.

OTOH, if the identified resource is framed as something like a pro-forma 
invoice, or a request for payment, then the onus for what one does with it is 
shifted to the application.

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

[...] (response moved to top)

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

I'm not really seeing what security concerns (other than "get user confirmation 
first") are being addressed by payto: that could not be addressed by a more 
generic application invocation mechanism.  And a generic app mechanism would 
surely be just as applicable to non-Web contexts as payto: would be.

(Your comment about non-app scenarios is puzzling to me - I struggle to see why 
a URI is useful in situations where there isn't some "web" or "app"-like notion 
in play.)

...

I'll finish by suggesting an alternative approach to payment that I believe 
would play better in Web contexts.  (I don't know about the non-web contexts you 
envisage, so I can't say how it might apply to them).

1. Starting point is a URI that identifies a "payment request".  It could use 
*any* URI scheme (maybe even a payto:).

2. Dereference the payment request to get a representation of it.  The 
representation would be associated with a Content-type which would in turn 
indicate how the request could be handled.  Different payment mechanisms would 
correspond to different content-types.

3. Invoke the appropriate content handler to do something with the payment request.

I proposing this, I note that the intent of the "payto:" scheme might be viewed 
as a way to *represent* payment requests.  If that is the intent, we already 
have a URI scheme that can do that (given an appropriate MIME content-type): it 
is "data:".

So I'm wondering if the push to define a a URI scheme might be more usefully 
directed to defining an suitable content-type?

Maybe there is some reason this doesn't work for you, but I can't see from the 
payto: scheme as described what that might be.  Which brings me back to my very 
first comment: "I'm struggling to understand what this idea gains from being a URI".

Regards,

#g
--