Optionally persist email OTP verification

[r00dgirl]

So that respondents will not have to repeatedly verify their email if their job is to complete many form submissions at one go - repeated data submission by authorised persons only e.g.

• referral forms
• logging of assets
• test result reporting

maybe:

• include session id when creating transaction object, look up before creating new transaction
• if transaction exists, prefill verified email field(s) and indicate verified
• refresh to clear fields or detect field edits to reset fields in transaction object
• on Thank You page, also show ~ "If you are done submitting forms, please close your browser tab to end this session securely"
• transaction has 4h expiry currently, ideally OTP verification has closer to 1h expiry similar to SPCP

optionally:

• allow user to check Remember me for next submission on frontend, which is by default unchecked
• if Remember me is checked in submission, session Id is saved to transaction obj. if it is not checked, session id is updated to null.
• Remember me is also checked by default on the next submission

[frankchn]

As a first step, I wonder if we can set a JWT-based session cookie containing the formId, the verified contents of the field (e.g. email or phone number), and an expiry time when a verification request succeeds.

The next time the user enters the same verified contents and tries to do verification, we immediately considers the verification to succeed if the JWT cookie is present and not send any verification emails or SMS. The session ends when the user closes the browser window or tab.

Next, we can get the client to read the JWT and pre-fill the relevant fields if possible.

[liangyuanruo]

Discussion

1. Figure out how to have this work with E2EE and webhooks
2. To cater for public library use case

[frankchn]

For my own reference, most of the logic for verification is in https://github.com/opengovsg/FormSG/blob/develop/src/app/modules/verification/verification.service.ts

[frankchn]

An implementation might be:

1. Upon request in verifyOtp, we generate a signed and encrypted cookie containing the verified recipient string and type (i.e. a phone # or an email) and an expiration time, and we store that cookie on the client.
2. When the client next requests an OTP with sendOtp, we check whether that cookie exists, and if it does, decrypt it and compare the verified recipient string to the new recipient. If it all checks out, we return the signedData immediately instead of sending the SMS. If it doesn't, we proceed as usual.

We will need an additional checkbox after the user clicks "Send SMS" etc to ask the user whether they want to persist their "verification" for the browser session or next 30 minutes.

[frankchn]

Here is a more detailed doc describing a potential workflow: https://docs.google.com/document/d/1tayeHx1oBJbsgw0uKhuZB9RQ7xaSrpVKo8UnICwTCUk/edit?usp=sharing

[tshuli]

Moved to linear