Internet Identity Roadmap Update, September 2022

Hi everyone

Here’s the September update for the Internet Identity team’s roadmap! You can find the August update here .

As promised last time in the August update, we did start to make more changes to the UI. Some of which are already live on mainnet (e.g. see this topic).

So what is going to keep us busy in September:

  • More UI changes to make II even prettier as well as some dev infrastructure to make changes easier in the future.
  • Hopefully finishing the long standing II subnet migration which will give it a whole (still NNS controlled) subnet on it’s own.
  • To accompany this migration, we want to provide infrastructure to retrieve a log of anchor operations for each anchor.
  • Also, we plan to move Internet Identity to a different domain to isolate it better from all the other applications on the IC. This epic is still very much in the beginning of being worked on and we will share more as we go along implementing it.

If you have any questions, we are happy to answer them. :slight_smile:

Have a nice day!


Sorry to have missed this Identity Group discussion today. The following topics would have been brought up by AstroX. I’ll just leave them here for further discussion:

1. Mobile App Integration

Problem: Mobile Apps, for example Distrikt, are hard to integrate with II. Because II only accept and response to browser window. The integration flow will become as following:

  1. Mobile app needs to load up a browser window page to redirect the authentication payload.
  2. The middle page should be the same url to web version login page of the DApp to make sure the principal ID is the same to both end.
  3. Payload are session publickey , “frontend url” and anchor number.
  4. After II response with a delegation message, this middle page will have to rebuild the delegation chain and get it back to mobile native side to recover the correct delegation identity.

This flow is not very good for mobile DApps, and we need to find a way to remove the middle page and call II’s canister function directly or allow II’s frontend to receive payload from other client software besides of Browser

2. Global delegation Identity and cross-device authentication

This two problem are related.

First, global delegation identity, is more important than we think for users. Delegation Identities provided by II, initially design for a secure way to access domain-tied canister, to prevent the delegation leak and protect users’ privacy. However, users today are too familiar with global ID for example ethereum’s wallet, they find it very easy to use to login as many integrated website. These IDs are portable, easier to understand that seems every DApps display the same thing, and more importantly. Users can use them to receive and send assets(coins/nfts) across the DApp. On IC, users find it difficult to understand and getting confused when they mint a nft from DApp A, and they have to manually input the principal/accountId of DApp B (market place maybe) to be able to list it to the market.

We have been told that the II team is working hard to find a solution with “pemission/capabilities” model of delegation. Which is great, however, we still need to find a way to generate such global ID for users to understand and use.

Secondly, AstroX is experimenting with such global delegation. We need to be careful that the delegation targets(canister IDs) have to be passed into the canister signature. And every time when there is a new actor with new targets used by frontend, these targets are also needed to added to the signature. If not, the global delegation can access to all the DApps and putting users in dangerous situation. We have seen Plug wallet is using the same mechanism to prevent this situation happens, since they are also another solution of global IDs. Although we can keep this secure by signing every targeted canister, but It will also increase the cost of interaction of Users. For example, entrepot has over 190 NFTs listed right now, and more will be added to the market, users need to sign all of them. Now think of if some day is integrating with such global ID, since every user control his/her own canister, if you invite a friend to your chatting channel, another canister need to sign. Which will cause such delegation not applicable to IC DApps.

For our problem, is that we cannot use cross-device login. For example, Alice has a mobile app holding her identity, meanwhile she wants to login to a computer in the public Cafe. Now she won’t have to add the computer as a device to her II, but to control a temporarily session identity using her mobile app, just like scanning a QR code. Now if only when the delegation is global, the signing process is needed when new target canisters are added. Which will cause so much trouble in this device-to-device situation. We do really want to support this scenario, but to overcome this problem, we need advanced solution of global delegation capabilities or we just have to use other protocol like WebSocket or other methods.


Any plans to move away from identity anchors ? Would be nice if we could just use our biometrics. Don’t think my grandma will be memorizing her anchor


Hi @neeboo

It is unfortunate that you missed the working group session. But thanks a lot for documenting the issues here! :slight_smile:

We have decided to move the working group discussions and documentations between the monthly sessions to a Github repository. It will still take a few days until I have finished setting everything up. But as soon as it’s ready, I will copy the issues raised here over to Github, where we can then have the discussion about them.

1 Like

@dfisher : Currently the anchors are used to switch between multiple identities that a user might have. We are aware that the anchors are not memorable.

However, if you are only using the same anchor on every service you only need to enter it when adding a new remote device (and there it is shown in the instructions on the existing device).

That being said: yes we want to improve the situation. But it is likely that we will always have some sort of identifier for users to chose which of their possibly many identities they want to use for the current interaction.

If you look at how NFID is constructed they do not use anchors. What do you think of that approach?

Also, if you want to stick with account anchors, are you able to tie it to a ICNS domain like davidfisher.icp?

1 Like

@neeboo I have now created the following GitHub issues to discuss your points raised:

Let’s take the discussion there. :slight_smile:

1 Like

Anything to learn from dWallet Labs? Seem to be building intelligent wallets with transferability (no permanent private keys). They are building a way to easily program access to control wallets.

Reminded me of Internet Identity. Wondered how it is different.