Hi, this might be a stupid question, but I’ve got a doubt. Has anyone or any dApps of the community implemented a login flow** using Stoic or Plug wallet? Or are those solutions primarily and only used by the community as wallets to sign and execute transactions?
** By login flow, I mean a process such as sign-in, sign-out, synchronizing the authentication, or calling the IC with an identity and an agent derived from the login action. Something commonly implemented with Internet Identity or NFID.
I’m trying to do that right now with Plug. Plus there is Artemis wallet connector, which also does that for a whole bunch of wallets, including Plug and Stoic.
What is your concern?
Btw, is Stoic even maintained? It looks exactly the same as 3 years ago.
2 Likes
Not really a concern, but some developers on the Juno Discord expressed an interest in supporting Stoic and Plug for sign-in purposes. Since adapting the related JS library would require some work, I was curious to know, before starting implementation, if such a login flow is actually possible and if anyone in the community did implement such a flow with those.
In the WG there’s ICRC-32 for signatures, combined with either:
You can register a public key on your server and for login send the signature (and optional delegation chain) to your server and verify these.
Standard might still change and hasn’t been implemented in most yet wallets. Neither is there any documentation regarding this available at this moment.
Thanks, did not thought about using the standard in that way, good call. That said I’m interested about the current state - i.e. has anyone already implemented a login flow using those providers? Maybe no one indeed…
NFID is actively implementing the standards, also Plug is working on implementing them as far as I’m aware. Haven’t heard anything regarding Stoic.
But for wallets that return a delegation like II and Stoic, you could already implement a signature + delegation validation approach.
Given a key pair public1 and private1, you store public1 on the server and to login you then sign a random challenge with private1, this signature is sent to the server which then verifies it with public1.
With a delegation chain it’s basically the same approach but the account private key isn’t available to sign the challenge with directly.
Given a delegation chain: 3 → 4 → 5, this delegation chain contains public key 3, a signature from private3 with public4 as challenge, public4, a signature from private4 with public5 as challenge and lastly public5. You store public3 on the server and to login you then sign a random challenge with private5, this signature and the delegation chain are sent to the server which then verifies the signature with public5 and the delegation chain with the IC root key.
The libraries from my earlier post both basically implement the signature (and delegation) verification mentioned in the steps above. As for signing the challenge, you can do this with the sign method on the Identity instance (same one as you’re passing to HttpAgent).
I’d be curious to get your and @sea-snake’s take on this.
I think we need to give devs better guidance of the auth instrument they use based on their dapp’s use case.
Thanks for the ideas and details, awesome!
However, just to be clear, my questions in this thread is not about the “how”, it’s really strictly about knowing if anyone in community already implemented a flow with Stoic or Plug?
Nothing less, nothing more. But again, great inputs!!!
Hi, here is the wallet adapter built by SonicDex: GitHub - sonicdex/artemis: dfinity wallet adapter for connecting different wallets in IC. While building DeAI, we are also creating our own wallet adapter that will support TypeScript and standardize those wallets a little bit more accurately.
1 Like
If you’re interested in standardizing wallet interaction, please join the WG calls, here we’re trying to solve this issue from the wallet side, so hopefully per wallet custom adapters implementations are no longer needed at some point.
Feel free to reach to me on Discord(same username) for an introduction/questions.
1 Like
Thanks so much, @patnorris! This has been helpful.
Contrary to my initial thoughts, it means that one project has indeed implemented a login flow with Plug and Stoic, not just a wallet flow.
Additionally, the source code you shared was really valuable. It confirmed my initial concerns, in terms of effort, that once signed in with these vendors, each actor needs to be initialized in a specific way, which sounds like a bummer 
.
PS: DecentralizedAIonIC 
2 Likes
Sure thing, happy if it was helpful
Yes, especially the setup for the browser extension-based login options was more custom from my experience.
1 Like