Internet Identity Roadmap Update, Jan 2023

[marydwyer]

Hi Internet Identity Community,

Happy New Year! The Internet Identity team is starting off 2023 with a release that streamlines the II frontend with updated design elements, more straightforward and reduced copy, a new FAQ page that is run by the DFINITY support team, and some infrastructure changes. These updates should make it easier for new users to use and learn about Internet Identity. You can review and vote on the proposal for this release here.

Over the next few weeks, we are prioritizing:

• Reducing the number of steps it takes to onboard new users, which will improve the onboarding experience for Internet Identity, as well as for the dapps that build on Internet Identity. The features that meet these goals include:
  • Reducing the number of system authentication prompts to only 1 while a user is onboarding.
  • Improving the device adding and naming experience, so that it requires no effort from the user and reduces confusion around “devices”.
  • Improving the recovery experience, so that it is easier to understand and use.
• Improving the developer experience for using II locally (exploratory)
  • We’ve heard from you that it’s challenging to set up II locally, and we are hoping to improve that experience. As a first step, we are improving the documentation.
• Attribute sharing
  • We have been designing solutions that allow dapps to share data attributes about a user, with the consent of a user, in a privacy-preserving manner. You can join our working group to contribute to the progress on this topic.
• Security and reliability improvements
  • We are constantly working to improve the security and reliability of Internet Identity, to improve the experience of our users and the users of the dapps that build on Internet Identity.

Here is a screenshot of our roadmap:

P.S. If you are just meeting me for the first time, my name is Mary and I am a product manager that works closely with the Internet Identity and NNS FE dapp teams at DFINITY. One of my goals as a product manager is to use feedback from the community to help define and prioritize new features and initiatives. I appreciate any feedback you have about your experience. Your insights will make our new features more impactful. I am looking forward to collaborating to improve your experience and the users’ experience with II!

[Gekctek]

One issue that non-browser applications have right now, like video games, is officially the Internet Identity only approves the browser client as the client to use.
We have something in C# to process the Fido2 device and integrate, but there seems to be an issue with trusting the client with the signed request. Since the client can act as the user, if the client is malicious, the client can cause some damage
Not sure the solution, if its changing the login flow or to ‘bless’ certain clients so people can feel safer.
All we really need is a good way to login without having to use a browser

[frederikrothenberger]

Hi @Gekctek

We will not endorse any other applications to interact with the II canister on behalf of the user other than the officially supported browsers.

The reason for this is security, as you have already pointed out:

Since the client can act as the user, if the client is malicious, the client can cause some damage

Users should rightfully not trust non-browser applications that interact with Internet Identity credentials.

As a developer, I advise you to abandon the this way of directly interacting with webauthn credentials. Even if users were to trust your application, this will cause various other problems:

• On moderated platforms, such as the Apple and Android app stores interacting with webauthn credentials in such a way will potentially get the app banned.
• On macOS webauthn credentials are separated by application (i.e. different browsers do not have access to the same set of WebAuthn credentials). So even if a user does have a valid WebAuthn credential for II on his macOS device, your application will not get access to it.

Rather, your application should interact with the system browser to obtain a delegation on the session public key. An example of such an integration is provided here.

[Gekctek]

The problem that is being run into is that its just a bad experience for some scenarios to use a browser.

Any advice on what approach to take. I find it hard to swallow that we can just never use anything but a browser for some of these integrations.
I guess we just have to do general wallet integrations or something manual?

[Zane]

Will we ever be able to use an authenticated device to temporarily auth other devices without a TPM or WebAuthn support? It is quite absurd this is still not a thing, do you realize not everyone in the world has a Macbook or is a crypto person with a ledger or Yubikey? WebAuthn is not available on any Linux distro and a majority of desktop computers, I’m not taking out my ledger everytime I need to log in DSCVR and I won’t buy a Yubikey just for IC dApps, usability for the average Joe should have been a top priority.

[Fulco]

I’d love the ability to have a username instead of needing to remember a 7 digit user number. Are there any plans for that?

[ilbert]

I would also like to run a Node.js client “delegated” by the user. This way in that client we can use @dfinity/agent-js libraries to interact with my canister on behalf of the user.
As far as I understand, this would require me to create a frontend that authenticates the user through Internet Identity and then somehow call the Node.js client back with the delegation obtained.
Open questions are:

• should the Node.js client save the delegation somewhere?
• how’s the delegation expiration handled?
• does this make sense at all? Or should I find an easier way to associate the Node.js client to the user on the canister side (e.g. assigning the client an id that is mapped to the user’s principal)?

