Payment Method Identifier Registry should have oversight / formal structure about webpayments

[ianbjacobs]

I suggest that we NOT maintain a registry of URIs.
If our identifier spec includes short strings, then I think those should be defined in the WG spec (with appropriate references to what they mean). For flexibility, the editor's draft of the spec can be updated
by the WG to add "draft" short strings.

Ian

[halindrome]

Why would you not want a registry of URIs? Discovery is an important part
of the way the internet works. Having a well-defined way for applications
to learn is critical to developer's ability to dynamically extend their
applications. Otherwise you are doomed to hard-code, and you end up only
using the things that everyone knows about. That sort of thinking
discourages growth.

On Mon, Dec 7, 2015 at 8:46 AM, ianbjacobs [email protected] wrote:

I suggest that we NOT maintain a registry of URIs.
If our identifier spec includes short strings, then I think those should
be defined in the WG spec (with appropriate references to what they mean).
For flexibility, the editor's draft of the spec can be updated
by the WG to add "draft" short strings.

Ian

—
Reply to this email directly or view it on GitHub
#25 (comment).

Shane McCarron
[email protected]

[ianbjacobs]

Why would you not want a registry of URIs?

The Web is the registry. People should be able to mint URIs and use them without our involvement.

Ian

[halindrome]

A URI is no guarantee of interoperability. Nor is there any way to
discover a newly minted URI without some sort of (distributed) registry. I
am not suggesting that there be any sort of impediment to anyone
registering anything. But just because Bob Pay has a new Bob Card at
http://bob.example.com/bobcard/payment-method.json doesn't mean my
application is going to magically learn about it. On the other hand, if my
application looks to a registry from time to time to see if there are new
methods available, it can then offer that method. When I get my new Bob
Pay card I can add it into my wallet (or whatever we are calling that now)
because my wallet application has learned about it and its characteristics
from the registry. Without that, the wallet application needs to get
updated - and probably will only do so when enough people complain about
not being able to add Bob Pay to their wallet. That's just silly.

On Mon, Dec 7, 2015 at 8:59 AM, ianbjacobs [email protected] wrote:

Why would you not want a registry of URIs?

The Web is the registry. People should be able to mint URIs and use them
without our involvement.

Ian

—
Reply to this email directly or view it on GitHub
#25 (comment).

Shane McCarron
[email protected]

[ianbjacobs]

A URI is no guarantee of interoperability.

Agreed. Registry or not.

Nor is there any way to discover a newly minted URI without some sort of (distributed) registry.

• Search engines.
• Marketing by minters

Ian

[zkoch]

I agree with Ian. The Web is the registry for URIs.

[halindrome]

On Mon, Dec 7, 2015 at 9:25 AM, ianbjacobs [email protected] wrote:

A URI is no guarantee of interoperability.

Agreed. Registry or not.

A Registry with URIs that point to content in well defined, extensible
format(s) is the key to discoverable interoperability. RDFa, JSON-LD, XML
are all fine ways to capture specific basic characteristics of a payment
method.

Nor is there any way to discover a newly minted URI without some sort of
(distributed) registry.

• Search engines.
• Marketing by minters

Really? I mean, of course, but that's the opposite of the direction that
we should be going. Those are tools for end users. Those are not suitable
tools for an application to use, nor are they the method we should be
recommending to application developers. Can you see us saying "NOTE:
Wallet developers SHOULD periodically do a comprehensive web search to
discover new, interesting payment methods in which their users may be
interested."? Or "NOTE: Wallet developers SHOULD be sure to support
payment methods when they see excellent advertisements for them during the
Super Bowl."? Surely not.

Shane McCarron
[email protected]

[ianbjacobs]

Can you see us saying "NOTE: Wallet developers SHOULD periodically do a comprehensive web
search to discover new, interesting payment methods in which their users may be interested."?

I don't think wallet developers will hunt around looking for things to support.

Rather, companies will promote their products and it will be an implementation detail what URI (or other string) people should use within the W3C APis to get those products to work.

Then, if you are a wallet developer and want to know how to get FooPayments to work in your wallet, you'll search for FooPayments, and there will be a section for developers that explains what to do.

[halindrome]

And I think that, as a value-add wallet developer, I would prefer to create
a smart wallet that does all sorts of cool stuff with every payment method
out there. And have it dynamically expand its collection. The
intelligence I add to my smart wallet - negotiating with the vendor,
dealing with affinity card information, bartering with the user for access
to their data in exchange for discounts - that's where I want to put my
energy.

If we don't provide this registry, someone else will. Doesn't it behoove
us to ensure that it is done by us, done right, and done in a way that puts
all payment methods on an equal footing?

On Mon, Dec 7, 2015 at 10:44 AM, ianbjacobs [email protected]
wrote:

