There are three public source code to support derive principal from other chain wallet:
I wonder can some team host one identity provider to support other Dapp rather than fork the code and run by our own?
Pros:
Cons:
I’m working with one of my friends on a service similar to what you described. Right now, the Internet Computer doesn’t have a universal, sufficiently simple identity provider that supports the kind of multi-wallet login you mentioned. Our plan is to build it using DelegationIdentity.
My plan is to prioritize implementing sign-in with a Solana wallet, sign-in with Internet Identity (II), sign-in with BTC, and sign-in with Ethereum, and then expand the service into an extensible identity protocol. It looks complicated, but it’s actually not that hard—everything boils down to writing validators for the different signature schemes. I estimate it will take another two to three weeks to complete this.
That’s pretty helpful, cannot wait to see the release product
How can can prevent if the provider being hacked or owner change the code?
Should we need a DAO for that?
I’ve always felt that for an “identity-extension” protocol (my term for any method of logging into the IC with a non-II wallet), the core job is simply to supply an identity that can interact with IC canisters. All the more complex features—such as linking multiple wallets—should be built on top of that protocol, not baked into it.
So my plan is for the protocol to do only two things:
Nothing else. Keep the protocol as minimal and focused as possible. What do you think?
@borovan what do you think?
However, it might also be feasible to commercialize this Infura-style service, because the protocol keeps expanding. We could have users send ICP to the canister to subscribe to the service—essentially turning it into a B2B product.
B2B sound good for me. But ideally this shouldn’t be centralize
It is great if at least 6-7 teams participate on this service
You’re absolutely right—we should promote this protocol to the community (for example, by adding it to ICP development tutorials) and get it adopted by as many existing IC projects as possible.
In the next couple of days I’ll post a demo in this thread that shows how MetaMask log-in verification works, and we can use this thread to coordinate development. Since it’s a purely community-driven product, I’ll also share details soon on how it operates and how to extend it.
Once we feel we’ve moved past the development stage, we can officially launch it to the community. I expect that will take about a month.
Hi, to begin with, I am a big believer in making it easier for ICP users to sign in with their authentication method of choice. That might Internet Identity, Metamask SIWE, Phantom SIWS, XVerse SIWB.. or any other authentication methods: Google, X, Okta, whatever..
It all depends on the context and the application, what authentication method is the appropriate within the current context.
One thing I am advocating for internally is that ICP should offer an abstraction layer on top of Internet Identity to make it easier for app developers to use more than on authentication method in an app.
Also excited to see community initiatives around this.
The path you describe comes some risks though.
- Principal derive from dapp can share between apps,
eg: user connect bitcoin wallet on kongswap can use the same principal in odin fun
Allowing the user to use the same principal for many apps is a MAJOR security risk. In the scenario you describe, Odin.fun could essentially do swaps on KongSwap for the user without their consent. And vice versa, KongSwap could launch some memecoins on Odin.fun without your approval. And, this might be fine (it really never is) if you trust the parties involved 100%. But, one day you login to some other, less trustworthy service using the same principal and the minute later both your KongSwap and Odin.fun accounts are empty.
On Ethereum, users login to different services using the same address. And, that is fine. Because, there is no shared delegated identity between those services. The JWT token you get from logging in to service A cannot be used to access service B. And, any onchain interactions requires you to approve with your wallet.
So, for comparison, the ICP delegate identity is like the JWT token for a web2 service. And, for the same security reasons, you need a unique JWT token / delegate identity for each service.
So does that mean that when using a DelegationIdentity, we need to create a different principal for each dapp to ensure security?
I think your concern is right but we already have thing like ICRC-34 with account delegation. We can limit the canister that services can access by define target for the delegation identity
If we need made a call to canister if they’re not in the targets of delegation identity, we can use
ICRC-49. But I’m not sure how other chain wallet will interacting with ICRC-49 standard
If that’s the case, a unified identity layer might need to take additional factors into account. Still, I’ll write up my approach so the community can keep discussing how to build it.
Yes, it is good practice to set the target of your delegated identities to your app canisters and no other.
So, I just wanted to add another factor to consider. In the case of IC-SIWE and IC-SIWS, by logging in you create a secure link between your IC principal and your ETH / SOL address. This means, even though you have different IC principals for different apps, you still “act” as the same ETH / SOL address.
If app 1 and 2 trust each other, they can still share data, or even allow update calls from the principal belonging to the other app (provided its target allows it).
user -> app 1: siwe_login(eth:0x123)
app1 -> user: app1identity
user -> app 2: siwe_login(eth:0x123)
app1 -> user: app2identity
user(app1identity) -> app 2: callsomefunction() // app1 id used to call app2
app2 -> app1: get_address(app1identity) // app2 asks app1 which address id is connected to
app1 -> app2: adress is eth:0x123
app2 : perform action on behalf of eth:0x123
The key difference from Internet Identity is that here, you have a stable identifier that spans more than one app (the eth address). This way you retain full control over which apps can interact with each other.
Other kinds of stable identifier services could easily be built on top of IC. One low hanging fruit would be to create something along the lines of ENS. Or maybe even simpler, a username service. Register your username once, use it in many places.
The existence of stable user identifiers would radically simplify for composability on IC. For example, someone could build a generic “Comments” section app, that can easily be added to any app. If your app lets users authenticate with the “ENS of IC” it would automatically be compatible with a bunch of other apps and features that use the same stable uder identifier.
To summarise:
I know your concern about delegate identity share between apps.
With end-user they just know they have different principal between dapp, if they’re using nft or tokens on IC they have to transfer the asset from app1 to app2 which is not a good ideal. Also if developer of app1 and app2 have to implement their own wallet page which is add more complex
What I think we need to have
