In the proposed idea, will it be possible for a specific dApp to configure login via II in such a way that it prevents logging into the dApp if there is a linked OpenID account? For example, some dApps might decide to trust only passkeys added as they are now. If something is linked to the II (e.g., a Google account), such an II might be considered less secure, given that some Google accounts can potentially be compromised through SMS or recovery email.
I believe such decisions can and will be made by dApps.
The idea above is different in the regard that a linked OpenID account is still allowed but a dapp can require that an additional security factor like a passkey is required.
Such an approach would scope the security requirements of the dapp to the interaction with the dapp itself. Of course at this point, this is still an idea, we’re looking into various ideas around this topic.
Yes, an in between party will be needed in most scenarios. Either a centralised decentralised inbetween like the Internet Identity, that is, one II service for the whole of ICP. Or inbetweens deployed together with applications, as currently is the case for ic-siwe. In a web2 scenario, there is also the inbetweening happening, when the OpenID service calls back to the app API to inform it of a successful authentication.
Yes, as would adding OpenID support to II.
If you want to support wallets for one chain only, that is all good. That is what using WalletConnect or Wagmi or RainbowKit for Ethereum helps you with. But, in the chain fusion world we envision for IC, we must assume that apps want to be support users logging in using “any” wallet they prefer. The reasoning is easy: If we create applications that can interact with 20+ chains, then the users will come from 20+ chains. Therefore we should support them logging in with wallets from 20+ chains.
Above example is a bit extreme. But, supporting more than, like 2 wallet discovery libraries in your frontend is a really bad idea. Just integrating one is often painful enough as they are often bloated things needing to support all different wallet quirks on a specific chain.
This I 100% buy. We don’t offer OpenID as a “main” way to authenticate with IC apps. Instead, the main offering remains: “Login to this application using Internet Identity” with the added “ps. Now you can also create an Internet Identity using OpenID”. Reasonable and a great addition.
OpenID on the IC
Yep, this is a very attractive idea that would also more closely mimick how you currently build a web2 project. You as the developer selects which auth providers you want to support for your app. You add some glue code and configure those providers but mostly, it just works.
Applying a similar approach to IC apps. You as the developer chooses the providers. You can select from a number of prebuilt provider canisters for anything from Ethereum to Twitter login. You add the providers you need to your dfx.json and deploy them with the rest of your project. Each provider hosts their own authentication UI so you need to add very little to your frontend codebase. In the frontend you only use a library very similar to @dfinity/auth-client. You display some login buttons, on click the auth client opens up the right provider authentication UI in a separate window/iframe. A callback from that window is made when authentication has finished.
So, basically the exact flow as with Internet Identity but taking into account the fact that Internet Identity will ever be only one of many authenication providers. The best thing with this flow is that it is mostly already in place, tried and tested with Internet Identity. Some smaller adjustements would only need to be made to enable it:
Upgrade the “protocol” used by a frontend interacting with Internet Identity to a documented standard
Extend auth-client to support many auth providers.
Custom settings per provider need to be supported
The did of auth provider canisters does (maybe) not need to be specified as it is ever only being called by its own custom bundled frontend.
Having an in between canister would move the efforts of implementing all the different chain authentications to another frontend. The underlying issue doesn’t disappear, it only moved. And now a dapp dev isn’t in control of this frontend to add other chains when needed
Within the Identity & Wallet standards WG we split the issue into two layers:
Transport: how to establish communication with the wallet / identity provider?
Messages: how to communicate with the wallet / identity provider?
Both layers are different for every single chain, each creating their own standards, so one way or another we’d end up creating bridges between these standards. As of now, there’s no solution yet to this issue, and creating a universal standard isn’t a solution that worked up till now
This is what the ICRC-25 signer standard and its extensions are attempting to standardize. But II isn’t compliant yet with this standard at this moment. OISY, Plug, NFID and other wallets/identity providers are already compliant.
The WG standards are still ongoing and being adopted as we speak, so for now we’re still in between with adoption and libraries used, documented and promoted. Though since ICRC-25 is an actual standard, a dapp isn’t required to use a specific lib anymore, a dapp developer could implement it from scratch following the standards if they intend to.
Good point, we didn’t go into that detail yet in the WG, I’ll bring it up in the next meetings.
It sounds like ICRC-25 together with ICRC-29 and ICRC-34 covers the authentication flow I am talking about quite well. Great!
There is some misunderstanding here. I am not proposing to build one UI that integrates all other wallets, that would indeed just move the issue. One ICRC-25 compatible provider canister per chain would be the way to go. And since I deploy the canister with my project I can configure it on deployment just as I would when integrating the wallet connection library directly. To exemplify, for an ETH ICRC-25 provider canister I would want to be able to set the “WalletConnect project ID” and configure which wallets (or all supported) to allow.
And no, new universal standards . Even though ICRC-25 could be said to be just that.
To me it sounds like it would be totally doable to upgrade the current ic-siwe provider canister to become ICRC-25 compatible. And the same could be done for ic-siwb, ic-siws, etc. And, of course, if someone wants to build a standalone OpenID provider, that could also be given a ICRC-25 wrapper.
Eventually, we want there to a be a library that allows app developers to use any ICRC-25 compatible provider easily. Maybe that is the goal of NFID IdentityKit? The library will support a number of default providers (Oisy, Plug, NFID, Internet Identity and so on). In addition to that you should be able to configure it to connect to “custom providers” that you deploy with your project.
I’ll try to join in on the WG call soon to listen in on the latest.
Yes IdentityKit is a framework that already implements the user interface, error handling, sessions and other details around wallets interaction with the ICRC-25 standard.
I love the possibility of adding OpenID as an additional II authentication method.
As a [current] web2 ecosystem developer exploring web3 user authentication methods, I am looking at both II and NFID. One (but not the only) current benefit of NFID is the ability for the user to use an email address to sign-in, whereas II requires the user to identify as a number, which can be jarring to a web2 user who has no/limited experience with web3.
Q: With the addition of OpenID in II, would the first step in the II sign-in process still require the user to select their identity as a number, and then chose their OpenID Auth method? TYIA
Wow! This would be a game-changer for mainstream adoption, especially for consumer DApps.
At RuBaRu, we’re currently working on integrating Google OAuth2 Sign-In for our Native Android and iOS DApps. We’ve already made progress in designing and developing the necessary services, combining stateless off-chain and on-chain components tailored to our use case. For now, we’re using delegation to generate identities, but a fully extended version that handles session expiry, session refresh, and dedicated anchors would be amazing! Could this also serve as a dual recovery mechanism?
For example, Firebase Auth keeps delegates authentication to Google Auth while managing session tokens, ensuring seamless token refresh even when the DApp is inactive.
Hey, what are the chances of the OpenID integration going on the roadmap? Any idea on timeline if it does? Also what does this mean for projects that have integrated NFID, will there be any UX improvements beyond what has already been achieved?
Delegations are still restricted by their set lifetime when issued from the II popup/tab. So at this moment, a user would still need to go through this flow again once the delegation has expired.
We’re already working on the OpenID integration within Internet Identity. We’re working on updating the public roadmap, it should be updated approximately at the end of the month.
Internet Identity and NFID are both different projects, the implementation efforts within Internet Identity are unrelated to NFID.
As for a comparison between the II and NFID Google sign-in implementations, both will have the same UX that follows the OpenID standards, but the underlying technical implement will likely differ in certain details. Only difference in UX that comes to mind is that II uses the FedCM API where supported instead of a popup.
Makes sense! By the way, if I recall correctly, Firebase uses serverAuthCode to handle expired tokens by exchanging it for a refresh_token. This refresh_token allows fetching new idTokens before they expire. However, I believe client applications should have the flexibility to implement their own custom strategies as per their need.
II could probably refresh the OpenID token silently, but this won’t make a difference for dapps interacting with II. Since those don’t have access to this OpenID token, the delegation flow with II remains the same for dapps.
Within the current ongoing implementation, II is not using refresh tokens, but an implicit flow to directly get an OpenID token for security reasons. The idea here is that the interaction between OpenID and II is only once to get a delegation to be used for further II interactions. This avoids the need to send and validate the JWT on every II canister method.
Yes, we’ve also implemented (currently under testing) Google Sign-In in the RuBaRu DApp using the same approach you suggested (one-time delegation creation). It appears to strike a good balance between usability and security.
Hello everyone, exciting news! We’ve just launched “Login with Gmail” in the RuBaRu App. Enabling, even Web2 users to enjoy seamless onboarding. We’ve implemented a simple mechanism where your Gmail is used to assign a principal upon successful Google authentication (just once!), and this principal will be used for all future interactions with the platform.
. Even though ICRC-25 could be said to be just that.