Can you see us saying "NOTE: Wallet developers SHOULD periodically do a
comprehensive web
search to discover new, interesting payment methods in which their users
may be interested."?

I don't think wallet developers will hunt around looking for things to
support.

Rather, companies will promote their products and it will be an
implementation detail what URI (or other string) people should use within
the W3C APis to get those products to work.

Then, if you are a wallet developer and want to know how to get
FooPayments to work in your wallet, you'll search for FooPayments, and
there will be a section for developers that explains what to do.

—
Reply to this email directly or view it on GitHub
#25 (comment).

Shane McCarron
[email protected]

[ianbjacobs]

And have it dynamically expand its collection.

I'm not sure that use case is part of our current charter.

Ian

[dlongley]

It seems to me that when people go out and get new payment methods/instruments from various websites, those methods/instruments should contain standard, machine-readable, self-describing data. A smart wallet can then make use of that information which will have the affect of "dynamically expanding its collection". The new information can be driven to the wallet via the wallet's users and the wallet can present new features that arise from it.

[webpayments]

… don’t let us put automatisms where they will likely rather scare people!

Marketing payment products has already been invented and we can help it take to the net even easier. No reason to push things to users. Let them chose when they want it…

Cheers,
Jörg

From: ianbjacobs [mailto:[email protected]]
Sent: Montag, 7. Dezember 2015 17:58
To: w3c/webpayments
Subject: Re: [webpayments] Payment Method Identifier Registry should have oversight / formal structure (#25)

And have it dynamically expand its collection.

I'm not sure that use case is part of our current charter.

Ian

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-162591878.

[halindrome]

I don't mind that approach. For me that's as low as the bar should be
though. At least then any "wallet" application can capture the information.

However, I strongly feel that same information should be discoverable by
the app. When I go into "Android Pay" today and tell it I have a whatever
card, I don't need to navigate to the site and somehow pass the information
about how to use that card into the Android Pay app. Android Pay knows
about the card and just deals with it. Similarly it knows about basically
every affinity card I have ever thrown at it (in it's Google Wallet
incarnation). Google has the resources to build all that intelligence into
their app. I am sure that on their back end they have a dereferencing
mapping for all the things they support, so their app can dynamically
expand its collection. Why not afford the little guy (Jim's Smart Wallet
Company) the same benefit by at least permitting Bob Pay to register their
information somewhere that is discoverable? Then Jim's Smart Wallet has a
fighting chance and can compete on features instead of on how many
different payment methods it knows about.

On Mon, Dec 7, 2015 at 11:01 AM, Dave Longley [email protected]
wrote:

It seems to me that when people go out and get new payment
methods/instruments from various websites, those methods/instruments should
contain standard, machine-readable, self-describing data. A smart wallet
can then make use of that information which will have the affect of
"dynamically expanding its collection". The new information can be driven
to the wallet via the wallet's users and the wallet can present new
features that arise from it.

—
Reply to this email directly or view it on GitHub
#25 (comment).

Shane McCarron
[email protected]

[dlongley]

Why not afford the little guy (Jim's Smart Wallet
Company) the same benefit by at least permitting Bob Pay to register their
information somewhere that is discoverable?

If "Bob Pay" includes self-describing, machine-readable information (which may also have links to further information), then when "Bob Pay" is added to the smart wallet, the wallet can figure out how to handle "Bob Pay". I think with that approach, there isn't any need for the wallet to asynchronously/periodically head off to check a registry.

[adrianhopebailie]

I don't think there is a good case for discovery of payment methods. However there may be a case for the discovery of payment apps that support a specific payment method.

i.e. This merchant supports payment via methods A, B and C, where can I find payment apps that support those so I can make a payment?

A payment method is a protocol for executing a payment that is based on the basic request response flows we are standardizing. I expect payment methods to spring up in the millions as payment app developers design ways that they want payments to work and create a agreements with PSPs to process payments in that way. In time there will be a smaller set of widely used methods that will either be controlled by large payment networks or will be open standardised methods that are free for anyone to implement in their apps.

It's not going to be possible for someone to build an intelligent payment app that is able to go out and discover payment methods and then dynamically add support for them. That is, unless they were also able to dynamically add PSP relationships that could process payments using that method.

In some respects this is what Interledger [1] could achieve. A payment app that supports Interledger would either expect the payee to explicitly state they also support Interledger, or they would be constantly looking at the payment paths they have available to them and therefor the payment methods they have available as terminating transfers and advertise these as supported methods.

For example, a merchant may support Bitcoin and VISA debit as payment methods (and have no knowledge of Interledger). If the user has a payment app that can use Interledger to make payments it will query it's available payment paths to see if any can make the necessary Bitcoin and/or VISA debit payment to the merchant.

[1] https://interledger.org

[msporny]

Migrated to w3c/payment-request#11