An Internet-Identity-principal is tied to a domain-name?

Developers Programs & Applications
1

If the ii ties to the domain-name now than what happens when the nns.ic0.app gets out of beta and has a new url?

Maybe tie the II-principal to a canister’s-id?

2

There are two independent aspects here worth mentioning:

  • WebAuth devices (finger print, yubikeys) are bound to the origin (i.e. host name) of the site you are logging into In this case https://identity.ic0.app. This is a property of WebAuthentication, and nothing we can change easily. If we move the Internet Identity from https://identity.ic0.app to another hostname, there will have to be a manual migration protocol (e.g. using a recovery seed phrase), but you can keep the User Number just fine.

  • The identity handed out by the Internet Identity is tied to the hostname. It is a deliberate decision in the design to authorize web application (which are identified by hostname) rather than by canister. This is matches the security model of the web in many ways, is more suitable because it’s really web applications (i.e. frontends) talking to each other here. And it’s not like a web application will always have a canister behind them – they may be hosted outside the IC, and there is no reason to not allow the Internet Identity to be used in that case, or there may have multiple canisters associated with this web application, or a single canister may host many web applications (dispatching on the Host: header, once we have nice-names-to-canisters).

    Yes, this is causing extra headaches when changing hostnames – but it avoids headaches when changing the hosting backend. So it’s a trade off.

4 Likes
3

Thanks. I see.
How will a migration work (behind the scenes) with the switch of a domain?

4

For a web application switching domains? A few ways come in to mind; all of them require the web app to be available on both domains for a while.

From the point of the application, there are now simply two independent users (principal a and b) who need to be merged. This requires both users to indicate that they want to merge, i.e. as a confirm that you are b, and as b you confirm you are a.

This could be manual (expecting users to copy’n’paste principals), but could also be done mostly automatic. I could imagine a flow where

  • User navigates to new.url.com, and logs in with Internet Identity
  • App doesn’t recognize the user’s principal, and besides “create new account” offers “migrate from account at old.url.com.
  • If the user selects the latter, they get forwarded to old.url.com, where they can log in with Internet Identity again, confirm that they want to migrate the account, and get forwarded back.

Of course this requires a bit of coding on the web app side, and needs careful design to be actually secure (a bit like the Internet Identity flow itself). Also the backend needs to support multiple princpials per user account.

If this becomes a common problem, I hope the community will produce convenient and elegant libraries that web application developers can just use for that.

4 Likes
5

I see, Gratitude.

__

6

This seems to apply to .raw.ic0.app vs .ic0.app addresses. The raw version and non-raw version don’t share users, and I wind up with a different principal depending on which I log in to. I would have thought accounts would at least be shared between raw and non-raw versions of the same address.

I noticed this by mistake when I loaded my frontend through the raw address and my account was missing. I use the .raw address for http_request responses, which don’t involve the frontend, so it’s not important that I be able to use the .raw address when loading my frontend, but I figure it’s worth noting that accounts can’t be shared between the two.

7

If you implement the alternative origins then you can share users between raw and non-raw.

1 Like