Re: Web2Native Bridge emulator

On 2015-06-26 21:44, Adrian Hope-Bailie wrote:
<snip>
>>  and I don't need to know what technology stack the user has
>>  behind the API to support my request.
>
>     This is not how I intend this system to be used. An application called
>     "com.mybank.pay.v1" would (should) be identical with the respect to the
>     calling Web application on all platforms where it is implemented.
>
>
> Then you addressing a very different use case to the web payments work.

As can be seen in the specification/presentation I practically started with this use case.


> As a merchant looking to call out to a browser API to initiate
 > payment negotiation with my customer I don't expect to know what
 > wallet software he has installed any more than a Web app that is
 > looking for location info should need to know what GPS hardware the user has.

There are no guarantees that all browsers implements a specific API
so what's maybe lacking is a way to see if a certain app is available.

Microsoft still doesn't support the (close to)official WebCrypto API to
take a recent example.


> The generic use case is solved by specific APIs for that use case

Each new API have to be specified, agreed upon and implemented.  This is probably
a 3-year journey if we use WebCrypto as a measuring stick with extremely
limited possibilities adjusting the specification when it finally hits the road.

WPIG has a long way to walk before you hit the API level.  Things may look
quite different when you do :-)


> where the technology stack behind the API (in this case a wallet) is not important.

All approaches would have this quality.


> Why the Web2Native bridge has value for developers looking to solve
 > interop problems that are not yet clearly defined

Supporting iterative/agile design is not to be confused with "unclear".


> and who don't want
 > to be constrained by the browser vendors willingness to implement a new API.

Which probably accounts for 99%.


> That said I'm not sure I see the appeal for a browser vendor of something
 > that is just a new attack vector to have to consider in security analysis.

Any additions to the browser is subject to a deep security analysis.  Since
Google already support Native Messaging we must assume that they indeed have
performed the basics.  Note: I haven't touched the browser code base.

Anders
</snip>

Received on Friday, 26 June 2015 20:53:43 UTC