Re: QR-code for bringing new NFC/BLE payments up to speed?

On 2016-09-12 12:26, Adrian Hope-Bailie wrote:
> There would certainly be value in encoding a payment request in
> a QR code, perhaps it is sufficient to have the QR code simply
 > link to the request in the form of a document?

Since payment requests can be pretty voluminous, the latter solution
is the one I have settled on.

A possible (not yet tested step...), is replacing the current HTTP scheme
with WebSockets [1] for merchant communication to enable "wallets" like the
Personal Payment Terminal [2] to only depend on asynchronous, bidirectional,
"channels" exchanging serialized JSON objects, regardless if they are invoked
from a Web page using the Web2Native Bridge [3], are manually invoked using a
QR-scan (on the Web or elsewhere), or (some day) are invoked through an enhanced
NFC/BLE interface.

The channel approach may also prove to be a viable alternative to REST-based
schemes since it aligns better with a SPA [4] when used on the Web, not to
mention the difficulties dealing with REST signatures [5].

The goal is streamlining the architecture including server authentication
in order to hopefully easier reach the critical mass needed for universality.

I hope this message can serve as "prior art" in case any of this would be novel
because I simply can't motivate myself writing yet another defensive publication [6].

Anders

1] https://en.wikipedia.org/wiki/WebSocket
2] https://cyberphone.github.io/doc/saturn/ui-demo/personalpaymentterminal.html
3] https://github.com/cyberphone/web2native-bridge#web2native-bridge---uniting-the-web-and-app-worlds
4] https://en.wikipedia.org/wiki/Single-page_application
5] https://www.ietf.org/mail-archive/web/jose/current/msg05553.html
6] http://www.defensivepublications.org/

>
> On 9 September 2016 at 17:57, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     Hi Payment Enthusiasts,
>
>     If somebody wanted to create a new local payment system that doesn't build on EMV [1], it would likely be met with considerable resistance.
>
>     Due to that, I have begun looking into using QR-code [2] as a way to "bootstrap" new local payment systems because the very same system can (if properly designed), also be used on the Web using a separate "Wallet".
>
>     FWIW, I can demo the latter to interested parties during TPAC (Thursday+Friday).
>
>     Anders
>
>     1] Why would anybody in their right mind consider not using EMV? Because EMV is a scheme designed for primitive cards not having UIs, high-performance CPUs, excellent communication abilities, etc.
>
>     2] Eventually QR should be replaced by NFC/BLE but waiting for this to happen is like waiting for Godot.  With already established QR-based systems on the market, NFC/BLE can be reduced to a local "upgrade" potentially having zero impact on the rest of the payment infrastructure.
>
>

Received on Monday, 12 September 2016 13:13:31 UTC