Please get rid of this annoying page. It’s quite annoying having this extra step.
4 Likes
it it annoying 
but it is necessary, you don’t want some unknown dapps access your Identity without your permission, right?
just like a wallet, need a step to confirm you really want to transfer.
You definitely wouldn’t want that, but that’s the whole point of authenticating is for. If you don’t want something to use you II, you don’t authorize it.
Is there a technical reason it can’t be something like this to skip that step:
6 Likes
I think this extra final step is necessary because this is the only step where you have your Principal to check with our eyes. You can check if it is correct one, just like you check uids for transactions before final confirm.
4 Likes
Yes, I’d strongly support merging the two pages into one. You just need to take all the information on the second page and put it on the first page. This would greatly improve the UX of logging into apps.
4 Likes
You have no information before authenticating through InternetIdentity…
1 Like
Couldn’t you use ajax and load in the principal as they type in their anchor? It wouldn’t work if they don’t have js enabled but it would work for most.
What information do you think the user needs? That random hexadecimal string in microscopic grey font? Why should users care about that when logging into 99.99% of apps? That string would only relevant to a user in an exceedingly rare circumstance.
4 Likes
I recently took a deep-dive into this while replicating the agent-js login parts with a rust frontend, so I think I can shed some light into how (and why) the auth flow is currently implemented.
In the most basic scenario you have a dApp, a User and the Internet Identity (II). There are two main flows here. User → II and II → dApp.
-
User to II
First, the user inputs their anchor ID and the II requests verification. This is the webauthn standard. Depending on the hardware used, the user is asked to insert their key, touch their key, provide a pin or biometrics. It is only after this verification step that the II can know who you are and what principals to sign with. So this part answers @skilesare 's question. You wouldn’t be able to display that info before verifying that the user does indeed control an anchor ID. -
II to dApp
After authenticating the user, the II communicates with the dApp (over postMessage()) and confirms that it is ready to perform a delegation, and asks for what the dApp needs. At the moment I think a dApp can only request a custom expiration. In the future, I guess this is where capabilities would come in.
So now the II has an authenticated user and a request from a dApp, so it can issue a delegation. The question of the day at this point is “should it just issue the delegation, or should it ask for confirmation?”. Technically there’s nothing stopping the II to issue the delegation. But there are a bunch of very good reasons that it should ask for confirmation, and even improve the UI to make it clearer that you are about to approve an important (and relatively irreversible) action here.
If you think about it, this is the flow for just about any 3rd party auth service out there. Consider singing in with Github. You just have to remember that there’s usually a hidden step here, since most people are already logged in to their authenticating service. But in a cold case, the sign in with Github is pretty similar:
Step 1: enter username & password for github
Step 2: github confirmation screen “Fleek would like to access your e-mail (secret***il@dodgyservice.com) and activity. ARE YOU SURE YOU WANT TO PROCEED?”
I would argue that it is an industry standard to confirm every potentially dangerous action. You never want anything crypto related to be dependent on one single click. This isn’t amazon trying to trick you into purchasing things you don’t need. Sacrificing a bit of convenience for security is pretty important, in my opinion.
On top of actual mistakes, there are also security consideration here:
A) If you practice sane OPSEC and have two (or more) identities, one for “fun” dApps and one for “serious” dApps. Having an action taken solely on an anchorID without any kind of confirmation is not something I’d expect from a crypto environment.
B) Considering either an evilDApp or a compromisedDApp, if a dApp can run js code, it can initiate an authentication request for another URL. Depending on the browser and implemented countermeasures for intercepting postMessage() from other origins, there’s a world where you would think you are logging in to cutepuppies.dApp and instead sign a delegation for mywallet.dApp or mysocials.dApp, where you have your precious NFTs or whatever.
Any counter-measures, anti phishing, etc. you could possibly implement are dependent on first authenticating your user, and then providing additional information and asking for confirmation.
Having said all that, I do think there are some ways to improve the UI/UX of the II flow.
- Allow users to “name” their identities. Just like we can name a device, we should be able to name an identity - anchorID. This would allow for the 2nd screen (the confirmation one) to read something along the lines of “Authorize Authentication of <FUN KEY 1> with nns.ic0.app”.
This would serve as an immediate visual barrier for simple mistakes like authenticating with a “serious” identity on “social” sites.
- Keep track of and display “last login” info. Maintain a list of last delegations, and provide an additional visual cue as to what actions are being taken. The 2nd screen would read something like:
"Authorize Authentication of <…SERIOUS KEY1> with dscvr.one
your last login was NEVER"
^^ Instant disk scratch in your brain. What do you mean never? I always login with dscvr. Oh, wait a minute…
There’s another good reason to keep the two screens separate: future proofing. There are a lot of ideas going around on improving the II. Capabilities, access control, access lists, etc. Whatever functionality ends up being implemented (I’m personally a fan of less is more in critical systems), this 2’nd screen is the place they will be presented to the user, and, again, be confirmed by the user.
There’s a reason this is the de-facto standard. Trust, but verify. Make it accessible, but always confirm important, irreversible actions.
Since this isn’t the first time this topic has surfaced, I would at a minimum ask the UI/UX team to take another look at the flows, and maybe rephrase the text on the 2’nd screen to drive home the idea of you are taking an important, irreversible action here, and at the same time making sure the user understands that this is a confirmation screen. Visual cues & everything should match these two concepts, IMO.
10 Likes
I’m thinking the whole authorisation process would should be in frame rather than taking you away from the website you are on
3 Likes