RE: [payment agent] Payment architecture feature priorities

Manu, Dave,

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.

 Assuming there's one 'wallet app' for all isn't a bad starting point to give users best control and transparency. It would be up to the operating system to offer more configuration options to fork requests to different 'wallet's or specific apps. I would say, that will happen if the 'wallets' fail to support the user effectively by e.g. not being open to all the choices they want.

That said, I believe that we don't have to solve this problem first. 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?

Cheers,
 Jörg

-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com] 
Sent: Mittwoch, 20. Mai 2015 05:32
To: Dave Raggett
Cc: Web Payments IG
Subject: Re: [payment agent] Payment architecture feature priorities

On 04/24/2015 05:33 AM, Dave Raggett wrote:
>> https://www.w3.org/Payments/IG/wiki/Payment_Architecture_Feature_Prio

>> rities
>
>> 
> One suggestion is not to rule out local apps for the initial charter. 
> W3C is seeking to close the gap with native, but this is a long term 
> goal, and in the short term we should acknowledge that developers are 
> likely to be attracted to native apps due to the richer capabilities 
> available to native apps compared with web apps.
> On both Android and iOS it is already possible to transfer from a web 
> app to a native app. However, I am not clear on how a result can be 
> returned to the originating web app.  This is not an insuperable 
> barrier, as we could ensure that the payment request passes a URI to 
> deliver the response to. The web app would then wait for a 
> notification from the server.

The problem has to do with how one figures out /which/ wallet app (among
many) to pass the payment invoice to. That requires coordination w/ browser vendors and OS vendors, and that'll take a non-trivial amount of time for W3C to coordinate. In the worst case, it could block the work if we're hoping to have it resolved in a v1 timeframe.

Native apps are vitally important. However, the problem isn't the web-to-native-and-back routing. The problem is figuring out which wallet app to send the payment invoice to as the user has to choose it from w/in the browser context or the OS context. It's a technically simple solution fraught w/ a politically complicated landscape.

Perhaps there is a technical solution to this already, but I'm unaware of one that would solve the problem above in the next 2-3 years.

> In respect to authentication for cloud based instruments, I am 
> expecting W3C to launch a new group focusing on strong authentication.  
> Depending upon how far this has got, we may be able to cite a 
> dependency on that group from our charter.

Yes, hardware-based authentication is important, but it shouldn't be critical path. Authentication to access payment instruments is a value-add that payment service providers can use to differentiate themselves. That work can happen in parallel, but you're right, we should cite them as "should coordinate with ...".

> In respect to the requirement for a digital signature on the payment 
> request (aka invoice in your terminology), I suspect that this may be 
> dependent on specific payment instruments, and would like to 
> understand this better. For instance, to validate a digital signature 
> you need to have a pre-existing trust relationship.
> 
> I question whether the new WG would need to standardise the proof of 
> payment as this would normally be defined by the standards applicable 
> to each payment instrument. The same applies to the routing of 
> requests from merchant sites to payment service providers.

Many payment instruments in use today have no verifiable proof-of-payment mechanism. It's just assumed that the payment network you're connected to is secure and the party you're talking to is trustworthy. Thus, we can't do push-payments w/o digital signatures on proof of payment.

-- 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 Thursday, 21 May 2015 15:45:06 UTC