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

[Graham Klyne <[e-mail]>]

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:
> 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
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>