You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The question has come up how the proposed Hardware Security WG would be of use for the Web Payments WG. The draft Web Payments API draft calls for payments apps that are native code used by the Browser, with no way to provide that through a Web page and associated server. Why couldn't a Web page register as a payment app (especially if it could use hasec APIs for secure, private processing on the device)? Some initial thoughts below.
Proposed W3C Hardware Security WG Charter provides:
Means of determining who vouches or secure environment (challenge signed by secure environment)
Secure Worker - JavaScript or WebAssembly (for high performance) running in secure environment on device (no tampering and not visible)
Secure Storage (data encrypted by Hardware Security component)
Secure UI (optional, when hardware security component has a capability for presenting simple html forms)
Crypto api, key management
Payment App in a Web page rather than separate native app - could be something like:
URL Registration of Payment app page with Browser (e.g. a tag that registers with the Browser, with user consent, when user visits the Web page, optionally using subresource integrity )
Web Payments WG defines API for Web payment page to call in Browser to set up communication channel with Browser and defines messages for checking available payment methods and to make payment requests and get payment responses.
Payment app page uses W3C Web Authentication (FIDO) to authenticate the user
Payment app page uses W3C Hardware Security WG (hasec) Secure Worker to run JavaScript or WebAssembly in a secure environment (with Hardware Security WG crypto, key storage, and possibly secure UI) to provide secure and private parts of payment app.
Secure Worker in hardware security environment can communicate securely with a Web sever it is associated with via its own defined encrypted messages passed encrypted through the Payment app page.
Even if Browser and payment app page in Browser is compromised, it can't tamper with messages between its Secure Worker code and the related Web server. Also, can use secure user IO if that hasec spec is supported.
W3C Web Authentication could also be used in the hardware security environment if it supports FIDO to authenticate the user without the Browser
If hasec not available, could look into Payment app page using Web server it comes from to do actions it can't safely do in Browser on device (there are also the other non-Web page payment apps as in Web payments spec that would be available)
With CORS and RFC1918, Web page that provides payment app could be served locally from device
The question has come up how the proposed Hardware Security WG would be of use for the Web Payments WG. The draft Web Payments API draft calls for payments apps that are native code used by the Browser, with no way to provide that through a Web page and associated server. Why couldn't a Web page register as a payment app (especially if it could use hasec APIs for secure, private processing on the device)? Some initial thoughts below.
Proposed W3C Hardware Security WG Charter provides:
Payment App in a Web page rather than separate native app - could be something like:
References
Web Hardware Security WG proposed charter
https://www.w3.org/2015/hasec/2015-hasec-charter.html
Web payments architecture
https://w3c.github.io/browser-payment-api/specs/architecture.html
CORS and RFC1918 internet and intranet/localhost
https://mikewest.github.io/cors-rfc1918/
Subresource Integrity
https://www.w3.org/TR/SRI/
The text was updated successfully, but these errors were encountered: