Ic-siwe: Sign-In With Ethereum support libraries for IC

Developers
6

image
image2722×1934 251 KB

I have opened up access to the repositories I have worked on and would like to share to progress so far of the ic-siwe library and the companion React demo application / template.

Deployed demo

Try out the login flow here, let me know what you think!

https://shtr2-2iaaa-aaaal-qckva-cai.icp0.io

ic-siwe-rust

This is the Rust based library that you use in your canister to enable Ethereum based identities. I have tried to make the integration as compact as possible, here is an example on how to add the three needed endpoints.

// Prepare the login by generating a challenge (the SIWE message) and returning it to the caller.
#[update]
fn prepare_login(address: String) -> Result<String, String> {
    ic_siwe::prepare_login(&address).map(|m| m.into())
}

// Login the user by verifying the signature of the SIWE message. If the signature is valid, the
// public key is returned. In this step, the delegation is also prepared to be fetched in the next
// step.
#[update]
fn login(signature: String, address: String, session_key: ByteBuf) -> Result<ByteBuf, String> {
    ic_siwe::login(&signature, &address, session_key)
}

// Once logged in, the user can fetch the delegation to be used for authentication.
#[query]
fn get_delegation(
    address: String,
    session_key: ByteBuf,
) -> Result<ic_siwe::SignedDelegation, String> {
    ic_siwe::get_delegation(&address, session_key)
}

ic-siwe-react-demo-rust

A demo and a template application to get started using the library.

RFC

I would like to get feedback on the current approach. The ic-siwe library is using certified variables internally to facilitate the delegate identity creation. The library borrows a lot of code from the internet identity codebase here. This all works well, but, it makes it harder if the canister developer wants to use certified variables as that will collide with the certified variable set by the library. This could be mitigated of course. But perhaps the approach is wrong, building this as a library? Perhaps ic-siwe shoud be a canister instead? Not a centralised service such as the Internet Identity but a small drop in, pre-compiled canister that you add to your dfx.json and configure to support your setup. In web2 development, often the authentication runs as a separate microservice. This would be very similar. If ic-siwe ran as a separate canister it could also be configured to allow the session to be valid on more than one canister, simplifying for developers who want to create multi canister applications.

Canister composability rather than canister bloat?! :joy:

Eager to hear your thoughts on this @domwoe @frederikrothenberger @cryptoschindler and all others.

4 Likes