W3C home > Mailing lists > Public > public-credentials@w3.org > June 2015

Re: Web2Native Bridge emulator

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Fri, 26 Jun 2015 22:53:10 +0200
To: Adrian Hope-Bailie <adrian@hopebailie.com>
Cc: UniDyne <unidyne@gmail.com>, W3C Credentials Community Group <public-credentials@w3.org>, Web Payments CG <public-webpayments@w3.org>
Message-ID: <558DBBB6.2080105@gmail.com>
On 2015-06-26 21:44, Adrian Hope-Bailie wrote:
>>  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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:24 UTC