[frederikrothenberger]

There are solutions offered by browser vendors to alleviate this:

• I.e. Safari and Chrome (at least) have a feature called QR code login which allows you to authenticate a browser session on the desktop using your mobile phone. This works nicely with II to do exactly what you’re asking.

This is more secure than us developing a similar QR code login feature in our application code as it preserves the phishing protection offered by WebAuthn (which is a property usually lost when authenticating across devices using only the means offered via JS browser API).

[frederikrothenberger]

We are aware that the browser integration using an intermediary dapp is not optimal from a UX point of view. However, it is quite common for sign-in operations to delegate to browsers by redirect, even for desktop applications.
I think having a better browser based flow (i.e. using redirects for example) could already improve UX by a lot. Unfortunately, this is not the top priority at the moment and will take a while to properly design and implement.

Just a general notice: the integration with II (regardless of what route we take) will always incorporate a change of context. I.e. the client application requesting the sign in must not also be responsible for handling the front-end interactions with the users regarding WebAuthn, otherwise the client application would have too many privileges and could do malicious things.
So then the questions just becomes, whether the application switches to another native application (i.e. app-switch on mobile platforms) or to the browser on a specific page or to a different device entirely (i.e. show a QR code within your application that must be scanned using a phone and the sign-in happens on the phone).

Feel free to join one of the sessions of the identity & authentication working group to discuss this in more detail, also with the developers of other IDPs on the IC.

[frederikrothenberger]

I would also like to run a Node.js client “delegated” by the user. This way in that client we can use @dfinity/agent-js libraries to interact with my canister on behalf of the user.
As far as I understand, this would require me to create a frontend that authenticates the user through Internet Identity and then somehow call the Node.js client back with the delegation obtained.

Yes, this would work.

• should the Node.js client save the delegation somewhere?

Probably, as you need access to it over a longer period of time. Note that the delegation itself is not sensitive and cannot be abused given the corresponding private key is stored securely and is not compromised.

• how’s the delegation expiration handled?

You can request delegations valid up to 30 days. Unfortunately, II does not (yet) support dynamic session lifetimes (i.e. extending the validity of a delegation dynamically if in use). You would have to re-authenticate at least every 30 days and rotate the delegation.

If you want to have more flexibility, it might be a better idea to generate a new identity for node.js and use the delegation only to tie the node.js identity to the II identity once. However, key rotation and periodic re-authentication are advised regardless of the method used.

• does this make sense at all? Or should I find an easier way to associate the Node.js client to the user on the canister side (e.g. assigning the client an id that is mapped to the user’s principal)?

This also depends a lot on what you are trying to do.
But either way is sensible given the trade-offs associated fit your needs.

[frederikrothenberger]

Addendum, because I don’t have enough context: if you plan on making a canister interact with a different canister on your behalf (i.e. the client is a canister as well) it is much better to use the delegation just once to tie the II principal to the canister id of the client canister and then do normal canister calls. This does away with all the key handling and poses less foot guns than trying to safely use a delegation from within a canister.

[Zane]

I’ve tried that with both Brave and Chrome and it just shares the tab, not the session, not sure if I’m missing something. Even if it worked, Chrome requires Sync to be enabled to move tabs from mobile to other devices, so one must be logged in with a google account and Brave’s UX for it isn’t really intuitive, not sure about Safari. So the choice, if the workaround shared the session, would be between relying on a centralized entity to do a basic web3 task, dealing with unnecessary complexity or switching browser altogether.
After all there must be a reason if banks, CEXes, NFID and many other services dealing with sensitive data have been adding QR code auth as an option instead of relying on browser solutions: they are more user friendly and most importantly work, both of which aren’t the case for the browser counterpart right now.

Your suggestion also seem to contradict what another dev on the identity team said months ago:

Internet Identity is slowing IC adoption

Some things you mentioned here (OTP/QR code, granular control and admin level) are definitely on the roadmap, we just haven’t gotten to it yet. For “Pseudonyms for Anchors”, I think that’s a great idea! How would that work exactly? Are you thinking of e.g. generating a pair of words based on the anchor number for instance? Having user-specified pseudonyms will be a bit tricky to implement. Finally regarding browser compatibility, can you clarify what the issue is? I think this isn’…

So it comes as a surprise to hear it doesn’t seem be on the roadmap anymore.

[frederikrothenberger]

Hi @Zane

I did not say that we dropped it from the roadmap, rather that there already exist solutions that might work for you.

