Re: [payment agent] Payment architecture feature priorities

On 2015-05-20 05:31, Manu Sporny wrote:
> 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.

Although I do not know this in detail (which is somewhat understandable
since current wallets are proprietary and close sourced), I'm pretty sure
that most of them would need considerable tweaks in order to be usable in
a Web Scenario.


> 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.

Right, what's bothering me is that it *seems* that the Web Payment IG intends to
postpone work (?) in this area which at this stage must be regarded as *pure research*.
This is more or less what happened with the WebCrypto "secondary features":
https://lists.w3.org/Archives/Public/public-identity/2011Nov/0030.html
It turned out that little or no research were carried out during the 3 year "moratorium"
leading to a failed effort and substantial member (and non-member) dismay.

FWIW, I have (after witnessing the Web Crypto debacle) finally given up the idea of creating
specific browser API's for "non-core" stuff like Wallets, Security Elements, Credential Management, etc.:
https://lists.w3.org/Archives/Public/www-tag/2015Apr/0053.html
I don't think the market is interested waiting 3 years for a new single-purpose APIs no matter how good it may be!

U2F is the solution? Saying that without showing (and testing) how is IMO asking for trouble.

Anders


>
>> 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
>

Received on Wednesday, 20 May 2015 05:11:50 UTC