Transferring identity from one host to another one

Developers
1

I want to “transfer identities” between hosts:

  • If a user authenticates on host1, he can use host2, too (but I can’t use ii-alternative-origins, because host2 is added dynamically, that is may be created at any time).

AFAIK, this is impossible to do on II, because an identity is only for one host.

I think, it is possible to implement by creating a new identity canister, in addition to the standard indentity_canister.

Can you point where to dig into? I am not very fond of reading the entire “Internet Identity” specs and then reasoning what to do without any guidance. So, I am asking for guidance.

Also, how much my new identity system can be coupled with II? I’d like, if possible, the user to use the same devices and keys.

Maybe, II should be updated to contain this fearture (see the one-item list above)?

2

We faced same scenario in Boom Dao, where we wanted every new game getting on boarded should be able to onboard existing users of Boom Gaming Guilds, having same account.

How we managed to do that - We created a Login Webpage template, its a kind of webpage which is deployed in a canister and have all alternative origins listed here (origins other than unknown games which will get deployed in future, like Boom Gaming Guilds platform etc). And then we made all new games which are getting onboard, use that same Login Webpage in their build for auth.

I am not sure what’s your actual use case, but may be you can follow same path.

3

As I told above, canisters are created dynamically (in any amounts), so I can’t pre-list all of them in alternative origins. When a new module is created, it would be missing in alternative origins.

My use-case is an “OS-like” package manager, that allows the user to install “packages” (each one consisting of several modules, possibly with frontends where the user needs to login. Alternative origins won’t work (even if I serve it dynamically, as a http_request - is this possible?) also because I want to transfer user rights from the package manager to installed package but not vice versa: The installed packages must have no control over the package manager, otherwise it would be easy for a hacker to screw my package manager.

4

Hi!

Why isn’t updating ii-alternative-origins dynamically working? In the same process that you create the canister, couldn’t you add it to the ii-alternative-origins asset?

Note that there is a constraint of 10 alternative origins at the moment.

The “self-hosted” solution would be to fork Internet Identity and add this functionality yourself.

We have been discussing different ways of handling this, but they are mid-term plans, not short terms.

5

I told:

  1. I need more than 10 origins.
  2. I want auth in package manager to work in other canisters, but not vice versa.