SaFi Bank Space : Use the app on new device

Epic: SM-1814 - IAM: Use the app from new device Rework requested

JIRA: SM-1838 - Use the app on new device Rework requested

Priority:

Effort estimate:

Review status: in preparation/ready to review/approved

As a Customer I want to be able to have access from the new device so that I can continue using the app.

In order to successfully complete using the app on a new device, Customer will need to go through other measures provided by the alternative scenarios.

Role: Customer

Objective: Login in from the new device using registered credentials

Reason: fraud prevention and device anti-duplicity check

Functional requirements:

• Customer cannot login with only credentials (password/passcode) on a different device.

• To decide whether the used device is different, we utilize device fingerprinting (from AAI).

• Customer cannot be logged in from two or more different devices at the same time

UI requirements:

Process flow:

Execution steps:

Internal dependencies: Device fingerprint using Advance AI

External dependencies: n/a

Alternative scenarios: If device fingerprinting does not match, the user is directed to the face matching (step-up).Login to app with face matching (Step-up)

Acceptance criteria:

• Customer cannot login with credentials only

• After installing app on the new device, Customer can access using registered credentials only if device fingerprinting matches

• If device fingerprinting is not matching or not registered customer continues process with Face Matching (Step-up)

Links to wireframes/UI: n/a

Technical Assessment

We agreed on 15 Dec, 2022 that a single flow will be used for the case when the old phone (and old app) is available and when not. This could change later.

Registration of New Key with LEVEL3 Step-up

