Re: [payment agent] Payment architecture feature priorities

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.


On 23 May 2015 at 15:29, <Joerg.Heuer@telekom.de> wrote:

> Hello Manu!
> A few comments below: JH>
>
> -----Original Message-----
> From: Manu Sporny [mailto:msporny@digitalbazaar.com]
> Sent: Freitag, 22. Mai 2015 05:06
> To: public-webpayments-ig@w3.org
> Subject: Re: [payment agent] Payment architecture feature priorities
>
> On 05/21/2015 11:31 AM, 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/
>
>