RE: [payment agent] Payment architecture feature priorities

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/

Received on Saturday, 23 May 2015 13:30:07 UTC