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_Priorities
>
>> 
> 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 Wednesday, 20 May 2015 03:32:23 UTC