Re: Spec/vision Clarification

On 2015-11-13 09:00, Adrian Hope-Bailie wrote:
> The purpose of the standard data, which would include more than price, is to help the component that helps the user select a payment app, filter which apps are able to process the payment.
>
> One can imagine having a bunch of payment apps installed which support different payment methods and may have other constraints on the payments they are able to process.
>
> It should be possible for the mediator (likely the browser) to (possibly with user interaction) be able to narrow the list down to a single payment app without needing to probe each one to find out if it is capable of processing the requested payment.

This is all good with one important exception: DFS (Discovery, Filtering and Selection) can without doubt benefit from a standardized solution, while the next step ("Execution"), most likely would not for reasons like the one I mentioned.

BTW, the design of the mediator is a huge issue, particularly if it depends on "browser chrome" (=built-in static UI code).

AFAICT, a light-weight DFS scheme could have many other uses as well, like login to e-governments and on-line banks who quite often offer a range of different alternatives that may also provide the user with different "power" depending on the security level of the selected method.  In the same way as for payments, I don't see any point in mixing DFS with the actual login.

Cheers,
Anders

>
> On 13 November 2015 at 09:09, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     Hi Payment-Lovers,
>
>     The JSONesque example below shows a very simple version of a possible Payment Request a la W3C Web Payments:
>
>     "paymentRequest":
>        {
>           "amount": "10.5",
>           "currency": "USD",
>        }
>
>     However, assuming that the request is targeting a system along the lines of my published PoC [1], the message also has to hold native payment request data like this:
>
>     "paymentRequest":
>        {
>           "amount": "10.5",
>           "currency": "USD",
>           "customData": <native payment request data>
>        }
>
>     The question that comes to my mind is simply: What purpose does the W3C Payment Request have in this particular case?
>
>     Is the idea that "Wallets" like in the PoC, should use "amount" etc. from the W3C Payment Request and thus refrain from defining such data in the native version? Unfortunately, there is no alternative for the PoC since the native part is signed (identifying a payee payment network member) and supposed to be countersigned by the user in order to create a fully end-to-end-secured solution using "stacked" signatures quite similar to what Cyril Vignet showed in his SCAI paper.
>
>     Cheers,
>     Anders
>     1] https://test.webpki.org/webpay-merchant
>
>
>
>

Received on Friday, 13 November 2015 09:43:30 UTC