RE: Hardware Security CG

Adrian,

Thanks for paying attention to the work of the CG.
To help any member wanting to take action on that one : all comment, suggestion, can be sent to the hardware-based secure services CG, starting here : https://www.w3.org/community/hb-secure-services/ <https://www.w3.org/community/hb-secure-services/>

Regards,
Virginie


From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
Sent: mardi 10 mai 2016 10:34
To: Payments WG
Cc: GALINDO Virginie
Subject: Hardware Security CG

Hi all,

The HW-SEC CG met recently and have posted up the findings of their face to face.

One deliverable they are working on is a transaction confirmation API which I think will be particularly interesting for anyone that wishes to write browser-based payment apps.

https://github.com/w3c/websec/blob/gh-pages/hb-secure-services/etherpad-04-26-27.md#transactionconfirmationapi---champion-sebastien <https://github.com/w3c/websec/blob/gh-pages/hb-secure-services/etherpad-04-26-27.md#transactionconfirmationapi---champion-sebastien>

Goal of the API: "to give some assurance to a remote entity that a transaction is confirmed. Confirm that what was sent was communicated to the user, and that what was displayed to the user is what was confirmed.  Confirmation should include a signature and also some information about the secure environment (which vendor, is it hardware, is there tamper protection, is there any certification- with clarity of both display and input as these may have seperate security "levels") - this will help the remote entity understand how confident they can be in the response."

I'd recommend that those of you in the WG interested in this aspect of the payment flow review and provide feedback as this work progresses.

It's my feeling that this functionality is not in-scope for the payment API itself [1] [2] (which simply passes the initial request from the payee website to a payment app

This functionality can not currently be achieved using a browser-based payment apps so this would be a great enabling capability for these in future.

Adrian

[1] https://github.com/w3c/browser-payment-api/issues/31 <https://github.com/w3c/browser-payment-api/issues/31>
[2] https://github.com/w3c/browser-payment-api/issues/41 <https://github.com/w3c/browser-payment-api/issues/41>
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.