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

From: Florian Dold <[email-masked]>
Date: Wed, 11 Apr 2018 00:44:28 +0200

Dear all,

I've submitted a new version of the payto URI scheme draft.

https://datatracker.ietf.org/doc/draft-dold-payto/

The goal of payto:// is to designate payment methods, similar in spirit
to how one would designate electronic mail addresses with the mailto URI
scheme.

Here are the responses and major changes from feedback to the previous
draft that was posted here for review quite some time ago:

Thanks to a suggestion from Eric Wilde, payment methods are now to be
managed in an IANA registry instead of a fixed list within the
specification.

I do not think that currency and amount should be specified in a
separate option.  Separating them would make it look like a payto URI
which only specifies the "amount" option but not the "currency" option
is meaningful.  Since many payment systems support multiple currencies,
the notion of wanting to pay "100" without a currency to some account
creates ambiguity and can be confusing.  One might argue though that
it's possible to require a "currency" option to be present if an
"amount" is specified, which simplifies parsing for consumers of these
URIs, but this also makes them longer and arguably less readable.  I'd
appreciate more feedback here.

David Nicol asked a while back on this list whether we should support
multiple currencies or even a notion of shopping carts.  Since payto://
is intended to address existing payment methods, it is unlikely that
these concepts translate well to them.  Thus I think that the
specification should address the lowest common denominator of payment
systems.  That is also the reason for having a free form "message" field
(intended to be read by humans) that might be changed (encoding / letter
substitution, upper/lower case) and a more limited "instruction" field
that must be preserved verbatim.  These kinds of limitations are common.

These higher level aspects of payments (related to cart management,
shipping addresses, payment method selection and so on) are also already
being addressed by other standards, such as the W3C's Web Payment
Working group.

Best regards,
Florian

---

From: Graham Klyne <[email-masked]>
Date: Wed, 11 Apr 2018 08:45:02 +0100

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*?

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

(Concerning the comparison with mailto: I have similar concerns with mailto:, 
but history.  But at least it's generally clear how a mailto: URI should be 
processed when dereferenced (e.g, clicked on in a browser); I can rationalize 
mailto: to myself by considering that it identifies an Internet email 
composition resource, in a similar way that http: URIs can be used to represent 
web forms.)

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

The security considerations seem a bit thin to me, for something as security 
critical as making payments.

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

#g
--

On 10/04/2018 23:44, Florian Dold wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Florian Dold <[email-masked]>
Date: Wed, 11 Apr 2018 13:21:27 +0200

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

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

---

From: Adrian Hope-Bailie <[email-masked]>
Date: Wed, 11 Apr 2018 09:39:17 -0700

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/

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.

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

Perhaps we can adopt the same payment method registry?

Finally, I'd like to make you aware of some related work we're doing in the
Interledger community.

1. Payment Pointers

https://interledger.org/rfcs/0026-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.

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:
https://interledger.org/rfcs/0015-ilp-addresses/

---

From: Larry Masinter <[email-masked]>
Date: Wed, 11 Apr 2018 16:42:33 +0000

https://www.w3.org/TR/payment-method-id/
https://www.w3.org/TR/payment-request/ 
and other specs from W3C Payment working group
seem to cover what you're trying to do, and
the work is much further along.

Larry
--
http://LarryMasinter.net

---

From: Florian Dold <[email-masked]>
Date: Wed, 11 Apr 2018 20:11:35 +0200

On 04/11/2018 06:39 PM, Adrian Hope-Bailie wrote:
> How should userinfo and port data in the authority be interpreted in
> this scheme? Are they allowed at all?

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.

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

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
> 
> https://interledger.org/rfcs/0026-payment-pointers/>
> I don't entirely agree with your analogy between payto and mailto which
> is why we invented payment pointers.
> 
> Email addresses on their own are very recognizable as such so the URI
> for is only useful in machine-read contexts.
> 
> 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.

> The authority would be an ILP Address as defined
> in: https://interledger.org/rfcs/0015-ilp-addresses/

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

Thanks for these interesting points!

Florian

---

From: Florian Dold <[email-masked]>
Date: Wed, 11 Apr 2018 20:39:40 +0200

I am aware of the work done by the W3C's Web Payments Working Group, and
payto is orthogonal/complementary to these specifications.

The Payment Request API (https://www.w3.org/TR/payment-request/) is a
relatively high-level JavaScript API that deals with concerns such as
line items for shopping cards, selection of payment methods, and
management of shipping address information.  All of this is completely
specific to Web browsers.

The Payment Method Identifiers spec
(https://www.w3.org/TR/payment-request/) only allows https-based payment
URLs and the "basic-card" method.

As suggested in my response to Adrian, payto URIs could be used as
another type of payment method identifier, if the WPWGs spec allows them
in addition to https URIs in the future.

There is nothing in these two existing specifications that would provide
or replace the intended usage of payto URIs, which is to uniformly
address destinations for payments (and optionally some parameters of the
payment such as the amount, sender's name or processing instructions)
across different payment systems.

Best,
Florian

---

From: Graham Klyne <[email-masked]>
Date: Thu, 12 Apr 2018 11:54:48 +0100

Hi,

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

 > 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

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

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

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

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

> 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

> inherent to the specific payment system, and would be out of scope for

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.

>> resource representation).

[...] (response moved to top)

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

---

From: Florian Dold <[email-masked]>
Date: Thu, 12 Apr 2018 16:31:04 +0200

On 4/12/2018 12:54 PM, Graham Klyne wrote:
> 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
> 
> 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).

Thank you for that suggestion! "Pro forma invoice" is indeed very close
to the intention of payto.  I'm worried, however, that it might be a bit
too restrictive, since "pro forma invoice" implies a fixed price and
something that's agreed upon.

One use case on the Web might be a donation link. Let's say I'm running
a charity and want to accept bank transfers to a SEPA bank account.
With payto, I'd include a link

 <a href="payto://sepa/FR-CHARITY-DONATION-ACCOUNT?message=Donation">
   Donate via SEPA transfer
 </a>

In this case there would be no fixed amount, in some cases there might
not even be a fixed message.

I think "a partially filled out transfer form" would describe best what
a payto URI actually identifies.

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

Further using the analogy of a partially filled out transfer form (where
only the receiver and type of payment is mandatory), a payto URI would
provide an encoding of exactly that resource.

As shown by the example above as well as many other cases (such as
having clickable links in text messages or emails) there is utility in
encoding this resource as a URI.

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

I completely agree with your concern, and I do think that payto URIs are
meaningful and consistent if used on the Web, if the default operation
is defined as invoking a dispatcher to a payment handler.

payto URIs with certain payment methods (or "target account types" if
you prefer) can be handled entirely in the browser, by "Payment
Handlers" that use the same machinery as the W3C's Web Payment Working
Group defines.

For other types, processing must be dispatched to another application,
such as your bank's banking application for SEPA payments.

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

It depends on the platform.  Android specifically allows applications to
install domain-based handlers for all URI schemes.

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

Yes, I think "Payment target account type" might a better name, and it
also would not clash with the W3C's slightly different concept of
"Payment Method Identifiers".

> 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.
> 
> 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.
> 
> invoice, or a request for payment, then the onus for what one does with
> it is shifted to the application.

To me it seems that the dangers of phishing with payto URIs are no
different from e.g. https URIs.

The only additional danger I see is that payto URIs can invoke your
banking application, and these applications must take care to consider
payto URIs as potentially untrusted and adversarial input.  Furthermore,
invoking payto URIs should not result in any other state change or
action within the banking applications other than showing this
(partially) pre-filled transfer form.

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

"Application invocation" does not capture the intention of payto URIs,
if seen as a resource that represents a partial transfer form.

Regarding security, the capability to invoke applications generically is
certainly more dangerous than being only allowed to invoke applications
registered as payment handlers.

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

What I meant to say was that using the URI syntax to represent
destinations for payments across different payment systems is also
useful for applications outside the Web, as it would be a standardized
format.

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

What you're describing sounds similar to Payment Pointers
(https://interledger.org/rfcs/0026-payment-pointers).

It is an orthogonal, higher-level concept.  Important use cases are not
covered by it.  If I want to include my SEPA (or some other
existing/legacy payment system) donation link in an electronic document,
a text message, Web site or email, I can't do this with Payment Pointers
unless I first establish this resource than can be dereferenced.

Using data URIs would make many other existing schemes "obsolete" (such
as "geo:", which could easily represented by data).  Using data: for
everything would obscure intent, and results in ugly, unreadable URIs,
which is especially bad when directly visible to the user.

I'd say that more users can tell what a "payto" URI represents when they
receive it via a text message, than an opaque "data" URI that could mean
pretty much anything.

Best,
Florian

---

From: Larry Masinter <[email-masked]>
Date: Fri, 13 Apr 2018 05:08:15 +0000

*   I am aware of the work done by the W3C's Web Payments Working Group, and
payto is orthogonal/complementary to these specifications.

The specs may be complementary but I think the drafts should coordinate; your messages pointed out the areas of overlap.

WebPayments is far along in implementation, testing and deployment.

https://www.thepaypers.com/cross-border-ecommerce has an interesting survey of payment methods around the world. Just sampling the Preferred Payment Methods and Payment Service Providers gives some indication of the complexity. Each payment processor has a complex API for invoking a payment of which the payto URI seems to want to supply some of the parameters?

Finally, I think it’s a mistake to use // or / in URIs that are not hierarchical, and to use //  / around something that isn’t a host name.

Larry
--
http://LarryMasinter.net

---

From: Larry Masinter <[email-masked]>
Date: Fri, 13 Apr 2018 05:13:15 +0000

Sorry, keyboarding problem

  *   There is nothing in these two existing specifications [web payment drafts]  that would provide

https://www.thepaypers.com/cross-border-ecommerce has an interesting survey of payment methods around the world. Just sampling the Preferred Payment Methods and Payment Service Providers gives some indication of the complexity. Each payment processor has a complex API for invoking a payment of which the payto URI seems to want to supply some of the parameters? You would have to map your components to each.

I think the I18N issues shouldn’t be ignored, especially for things like names of users.

Larry
--
http://LarryMasinter.net

---

From: Florian Dold <[email-masked]>
Date: Fri, 13 Apr 2018 09:51:56 +0200

On 04/13/2018 07:13 AM, Larry Masinter wrote:>
https://www.thepaypers.com/cross-border-ecommerce has an interesting
> survey of payment methods around the world. Just sampling the Preferred
> Payment Methods and Payment Service Providers gives some indication of
> the complexity. Each payment processor has a complex API for invoking a
> payment of which the payto URI seems to want to supply some of the
> parameters? You would have to map your components to each.

Thank you for pointing out that resource.

Payto is not intended as a generic API for payment systems, this is what
the Payment Request API already provides to some degree.  There is no
need to model the API of these payment systems.

Payto only represents the details for a payment to a certain target
account, with standardized names for the most common denominator of
parameters (though specific target account types can accept additional
parameters).  Some payment systems (such as credit cards) do not
directly expose this concept of transferring funds to a target account,
and payto does not apply to them.

Obviously the concept of "here is my credit card information, please
initiate a payment to my credit card" does not make sense.

> WebPayments is far along in implementation, testing and deployment.

There is the concept of "Payment Method Identifier" in WebPayments, but
as discussed in another thread, in payto it should be called "Target
Account Type" instead.

The W3C's Payment Method Identifier spec currently only defines one
fixed payment method.  As mentioned in the discussion with Adrian, a
payto URI could be used as a Payment Method Identifier in the future.

The existing "basic-card" and https-based Payment Method Identifiers
can't be replaced with a payto URI, for reasons stated earlier.

What exactly is the overlap between the Payment Request API and payto
URIs that you'd like to see addressed?

> I think the I18N issues shouldn’t be ignored, especially for things like

Could you point out internationalization issues you see that are not
already addressed by URL encoding?

Some payment systems use a "lossy encoding" for some strings, this issue
is already addressed here:
https://tools.ietf.org/html/draft-dold-payto-01#section-6

> Finally, I think it’s a mistake to use // or / in URIs that are not
> hierarchical, and to use //  / around something that isn’t a host name.

Do you have any reason for this other than personal preference?  The
presence of "//" is required for the first component of the URI to be
interpreted as the authority, as opposed to being part of the path.  The
"/" separates the authority from the path.  Quoting RFC3986:

"The generic syntax provides a common means for distinguishing an
authority based on a registered name or server address, along with
optional port and user information."

and

"If a URI contains an authority component, then the path component must
either be empty or begin with a slash ("/") character."

The authority does not need to be a hostname, it can also be a
registered name.

There are good reasons to stick to the common syntax of URIs, most
importantly to avoid the need for custom parsers.

Best,
Florian

---

From: Larry Masinter <[email-masked]>
Date: Fri, 13 Apr 2018 20:34:25 +0000

On // and /: 

RFC 7595 section 3.2:

   Schemes that are not intended for use with relative URIs SHOULD avoid
   use of the forward slash "/" character in order to avoid unintended
   processing, such as resolution of "." and ".." (dot segments).

   Schemes SHOULD avoid improper use of "//".  The use of double slashes
   in the first part of a URI is not a stylistic indicator that what
   follows is a URI: double slashes are intended for use ONLY when the
   syntax of the <scheme-specific-part> contains a hierarchical
   structure.  In URIs from such schemes, the use of double slashes
   indicates that what follows is the top hierarchical element for a
   naming authority (Section 3.2 of RFC 3986 has more details).  Schemes
   that do not contain a conformant hierarchical structure in their
   <scheme-specific-part> SHOULD NOT use double slashes following the
   "<scheme>:" string.

RFC 7595 Section 3.3

   While URIs might or might not be defined as locators in practice, a
   scheme definition itself MUST be clear as to how it is expected to
   function.  Schemes that are not intended to be used as locators
   SHOULD describe how the resource identified can be determined or
   accessed by software that obtains a URI of that scheme.

My point in citing 
    https://www.thepaypers.com/cross-border-ecommerce 
was to note that if you DID want to use a banking payment processor,
there isn't sufficient clarity as to how it is expected to function.

---

From: Florian Dold <[email-masked]>
Date: Sat, 14 Apr 2018 03:51:34 +0200

>    <scheme-specific-part> SHOULD NOT use double slashes following the

I do not see any inherent conflict here, since the
<scheme-specific-part> indeed contains a hierarchy, though often of
depth exactly two.

Some (currently imaginary) payment system's account identifier could
contain, for example, country and state as part of the hierarchical
identifier:

  payto://futurebank/usa/alabama/joe-exampleguy?amount=USD:50.00

Here "futurebank" is the target account type, and
"/usa/alabama/joe-exampleguy" is the account identifier.

(and further hierarchical sub-elements could be different accounts held
by the same identity, etc.)

Maybe the spec should stress that <scheme-specific-part> indeed contains
a hierarchy, and that a verbatim "/" in the account identifier would
have to be encoded (as %2F)?

>    accessed by software that obtains a URI of that scheme.

Yes, I agree that this should be more clearly explained in the spec.

The resource represented by a payto URI is a partially filled-out pro
forma invoice, with the (mandatory) beneficiary identified by the
authority and path and other (optional) details (such as amount, debitor
name, etc.) given in the query part.

(Of course "pro forma invoice" is a much broader concept than what payto
provides, but so far we haven't found terminology that is a better match
yet.)

And payto URIs are handled by invoking the application registered with
the target account type ("payment method" in the old terminology).
Typically this application can settle/pay an invoice to such a target
account.

(The application might be part of the browser itself, for example when
an appropriate Web Payment handler is available.)

Best,
Florian

---

From: Larry Masinter <[email-masked]>
Date: Fri, 13 Apr 2018 22:46:29 -0700

On // and /.

The definition of "payto" is a good example of WHY RFC 7595 gives the advice about avoiding them.
You say you want to use "standard libraries" without writing a  custom parser. But there is no standard library, there are lots of little URI-parsing hacks, and there are likely many heuristic libraries that do things you might not want (like case-folding or normalizing the authority name or turning // or /./ or /xx/../ into / because they worked mostly and it mostly doesn't matter. Which is OK in most cases.

Saying a data structure is "hierarchical" does not apply to one that is always a hierarchy of exactly two levels, without any applications that would use the hierarchical nature.

Your registry of payment names may need a dispute process -- what if two different payment processors both claim to "own" (and release incompatible additions to) a widely used payment type.

I think you might relook at Graham's advice to consider an application/payto+json MIME type and schema instead; you'll get parsers and validators and other goodies, easy integration and extensibility. MIME type are easy and a schema is easier. If you need to stuff it in a URI use data:.

A lot of work went into RFC 7595/BCP 35, and I wish you would take it more seriously, rather than try to lawyer through.

Larry
--
http://LarryMasinter.net

---

From: Florian Dold <[email-masked]>
Date: Sat, 14 Apr 2018 13:49:27 +0200

> Saying a data structure is "hierarchical" does not apply to one that is always a hierarchy of exactly two levels, without any applications that would use the hierarchical nature.

Neither the hierarchical processing nor case folding within the
authority component causes any issues for payto.  That can of course be
emphasized in the spec.

Quoting  RFC 7595:

"New schemes SHOULD reuse the common URI components of [RFC3986] for
the definition of hierarchical naming schemes.  If there is a strong
reason for a scheme not to use the hierarchical syntax, then the new
scheme definition SHOULD follow the syntax of similar previously
registered schemes."

You seem to be advocating for the invention of additional syntax,
instead of trying to map to the generic syntax of URIs if possible.  Are
you suggesting that the generic syntax of URIs (RFC 3986, Section 3) is
not well defined?

And indeed I do not follow the argument that a hierarchy that is usually
of depth two should not be mapped to hierarchical URIs.  I'd agree with
you if we were trying to encode something like unordered key-value pairs
in the path, but we're not.

Having the "//" in payto URIs means that the matching of payment
handlers can be done by simply looking at the authority part of a URI,
instead of picking apart the path.  This would make deployment on
systems that already allow matching on the authority (but not picking
apart the path) easier. Android's intent registration mechanism is an
example where this applies.

> Your registry of payment names may need a dispute process -- what if two different payment processors both claim to "own" (and release incompatible additions to) a widely used payment type.

This is precisely why the spec defines an IANA registry.

> I think you might relook at Graham's advice to consider an application/payto+json MIME type and schema instead; you'll get parsers and validators and other goodies, easy integration and extensibili…

How does this address the need to send somebody a link (e.g. through
email, within a document, on a website, in a text message) that
initiates a payment through an existing, traditional banking system?

This is not addressed by the Web Payment APIs.  These APIs are there to
make the checkout flow on a merchant's website easier.

If I want to make a bank transfer to somebody's account, the only way to
initiate this right now would be to open a banking app/site manually and
enter all this information manually (or copy&paste it).  That's
precisely what payto wants to solve, and it can only do so by being a URI.

(Graham's suggestion of using app invocation links doesn't work either;
what's the "app" for SEPA or ACH account payments?)

> A lot of work went into RFC 7595/BCP 35, and I wish you would take it more seriously, rather than try to lawyer through.

Then could you please give some constructive advice on what changes
you'd want to see in the spec to be conformant with RFC 7595/BCP 35?  So
far it seems to me you're mainly arguing from the position of "this
shouldn't even exist as a URI", but maybe I'm misinterpreting what you said.

Florian