feat: secure information handling

[weboko]

This is a feature request

Problem

There is always a risk of XSS happening and someone taking away the credentials of a user. It becomes more critical in the scope of RLN when credentials might be stored on js-waku side.

Proposed Solutions

This is more exploratory work where we should look into:

• [ ] since waku messages are plain we can look into providing utility to guard against XSS;
• [ ] explore passkey API in browsers if is it possible to use it for safer storage of creds;
• [ ] create an entity in our code (package or class) to handle safer / persistent storage of some information (creds etc);

note: passkey might not be a storage per se but a source of information for following credentials generation etc.

This might not be needed right now but could be a good building block for the future. It is worth exploring already implemented solutions out there and maybe re-using them.

One potential solutions are researched we should follow up with research if necessary.

Notes

Useful links: passkey, MetaMask

[weboko]

Problem

Right now @waku/rln has two points of contact with RLN identity.

Registering

As it is written here in order to register RLN identity with @waku/rln consumer should:

1. sign a message by using wallet;
2. using signed message as a seed - generate an identity;
3. use this identity to register on RLN contract;
4. save it as Keystore for later use;

Seeing this it is clear that dependency on the wallet exists only because of a need to create a seed by signing a message.

Using identity

Once RLN identity is saved in the Keystore format it can be passed to @waku/rln like done here to be used by the library for proof generation like setup here and usage here.

But there are couple problems:

• Keystore format should be decrypted so that password should come with it, here;
• Keystore should be stored somewhere and after decryption should not be leaked;

This makes it poor to be re-used in a web app at the very least.

Solution

Let's use passkey. It is a pair of public/private keys that securely stored on a device and can be shared with others and more importantly - comes with great UI on various platforms - browsers / iOS / Android. We can use it for addressing problem with RLN identity generation and following usage of it.

Registering

With passkey we would eliminate dependency on wallet and can generate a seed directly with it by either signing some message or doing something else:

const signature = [passkey].sign(same message);
const identity = this.zerokit.generateIdentityCredentials(signature);
// registration

Using identity

Here comes a nice bonus of not having to store any Keystore and we can reliably re-generate RLN identity again by using passkey from the device.

Limitations

Main limitation is passkey are domain or application specific meaning they won't be re-used so if user has a RLN identity at a website - it won't be possible directly re-use it so new identity would be needed to be created.

Potential mitigations:

• once user wants to re-use identity - it can be exported in a Keystore format but later usage would be more complicated;
• maybe there is a way to duplicate passkey across different domains - doesn't seem secure;

Next steps

We can try to make a PoC to and have an example app in lab.waku.org to showcase it.

In order to bring it to production we need to understand:

• (if no mitigation) how problematic is to have user creating identity for each Waku powered app they use;
• if there is any request for it to become part of the library, since it is possible for consumers to build on top;

[danisharora099]

passkeys look pretty cool! a POC would be fun

---

on a side note: since they are quite new, how do you think about the education + onboarding part should be handled by us?