Re: [payment agent] Payment architecture feature priorities

On 2015-05-26 13:42, Adrian Hope-Bailie wrote:
> I know the idea of URL protocol handlers has been frowned  upon in
 > the past but I maintain they may have great utility in solving this problem.
>
> Today, many native apps are launched from the Web context in this way by
 > registering a proprietary URL protocol with the browser/OS.
>
> Where more than one native app has registered itself for the same protocol
 > or action the user is presented with a choice of app to use to perform the
 > action they have initiated.
>
> If we can standardise a payment URL protocol that is intended to initiate
 > payment handling then we potentially solve the issue.
> The transition from Web context to native wallet is done via a URL which:
>
>  1. Prompts the user to choose which native wallet to use
>  2. Passes the wallet context from the Web in the form of a URL that should:
>      1. Point to some linked-data document which current transaction context
>      2. Pass any additional variables in the query string.

This is a technical issue that will be difficult to resolve since no method
for invoking native applications from the web has received "standards" status.

I have exploited the mentioned URL protocol scheme in
https://play.google.com/store/apps/details?id=org.webpki.mobile.android
so I'm pretty familiar with the pros and [numerous] cons of this scheme.

Another popular solution is referring to services running on "localhost" which appears
to have certain issues: https://code.google.com/p/chromium/issues/detail?id=378566#c78

The most recent addition to this troubled space is Google's Native Messaging:
http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/

IMO, none of these schemes are satisfactory as a foundation for a *standard*
which is why I have invested considerable time in defining such a system.
I'm currently in a very early phase of concept verification.

Anders




>
>
> On 23 May 2015 at 15:29, <Joerg.Heuer@telekom.de <mailto:Joerg.Heuer@telekom.de>> wrote:
>
>     Hello Manu!
>     A few comments below: JH>
>
>     -----Original Message-----
>     From: Manu Sporny [mailto:msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>]
>     Sent: Freitag, 22. Mai 2015 05:06
>     To: public-webpayments-ig@w3.org <mailto:public-webpayments-ig@w3.org>
>     Subject: Re: [payment agent] Payment architecture feature priorities
>
>     On 05/21/2015 11:31 AM, Joerg.Heuer@telekom.de <mailto:Joerg.Heuer@telekom.de> wrote:
>     > The problem described below is analog to the use of the NFC device -
>     > or more exactly that of a specific 'aID' via NFC. There can only be
>     > one handler for a specific aID on a given device. The choice is
>     > usually made available to the user by a 'wallet' application which has
>     > the right to 'talk' to the device. With HCE Google demonstrated that
>     > the stringent connection between NFC and SE is 'loosened' by the
>     > operating system. Still, combinations of NFC and SE are not
>     > compromised in their integrity, HCE just offered more choice.
>
>     +1
>
>     > Assuming there's one 'wallet app' for all isn't a bad starting point
>     > to give users best control and transparency.
>
>     I think that's a very dangerous starting position for anyone that is not in control of the OS platform (which is most of us).
>
>     History has demonstrated that the market doesn't always favor customer choice and transparency.
>     JH> I see your point. Like in the NFC-world, we'd thus need to differentiate on the level of supported 'schemas'. If the 'request for payment' by the payee' contains information of the schemas supported (I think we agreed on this already) then we'd require a mechanism which allows to either register for all such request - or a larger set of them (aka one or more 'wallets') or maybe even a single one (e.g. a specific payment app running the one schema the user wants to use). I'd propose a hierarchy of such 'request routing' logic, but from the standards perspective, I'd say we need to ask for requests that provide information which allows such 'routing' on the user's behalf. (Whether it's done by the browser, the OS or a wallet.)
>     Does that sound okay?
>
>     > That said, I believe that we don't have to solve this problem first.
>
>     Agreed.
>
>     > We will be able to standardize and recommend along one concept for
>     > communicating with one app on the device. If the operating system gets
>     > in between and 'forks' communication with several apps our protocols
>     > shouldn't falter, but support it. Nothing wrong in that - or is it?
>
>     I agree wrt. 'forking communication'. That's what W3C should be striving for from day one, and until that happens, I'm wary of putting the minority of organizations this group in a very favorable competitive position vs. the other members in the group.
>     JH> above proposal should do the work, right?
>
>     Here's a counter-proposal:
>
>     For version 1.0, cloud-only wallets. This enables everyone to compete on a level playing field. Any one of us should be able to launch a cloud wallet.
>     JH> I'd rather not limit ourselves to 'cloud wallets', because we will likely miss the opportunities on the device then. From an architectural point of view, we should be able to work with the capabilities of a platform which can either be a web server or a service on the user's device.
>
>     Once we figure out how to create an OS-level message bus that enables a level playing field w/ native-app/SE wallets, we can enable that as soon as it is available.
>     JH> I think we've already designed our approach that way, so we can make use of either platform type. We can always provide support on that basis.
>
>     This does two things:
>
>     1. Starts all of us on a level playing field (cloud-only wallets).
>     2. Progressively enhances the platform when we're sure we've created an
>         ecosystem that's going to support fair competition.
>     JH> Okay, but let's already take into account what might go beyond the 'cloud'-option. I am willing to act as a straw man to check for the 'user device compatibility' of whatever architecture.
>
>     -- manu
>
>     --
>     Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc.
>     blog: The Marathonic Dawn of Web Payments http://manu.sporny.org/2014/dawn-of-web-payments/
>
>

Received on Tuesday, 26 May 2015 12:31:33 UTC