4.1.2 Secure transaction API details

[mark-orz]

Note in this paragraph the importance of having a Trusted User Interface available, which should include both a trusted display and a trusted return path for the user's confirmation.

[sbahloul]

a trusted return path for the user's confirmation

I am not sure to understand the security properties you are thinking about this path: do you mean that we should deal with the interception of the final result of the operation or more specifically about the strength of the link between the trusted display and the secure credential storage ?

[mark-orz]

The point I was trying to make was that, as well as having a trusted path between the Secure Element and the display (so that the user is shown exactly the information to be signed), there also needs to be a trusted path between the user's input device (e.g. keyboard or push-button) and the Secure Element. If this path is not trusted, the Secure Element could be fooled into believing that the user had chosen to confirm the transaction (by pressing 'OK') when in fact he/she had rejected the transaction (by pressing 'Cancel').

I'm not saying anything about the final result of the operation (the signed transaction) or the strength of the link between the Secure Element and the Trusted User Interface.

[sbahloul]

This is something new we need to add to the doc: can I considered to add your following mention in the Section 5 ?

As well as having a trusted path between the Secure Element and the display (so that the user is shown exactly the information to be signed), there also needs to be a trusted path between the user's input device (e.g. keyboard or push-button) and the Secure Element. If this path is not trusted, the Secure Element could be fooled into believing that the user had chosen to confirm the transaction (by pressing 'OK') when in fact he/she had rejected the transaction (by pressing 'Cancel').

[cyberphone]

A major problem with the Secure Transaction API is that it doesn't work for payments since payments systems do not put user display data into the transaction stream. That is, the display may show one thing but the actual signature operation (=result) probably works on a much lower level like is the case for EMV.

[cyberphone]

@mark-orz @sbahloul @brunojav I believe that when you have gone over all the issues will come to the same conclusion I did sometime back in 2015 (after several failed attempts coming up with a reasonable Web solution...), which is that you need "installable" trusted Web applications having similar privileges as native applications.

Although imaginable, this would indeed be an entirely different project than HB Secure Services. It would also be an extremely daunting task since essentially every useful feature (they are?) of the native world would have to be standardized. This is what Mozilla tried to do with Firefox OS and it didn't work: https://annevankesteren.nl/2016/01/double-down-on-the-browser

It is obviously much faster and simpler hooking into the existing native application world.

[cyberphone]

For some applications like payments a Web-2-App scheme enables the same App code (with moderate parameterization), to be used locally using NFC which also is a feature of Apple's and Google's recent wallet versions.

[mark-orz]

Not wishing to disagree or dismiss cyberphone's comments, but the original issue was a note to have a trusted path between the user's input device and the secure element, and sbahloul's proposed addition to section 5 fixes that. Suggest cyberphone raises a separate issue for his concerns.

[cyberphone]

@mark-orz It is the trusted path to the display (=the Web) which is missing. This can (AFAIK) only be achieved through built-in browser "chrome". I don't see how you could define such chrome in a way that matches a myriad of different applications.

[vgalindo]

I suggest we close the issue as a corresponding resolution has been agreed by Mark https://github.com/w3c/websec/issues/99#issuecomment-235295667