The feature that I’m talking about, does not require you sign in to chrome (see that I’m using the “guest” profile to showcase this).

So on the WebAuthn prompt you should get the following options (red box):

Which should give you this screen:

You should then be able to scan this QR code with your mobile phone to complete authentication. Note that it might require both devices to have Bluetooth enabled.

Currently, there is a lot of movement with regards to OS and browser support of WebAuthn. So we expect more changes to be made by browser vendors to make WebAuthn easier to use.
Given the current resource constraints on our side it might therefore be sensible to wait a bit for the WebAuthn changes to settle down a bit, before we start adding features related to that.

I hope this helps.

[Zane]

@frederikrothenberger

I did not say that we dropped it from the roadmap, rather that there already exist solutions that might work for you.

Oh ok, the previous statement gave me the impression you weren’t considering it anymore cause it’d be less secure.

@frederikrothenberger

Note that it might require both devices to have Bluetooth enabled.

I see, I tried that too but didn’t know about the Bluetooth requirement. It’s an improvement but very small, it doesn’t seem to work with Brave and the device must have Bluetooth support, which most desktops lack. The feature isn’t quite known and this is the first time I’ve seen it proposed as a solution for lack of WebAuthn support, so at the very least it should be advertised more.

[marydwyer]

Hi @Fulco, thank you for the suggestion and this is on our backlog. We will keep you posted on its priority in the roadmap updates.

[yuriy0]

@frederikrothenberger

the client application requesting the sign in must not also be responsible for handling the front-end interactions with the users regarding WebAuthn, otherwise the client application would have too many privileges and could do malicious things.

Can you clarify what you mean by “must not”? Does you mean that:

• we merely ask nicely that client applications don’t do this
• the internet identity login interface will one day prohibit this (i.e. it will become impossible to achieve)
• client applications which are known to do this will be censored from the IC

or something else, or a combination of these?

Also, can you clarify what you mean by “client application”? Does this include every application except the “Internet Identity frontend running in a browser”? Is an application which serves as a middleware, provides login to II, but does not provide any “IC end-user functionality”, nor does it allow access to the users Webauthn signature, considered to be a client application?

In other words, is there a possibility that in the future, another application other than “Internet Identity frontend running in a browser” would be considered to be an official, approved method of login to the II? And in particular, could such an application be a native application which does not require a browser?

[frederikrothenberger]

Hi @yuriy0

Thanks for the question. It was meant as a very strong recommendation, for several reasons:

• We cannot stop people from building applications that integrate this way and there is no way to restrict it from the II side.
• I don’t think we want to censor applications. However, when asked about the security of such applications, we would absolutely highlight the security risks involved.
• I think even for the developers themselves, it is not necessarily easier (or even better UX). See e.g. the points I have highlighted in a previous post:

• On moderated platforms, such as the Apple and Android app stores interacting with webauthn credentials in such a way will potentially get the app banned.
• On macOS webauthn credentials are separated by application (i.e. different browsers do not have access to the same set of WebAuthn credentials). So even if a user does have a valid WebAuthn credential for II on his macOS device, your application will not get access to it.

About the other points:

Is an application which serves as a middleware, provides login to II, but does not provide any “IC end-user functionality”, nor does it allow access to the users Webauthn signature, considered to be a client application?

This would be totally fine.

Let me clarify: Any application that interacts with the Internet Identity WebAuthn credentials directly (i.e. requests signatures signed by the users keys) necessarily has the same privileges as the Internet Identity front-end itself. I.e. it is in full control of the identity.

It would be a very bad security model, if - in general - applications had that kind of control. As it stands currently, when signing into websites (regardless whether they are malicious or not), you do not need to worry about the safety of your Identity Anchor. And this is the property that is broken by direct WebAuthn integration. Users should rightfully not trust applications asking for credentials that belong to Internet Identity.

However, coming to your last point:

In other words, is there a possibility that in the future, another application other than “Internet Identity frontend running in a browser” would be considered to be an official, approved method of login to the II? And in particular, could such an application be a native application which does not require a browser?

If the application is distributed in a secure way, fully open-source, with verifiable builds that can be checked against the installed application and has been security reviewed by professionals and can only be updated by explicit user consent (to recheck the security properties of the update), then I don’t see an issue with trusting such an application. This is the security standard that the Internet Identity front-end sets.

For game developers this is an unreasonably high bar to meet and thus my recommendation: try to find a way to integrate with less strings attached.
This might require us to extend Internet Identity with new functionality. I invite anybody interested in this topic to join the Identity & Authentication working group to help us find a solution that works for everyone.