Similar to the Bypass login flow, the customer fetches the customerId based on the phone number (for security reasons an OTP need to be verified). Then a new key is registered on the new device and specially associated to the customer. A modified version of the step-up procedure with face comparison is executed on the new device that allows the use of the newly registered keys. The last step is a LEVEL3 authenticated call to replace the credentials of the customer (refer to https://safibank.atlassian.net/wiki/spaces/ITArch/pages/211419176/Forgotten+password#Technical-Assessment).

Note that if the customer’s phone number is new, they should start with calling CC where the phone number is updated.

High Level Flow

Notes:

• Both the ‘Provide credential ID to app' and the 'Generate and register keys’ flows can be found at https://safibank.atlassian.net/wiki/spaces/ITArch/pages/70484094/Register+passcode#Technical-Assessment

• The 'Forgotten password' flow can be found at https://safibank.atlassian.net/wiki/spaces/ITArch/pages/211419176/Forgotten+password#Technical-Assessment

UX

Assignments

OTP & Customer ID

1. Add a new endpoint to customer-manager: POST /v1/customers/otp to initiate SMS OTP

   1. Phone number should be in verified state.

   2. Endpoint should not be protected.

   3. Should not report error in case of an unknown phone number or any errors in sending the SMS - this is a security measure.

   4. (optional / later) Should be rate limited - this is a security measure.

2. Add a new endpoint to customer-manager: POST /v1/customers/id/by-otp to return the customer_id if the OTP is valid.

   1. This should allow a single successful invocation (next calls even with a valid OTP should return error) - if there is network error / etc such that the customer_id is not received by FE, the OTP flow need to be repeated.

3. If needed, modify customer-manager's POST /v1/customers/resend-otp to support this use case, too.

Credential Registration

1. Modify iam-manager's /credential endpoint to allow creating a new credential when there is already a credential assigned to the customer_id.

   1. Add the new state NEW_DEVICE to the credential states.

   2. Set the state of the newly added credential to NEW_DEVICE. Send an audit log message that a new device registration procedure has been started. (TODO: audit log details)

   3. It is allowed to have multiple credentials in state NEW_DEVICE for a single customer. If this is the case, send an audit log message that multiple new device registrations are in progress. (TODO: audit log details)

Assign New Credential

1. Update iam-manager's /credential/replace, /face-comparison and /face-comparison/check endpoints to allow the use of a signed request with a key in NEW_DEVICE state.

   1. Fetch the key from the DB even if it is in state NEW_DEVICE and try it for signature verification.

   2. Use iam-auth-lib's signature check functionality unmodified to verify the signature.

2. Update iam-manager's /credential/replace endpoint

   1. When called with LEVEL1 signature

      1. Use the credential_id as the challenge_data when requesting step-up.

   2. When called with LEVEL3 signature

      1. Check that the challenge_data matches the credential_id used for this call.

      2. Revoke the old credential (in local DB) - this may already been revoked, see notes below

      3. Update the new credential’s state from NEW_DEVICE to IN_PROGRESS.

      4. Revoke the customer’s all other credentials in NEW_DEVICE state.

      5. If the above is successful, revoke the old credential in VIDA - this may already been revoked, see notes below

Notes

• The solution does not care (from the viewpoint of this flow) whether the old key has already been revoked by slacker (e.g. due to some very risky situation) or by BOFE (e.g. when the customer called and CC agent revoked it) or anyone else. The flow does not depend on the validity or the old key.

• All other endpoints (of all other domains) are unaffected since the key that they can use is the one in IN_PROGRESS state (and we only invalidate the old key in the last step of the flow).

Background Info

OTP

• onboarding flow:

  1. POST /v1/customers/sign-up - LEVEL1 auth, customer must be PROSPECT

  2. POST /v1/customers/resend-otp - LEVEL1 auth, customer must be PROSPECT_AND_CUSTOMER

  3. POST /v1/customers/verify-otp - authorizeCustomerUpdate???, customer must be PROSPECT_AND_CUSTOMER

• bypass login uses /v1/customers/id/by-phone which is unprotected

TODO

• why did we need multiple active / non active credential returns (for the forgotten passwd)?

• make it clear what to do / allow when used with the IN_PROGRESS and NEW_DEVICE keys

Archives

Transfer ownership

If the application on the old device is fully functional, we can sign the request of the new key registration on the old device and this way properly authenticate the request (with step-up if required for this functionality). The way of transferring data from the old device to the new may be through a simple QR code or a more sophisticated one like the swarm code when transferring data from an old iOS device to a new one.

The key element in the process is the credentialId (refer to https://safibank.atlassian.net/wiki/spaces/ITArch/pages/70484094/Register+passcode#Technical-Assessment for details). A request can be signed (in the old app) that allows resetting the credentialId for a customer. Idea: reuse https://safibank.atlassian.net/wiki/spaces/ITArch/pages/211419176/Forgotten+password+WIP#Technical-Assessment with LEVEL2 auth (or higher if required).

Then the new credentialId and the customerId need to be transferred to the new phone (via the aforementioned QR code) and the new app can register the new key with the new credentialId via VIDA SDK.

Notes:

• The new app may need to fetch other info from BE to configure itself properly or (part of) this data can be also transmitted from the old device (via the aforementioned QR code).

• The keys can not be extracted from the phone (if hw support is available and the keys are properly generated), so the simple OS level phone restore should not solve the task, that is why we need this procedure.

  • The key generation / store proof can be received via key attestation. One reference is PKI Consortium’s overview of support of this in different platforms: https://github.com/pkic/remote-key-attestation

• After the key invalidation, the old app becomes unusable because the old credentialId has been revoked. This means that the old app can not execute any request that requires a valid signature.

Details

1. [BE] Modify https://safibank.atlassian.net/wiki/spaces/ITArch/pages/211419176/Forgotten+password+WIP#Technical-Assessment to

   1. require LEVEL3 only if it was called with LEVEL1 auth (the original use case for the forgotten password)

   2. execute the “Replace old Credentials“ subflow when LEVEL2 auth is present.

2. [FE-OLD]

   1. Create a screen / menu item etc. that starts the procedure with signing the request with LEVEL2 auth (or LEVEL1 if step-up is required based on business decision).

   2. FE receives the new_credential_id from BE (see #9 in the sequence diagram) and together with the customerId (and any other data) the FE generates and displays a QR code (or any agreed other code).

3. [FE-NEW]

   1. Create a screen / menu item etc. that shows the camera and waits for a successful decode of the QR code (or any other agreed code).

   2. Executes the key registration and password setup process with the received credentialId via the VIDA SDK (refer to #10-13 in the sequence diagram).

Forgerock solution