Internet Identity Upgrade 135312: Domains Compatibility

Internet Identity Upgrade :rocket:

There is a new Internet Identity upgrade available for voting in the NNS.

This upgrade includes a new feature developed over the last months, which we are excited to announce: Domains Compatibility.

Moreover, this upgrade also includes the analytics setup, as agreed in a previous forum post.

Domains Compatibility

Support For Multiple Domains

The new feature enhances the login experience to support multiple domains seamlessly.

Currently, Internet Identity operates in two domains:

Users have encountered difficulties switching between these domains because their passkeys are tied to the domain they initially registered.

This update ensures that users can log in across all supported domains without creating new credentials in the other domains.

Login

When logging in, II will determine the best way to fetch credentials based on where the user’s passkeys were registered. If a user has multiple devices registered across different domains, the system will try different origins automatically, prompting retries if needed.

Most users will not notice any changes because only a minority has passkeys registered in multiple domains.

New Passkeys

To prevent fragmented passkey registration in the future, new passkeys will always be registered in the same origin as existing ones—whenever the browser supports Related Origin Requests.

Limitations

Firefox, older Safari versions, and third-party password managers extensions do not support Related Origin Requests. Therefore, those users might end up having passkeys in different domains, which could trigger the retries during the login process.

To address potential issues, affected users will be prompted to register their current device on the active domain, ensuring a smoother experience in future logins.

Analytics

The new analytics setup includes integrating Plausible and events to track the Webauthn authentication flow for failures and successes

We will share the public dashboard next week.

Vote

Don’t forget to vote on the new upgrade proposal 135312 :rocket:

7 Likes

My biggest issue with internet identity is that it takes a long time to load with a weak internet connection, unlike passkeys. How can we fix this? Sometimes it is impossible to log on to any IC apps at work due to poor connections.

2 Likes

Proposal #135312 for ii — Zack | CodeGov

Vote: Adopted

Reason: Builds fine and the wasm and arguments hash match the payload.

Been a while since I followed up with ii, but had to check out 823be50 - Plausible Tracking WebAuthn Flow and 3b178e1 - analytics config. All commits LGTM and match their description.
The only thing I noticed that using the script in the proposal summary it only checks the archive wasm hash, that is the second flag.

So either remove it or if archive is required as well fix it to run both. Not an issue since anyone can just manually check the file after the build is done to compare it against the payload.


Just my 2 cents. Thanks for the great work.

About CodeGov

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.

1 Like

@ZackDS The script also checks II wasm. It just outputs it a bit before the archive wasm.

I see how this might be confusing.

I’ll fix that and add both together.

1 Like

Sorry to hear that.

DFINITY has worked hard to keep Internet Identity as lean as possible so that it will still work on poor connections.

The files are minimal and the requests have been kept to the minimum necessary and parallelized when possible.

I’ll take a note and make another pass to see what else can be improved.

Yes but unless one takes a look at the script has no idea to scroll up.


Could be easier just to point that out maybe. Thanks for the reply.