Change the SEP24 flow to authenticate recurring users

[vadaynujra]

Context

The ARS anchor needs to be able to identify and authenticate recurring users to provide a compliant off-ramp service.

To do

• Add changes to SEP24 to include use the memo field such that the user doesn't need to reenter login details.

Additional info:
Memo info would be saved with the user and user does not need to reenter bank data etc. again
Can the tx come from the same user (vortex) and individual users are only identified through the memo

[TorstenStueber]

The idea would be to use the same account (owned by us) for all SEP-10 authentication and distinguish users only be a text memo. The question is how to derive this text memo? We could hash their Polygon account and use the maximal initial segment we can use for a memo (or use a technique similar to Spacewalk, where we also extract information from an address to fit into a text memo).

[vadaynujra]

Identifying the users - we can choose the approach, as long as we're using the memo field
KYC-ing the users - stays with anchor

[gianfra-t]

I can think of:

• A subset of the hash of the account like you say.
• A subset of the account itself.
• A subset of the hash of the signature from the challenge we will provide. I do not know which one has higher entropy and randomness. Probably the latter?

On a related topic, I already tried a few things on the client domain PR. Could the full flow be something like this?:

• Send a random challenge
• User signs and sends the signature back.
• Derive the text memo.
• If okay, we fetch and sign the challenge from the anchor with corresponding memo, and our main account as source account.
• We return either the jwt or the signed challenge to the UI.

This is disregarding the "free use of our Client App" issue I'm still not sure about.

[TorstenStueber]

The question is whether we want to let the user sign another request in their wallet (UX not so nice this way) to prove their ownership of the Polygon account. I would argue that could skip this at this phase of the project.

[prayagd]

The question is whether we want to let the user sign another request in their wallet (UX not so nice this way) to prove their ownership of the Polygon account

I would say we should include this can keep this in the start itself when the user connects the account they sign this request. Pretty standard now in all dApps.

I would argue that could skip this at this phase of the project.

Would skipping this introduce any security issues?

[prayagd]

Hey team! Please add your planning poker estimate with Zenhub @b-yap @ebma @gianfra-t @TorstenStueber

[TorstenStueber]

Would skipping this introduce any security issues?

Someone could impersonate an existing user without this check. But we also decided that we will do the check now.

[ebma]

Just for the sake of it, I'll share my proposition here again:

• We ask the user right after they connected their wallet account to sign some arbitrary data. Maybe terms or whatever we want.
• We store the signature in local storage, possibly with the date so we can invalidate it at some time in the future if we wanted to.
• Before doing the SEP authentication, Vortex checks the local storage for that signed string, and if it doesn't exist, triggers the request for signing again.

This way, a user doesn't have to sign three times in a row. Also, users are used to some dapps asking for a signature when connecting I think.

[prayagd]

I agree to the above solution from Marcel

[prayagd]

Also if i understand correctly this is done through SEP 10 right? Should we change the title of the ticket?

[gianfra-t]

It is related to sep 10 @prayagd you are right, but it also propagates to sep 24 so I don't think there is a need.

@ebma 's idea is quite nice, but I've been thinking how exactly it would look and I have a few questions that we can discuss here @pendulum-chain/devs and @pendulum-chain/product.

We could implement directly a sort of log in with web 3 feature as soon as the user lands. In my mind, this will just replace the Connect button and this third signature will feel less like yet another signature appearing from nowhere and more a traditional login. So a very small deviation to the original idea but with a different "feel".

And as long as the user uses the same address, there is no need to re-sign if the user changes networks. Alternatively we could change the network before asking for the signature/log-in.
The downside of this, is that if the user wants to change addresses, it needs to sign yet again. Let me know if this sounds like a reasonable approach since I would like to start implementing this today.

[ebma]

Sounds good but I wouldn't want to trigger the 'login' right when the user lands but only when they decide to connect a wallet. Polkassembly has a similar login. If you click on the Login button on the top right-hand corner, they will ask you to select an account and sign a string so that they can verify it's you. Being forced to connect a wallet to do just about anything on the dapp seems a bit intrusive to me. Maybe I just want to play with the available currencies, enter some data, check out the quotes, whatever.

The downside of this, is that if the user wants to change addresses, it needs to sign yet again.

Right, but I think it's okay if we do that. If we consider a wallet-connection/selection to be similar to a login, then changing the wallet is similar to changing an account and it should be fine to ask for a signature again.

[gianfra-t]

I wouldn't want to trigger the 'login' right when the user lands but only when they decide to connect a wallet.

Totally agree, I was thinking exactly the same. By replace the button I meant replace it with a login button.

Let's try!

[ebma]

Let's do it 👍

[TorstenStueber]

We store the signature in local storage

That would mean that when switching to a different account and back again the user would need to sign again, unless we store multiple (account -> signature) associations in the local storage.

Apart from that I agree with @ebma!

[ebma]

Do you think we should cover that too @TorstenStueber? It shouldn't be difficult to have a mapping but I would assume that our users don't switch accounts too often.

[TorstenStueber]

Yes, let's start simple and just store the current account and signature.