[Openid-specs-fapi] Google proposal: FIDO/PISP Integration

Anders Rundgren anders.rundgren.net at gmail.com
Tue Apr 14 06:46:42 UTC 2020

On 2020-04-13 06:45, Anders Rundgren wrote:
> https://www.w3.org/2020/02/3p-creds-20200219.pdf

Another way dealing with this scenario could be as follows:
- Bind a FIDO key to the ServiceWorker domain ("boa.com" in the Dirk's presentation)
- Use a ServiceWorker-local UI (https://github.com/adrianhopebailie/modal-window ?) to show Merchant payment requests
- Perform ServiceWorker-local FIDO-assertions based on received payments request data
- Encrypt assertions using a ServiceWorker-local public key where "boa.com" would have the private counterpart
- Send completed packages (+ related domain identifiers for "routing") back to Merchants for fulfillment

This should be "fairly compatible" with existing card processing systems and vendors.
No updates to FIDO would be required and the UX could be close to optimal.

However, to the W3C folks great dismay, I claim that:
- There is no need for a specific "Payment API" in Web browsers[1,2,3]
- Most current payment providers target "omnichannel" which calls for quite different solutions[4,5,6]

b at d@ss and general PITA

1] In fact, I published an open letter about this *before* any significant work had been performed: https://cyberphone.github.io/doc/web//webpayments-taleof2roadmaps.html
2] Some of the W3C members have indeed recently also "observed" the problem (and associated *opportunity*): https://github.com/adrianhopebailie/modal-window/blob/master/explainer.md#solutions-considered
3] "Workaround": https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf

4] Open solution: https://cyberphone.github.io/openbankingwallet/
5] Closed and secret solution(s): https://empsa.org/
6] Ridiculous "solution": https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2020-01/MSG%20MSCT%20061-19v1.1%20Extended%20Mandate%20MSG%20MSCT.pdf

More information about the Openid-specs-fapi mailing list