Why principal ID is different for same identity for nns wallet and my own canister?

Developers
1

I expect to see same principal to avoid change UI and provide user principal ID to add ICP balance.

Inside my code, I grab principal like that:
const canisterIdinternetIdentity = ‘rdmx6-jaaaa-aaaaa-aaadq-cai’

    window.ICPauthClient.login({

        identityProvider: (window.web3ChainId) == 111111456327830 ? "https://identity.ic0.app/#authorize" :'http://' + canisterIdinternetIdentity + '.localhost:4943',
        // 7 days in nanoseconds
        maxTimeToLive: BigInt(7 * 24 * 60 * 60 * 1000 * 1000 * 1000),

        onSuccess: async () => {
            console.log("success")


            const identity = await window.ICPauthClient.getIdentity();
            console.log("identity " + JSON.stringify(identity))

            const principal = await identity.getPrincipal()
            console.log("getPrincipal " + principal)
1 Like
2

Why principal ID is different for same identity for nns wallet and my own canister?

Long story short, principals authenticated with Internet Identity are closely tied to the domain of authentication.

In other words and for example, if you sign in on hello.com, www.hello.com, yolo.com, and localhost:5173, you will get four different principals for the same identity.

This is designed to prevent tracking and preserve anonymity.

4 Likes
3

general problem in case that I must add special UI for receive/send ICP for my own local wallet, which is not good user experience. If there any ways solve it for user friendly manner?

4

Your question is a bit vague, so I’m not entirely sure what you’re aiming to achieve. Different principles don’t necessarily lead to an unfriendly user experience, in my opinion. Could you provide more context and perhaps some code?

But generally speaking, what I described above is a fact. There are some signer standards that are currently being discussed and implemented (see repo) which would ultimately standardize communication with wallets, but they are not ready for production yet.

If it’s the wallet interaction that bothers you, you might want to look at Plug or other wallets for now, but again, I’m really not sure about your context.

5

In general, users expect to have wallet on nis with balance and when they connect to my game, same wallet expected with same balance. This is how regular experience works
In case of have different addresses and balances for different games users must take care send balance before start, my UI must handle send money back e.t.c.

6

Thanks for the context. Then my last answer was correct. I think NNS-dapp does not support yet the pattern you are describing because the standards are not yet accepted. Don’t know if it will in the future but, for sure when standards exist, then multiple wallets can coexist while you implement only one standard in your app.

Meanwhile, as I also pointed out in my previous message, if you are interested to implement such an experience now, you can have a look to existing wallets which, I guess, implement their own interaction scheme such as Plug and other existing wallets. See for example this list.

Hope that helps.