Improve use of correlation ID

[peterjah]

Context
The correlation ID is used to allow a dApp to send several operations when use is signing only one request.
Today, this behaviour is hidden from the user point of view, and it is also quite risky in term of security because the dApp can send any operations without the explicit user approval.

There is to aspect to focus on:

• transparency regarding what the user accept when signing
• security: implement restrictive rules that defines what the dApp is allowed to do with the correlation ID

Tasks

• Inform the user that he is accepting a batch of operations
• implement different rules to restrict the allowance scope
• When new rules are implemented in backend, make the according evolution in frontend

Idea of rules

• restrict the total number of operation allowed
• restrict the time until the correlation id is valid
• restrict the type of operation allowed
• for callSC, restrict the SC(s) that can be called
• identify the dApp and check that batched operations are sent from the same origin

[longgamma-massa]

@gregLibert @peterjah @Thykof

With Pierre we propose the following way for 'upload website' feature:

• User can't sign multiple operations at once. He must sign the following by himself each time:

1. Deploy website storer SC (Execute SC?)
2. Call DNS contract to register domain name (Call SC)
   (on this step we verify if the domain name is taken. coins are taken from the user on step 2 even if we get an error.)
3. Upload chunks (Call SC?). In case of multiple chunks, at this step we can batch operations, as it makes sense to as user to sign all chunks at once. But user must be aware of it.

All this needs to be presented before first signing request to the user. So frontend refactoring is needed of the right-side panel.

---

Follow up tasks would include:

• Allow user to enable signing operations without password in Settings. This way we improve the UX for quite some.
• Allow user to enable signing without password, when a dApp first calls the Wallet for signature.
  This is like a checkbox to tick to enable 'Sign operations without password from this dApp'.
• Error that 'a domain name is taken' must be shown to the user before signing the first operation.

We need to decide on the approach so share thoughs :)

[gregLibert]

What do you mean by sign ? Does this means that the user need to type in his password 3 times to deploy a website ?

[longgamma-massa]

If we stay like this yes. If we add the ability for user to choose to sign without providing a password (for specific or all dApps) we remove the need to type passwords.

That'd be the 1st follow-up task.

[longgamma-massa]

This is an industry standard. Users are given possibility to choose whether to enter passwords each time or not.

[gregLibert]

I think that the 1st task on this subject is more about informing the user that a batch of transactions is being signed.
Then we could go two directions:

• avoid having to type again the password for a given duration, but the opeartion still need to be validated
• frame the eligible transactions to be part of the batch by limiting them (for instance, for a specific smart contract...)

Wdyt @peterjah and @longgamma-massa

[longgamma-massa]

From the UX point of you it means things don't change for users functionally, but he must see more information.
@LucasF243 here we need that Scenario 1 described in Figma

[longgamma-massa]

We designed 3 flows.
This is the flow to implement for "Keeping batch operations (user signs once), showing info about operations and fees to user.
Designs: https://www.figma.com/file/LSaOibVDFb1reF6FePVn5l/Massastation?type=design&node-id=6365-27176&mode=design&t=Hp8cwqcX4eQ0YcTj-0

Error implemented for showing 'domain name taken' error before signing: https://www.figma.com/file/LSaOibVDFb1reF6FePVn5l/Massastation?type=design&node-id=6365-27290&mode=design&t=Hp8cwqcX4eQ0YcTj-0