I do remember @diegop mentioning something about this unusual behavior, but I assumed after some time option 1 or 2 would become the only option, but we still have two option, and only option 2 works with the NNS.
I tested several times and this was consistent behavior.
What is the recommendation to use for developers and end users? Would only option remain soon?
For now we lean towards option 2, since we will probably use the NNS.
Any advice or explanation on what is happening would be most appreciated!
I cannot provide any recommendations or answer your question about which option will remain. Unfortunately, I do not have that information, and I really wish I knew more (you can refer to this thread here for why Juno uses internetcomputer(dot)org).
Regarding the “unusual behavior” you noticed, let me try to explain. When you create a new anchor with Internet Identity, it becomes valid for sign-in purposes for the specific domain on which you created it.
For instance, if you create an anchor on identity.ic0.app, you will only be able to use it to sign in on that domain. If you try to sign in on a third-party dapp like Dscvr, that dapp should request you to sign in with identity.ic0.app specifically to use the anchor you created. If it asks you to sign in with identity.internetcomputer.org, it won’t work.
The same applies in reverse.
When a developer implements the AuthClient of agent-js, they can define which II domain to use. However, commonly and by default, identity.ic0.app is still mostly used.
It is possible to set an anchor to be valid on multiple domains. For example, my personal anchor works on both, allowing me to sign in everywhere regardless of the II domain used. Nevertheless, I understand that the UX for setting up such “cross-domain” functionality in II is not yet optimal and is not well-documented.
I hope this answers your question, at least regarding the why and what. Let me know if anything is still unclear.
From your reply it seems that this behavior is what happens today, and it ill not change for NNS any time soon, it will just run on https://identity.ic0.app and nowhere else.
Here is what is not so clear from your answer:
1.- It seems an on-chain DAPP can not support both domains correct? That would explain why the NNS only works with ic0.app.
2.- It seems however that a client app, a JavaScript interface could theoretically connect to anywhere. Correct?
3.- How can a regular user have a single Internet Identity (a single number) that connects to both ic0.app and internetcomputer.org domains? It seems impossible using the normal process. On the link you shared about [Juno] you said it was possible to have an II number work in both domains, how?!(Internet identity and login - #2 by peterparker)
When registering an anchor on the Internet Identity, it can work with both domains, but it requires some configuration. That’s why your anchor may work with one method but fail with the other.
Correct. Like I said above, it’s an optional parameter of the AuthClient.
Yes it’s possible, I set up my personal anchor few months ago and it works on both, but, I’m not sure it is well documented or even still documented at all. There was a tutorial shared in the incident thread but, cannot find the reference anymore.
One suggestion for DFINITY, after a user creates a new identity on the new: https://identity.internetcomputer.org/
The link they will see later for the NNS app is incorrect, it should take them to the link you just mentioned: https://nns.internetcomputer.org/
But instead takes them to the old one, and of course it does not work.
I agree that it looks better and has additional advantages, such as not being a TLD owned by Google. While I cannot make any specific recommendations and have no insight into the future, based on our discussion in this thread and the other recent threads, I have to admit that if I were to start a new project tomorrow, I would likely be hesitant and would possibly end up using the default option ic0.app.
Good catch! I’ll pass on the message. I’m not sure if it can be made dynamic, though, since the list is static. It’s copied from the same list used to generate the showcase on the IC portal (https://internetcomputer.org/ecosystem), but I’ll pass on the information. Thanks!
I’ll check if I find again the documentation that explains how to have both domains and, if I find none, might try on my spare time to write a tutorial about it. I’ll share my findings.
No it won’t. AFAIK this is because WebAuthn messages/signatures are bound to a domain, so if you register a device on one domain then on the other one it won’t provide the same identity. To II they will look indistinguishable from two separate devices
