Super nice diagrams (they help a lot understanding this). I can see already the Hard work behind the scenes... so well done for this.
Some questions from me for each of the steps:
1. Looks all good here. 😎
One request though, even if the QR code is a great way to simplify the validation of who is requesting, it would be nice to have a way to see the IP of who is requesting, to allow users to have a second way to troubleshoot things when they are not making sense.
I am thinking about phishing situations when eventually users get emailed with QR codes in the name of the apps asking for authentications (of course no one should do this).
This IP (or session) validation could be done either at the PKSA side (and visually validated by the user) or using a phishing code as 3rd-step of an MFA (in case you activate it) provided by the library the "apps" would need to use. Effectively stamping that "confirmed" session in the blockchain. Comments...
2. and 3.
How is the user able to understand if the transaction request is from the browser/app/host he/she is requesting/interacting with?
For example, if I use the phone to accept and broadcast a transaction that is initiated on my PC. Is there a mechanism that only allows this after the authentication happens (which I would say, that can either have protection towards the active session, or something like, identify the session with a name or IP)?
I am looking at the same perspective of what I described on the authentication, and I understand that at the same time we want to make this simple for the user. So, maybe either provide a way to identify sessions (if multiple are allowed) or only allow one to persist, forcing the user to first authenticate before going through sign/broadcast transactions.
The scenarios above are probably important for public places where wireless devices can be trying to listen and be also man's in the middle. But I agree for most situations it will not be a problem.
Thanks
Cheers for all this work and the courage to deep dive into resolving this "complexity" problem for the community. Feel free to always tag me on these. My pleasure to support/review/discuss stuff like this. Hopefully, the proposal will go ahead.
Thank you for your comment @forykw
Not sure it will help. When you're on mobile, people often don't even know which IP they use or how to display it, as the "requester" is the device itself, not an app running a remote server.
Moreover, the incoming IP seen by the PKSA will always be the one of the HAS it is connected to.
That being said, the App and the PKSA can display the uuid of the request for the users to match it.
This will be explained in details in the coming posts. TLDR; communication between App and PKSA is a one-to-one once the user authenticated with an App
Ok, I can wait for it. Maybe in the HiveFest we can chat... easier.
PS: I was not covering people that know how to deal with IPs... but instead the other way around, the ones that don't know and will get "tricked" by people that wish to take the glorious stupid creative path.
In normal circumstances yes... but behind firewalls anything can happen. And big commercial buildings have huge problems with these. Most household ISPs will be ok... but when we move to IPv6, this will be uncontrollable. Not something to worry for the immediate future, but something to think about ahead of time and make some "preventive" countermeasures.