LG-15216 Handle password reset for in-person enrollments waiting for fraud review #11855

shanechesnutt-ft · 2025-02-07T19:33:20Z

🎫 Ticket

Link to the relevant ticket:
LG-15216

🛠 Summary of changes

Enable user's to not lose in-person enrollment progress after a password reset when the user in fraud review.

Changes Include:

New InPersonEnrollment status in_fraud_review
New metric for GetUspsProofingResultsJob enrollments_in_fraud_review
Update to the action account scripts to update relevant in-person enrollments base on result

📜 Testing Plan

In-Person Password Reset enabled

Set feature_pending_in_person_password_reset_enabled: true in application.yml.default

Scenario: Fraud review in-person enrollment and user password resets with personal key

Login through the oidc sinatra application selecting the Identity Verified level of service.
Create a new account
Complete the ID-IPP flow reaching the ready ssn page.
Mark the threat metrics as review on the ready ssn page.
Submit the ssn form.
Continue the ID-IPP flow reaching the ready to verify page.
Run the GetUspsProofingResultsJob

# To manually run the job in the rails console run the following:
job = GetUspsProofingResultsJob.new
job.perform(Time.zone.now)

Ensure the enrollment is updated to have in_fraud_review status.
Ensure user is navigated to the LG-99 screen.
Logout
Reset the password of the user.
Login through the oidc sinatra application selecting the Identity Verified level of service.
Ensure user is prompted for personal key entry
Enter in user's personal key
Ensure user is navigated to the LG-99 screen

Scenario: Fraud review in-person enrollment and user password resets without personal key

Login through the oidc sinatra application selecting the Identity Verified level of service.
Create a new account
Complete the ID-IPP flow reaching the ready ssn page.
Mark the threat metrics as review on the ready ssn page.
Submit the ssn form.
Continue the ID-IPP flow reaching the ready to verify page.
Run the GetUspsProofingResultsJob

# To manually run the job in the rails console run the following:
job = GetUspsProofingResultsJob.new
job.perform(Time.zone.now)

Scenario: Fraud review in-person enrollment and user password resets before deployment

Checkout main and start the idp application
Login through the oidc sinatra application selecting the Identity Verified level of service.
Create a new account
Complete the ID-IPP flow reaching the ready ssn page.
Mark the threat metrics as review on the ready ssn page.
Submit the ssn form.
Continue the ID-IPP flow reaching the ready to verify page.
Run the GetUspsProofingResultsJob

# To manually run the job in the rails console run the following:
job = GetUspsProofingResultsJob.new
job.perform(Time.zone.now)

Scenario: Fraud review in-person enrollment and user has passed review

Login through the oidc sinatra application selecting the Identity Verified level of service.
Create a new account
Complete the ID-IPP flow reaching the ready ssn page.
Mark the threat metrics as review on the ready ssn page.
Submit the ssn form.
Continue the ID-IPP flow reaching the ready to verify page.
Run the GetUspsProofingResultsJob

# To manually run the job in the rails console run the following:
job = GetUspsProofingResultsJob.new
job.perform(Time.zone.now)

Ensure the enrollment is updated to have in_fraud_review status.
Ensure user is navigated to the LG-99 screen.
Run the review-passed script bin/action-account review-passed <user_uuid>
Ensure the enrollment is updated to have passed status.
Ensure the user is prompted to activate their account.

Scenario: Fraud review in-person enrollment and user has failed review

Login through the oidc sinatra application selecting the Identity Verified level of service.
Create a new account
Complete the ID-IPP flow reaching the ready ssn page.
Mark the threat metrics as review on the ready ssn page.
Submit the ssn form.
Continue the ID-IPP flow reaching the ready to verify page.
Run the GetUspsProofingResultsJob

# To manually run the job in the rails console run the following:
job = GetUspsProofingResultsJob.new
job.perform(Time.zone.now)

Ensure the enrollment is updated to have in_fraud_review status.
Ensure user is navigated to the LG-99 screen.
Run the review-reject script bin/action-account review-reject <user_uuid>
Ensure the enrollment is updated to have failed status.
Ensure the user is redirected to the unverified page.

In-Person Password Reset disabled

Set feature_pending_in_person_password_reset_enabled: false in application.yml.default

Scenario: Fraud review in-person enrollment and user password resets

Login through the oidc sinatra application selecting the Identity Verified level of service.
Create a new account
Complete the ID-IPP flow reaching the ready ssn page.
Mark the threat metrics as review on the ready ssn page.
Submit the ssn form.
Continue the ID-IPP flow reaching the ready to verify page.
Run the GetUspsProofingResultsJob

# To manually run the job in the rails console run the following:
job = GetUspsProofingResultsJob.new
job.perform(Time.zone.now)

Ensure the enrollment is updated to have in_fraud_review status.
Ensure user is navigated to the LG-99 screen.
Logout
Login through the oidc sinatra application selecting the Identity Verified level of service.
Ensure user is navigated to the LG-99 screen.
Logout
Reset the password of the user.
Login through the oidc sinatra application selecting the Identity Verified level of service.
Ensure user is navigated to the welcome page

WilliamBirdsall · 2025-02-11T15:49:03Z

app/models/user.rb

@@ -223,9 +223,9 @@ def in_person_enrollment_status
    pending_profile&.in_person_enrollment&.status
  end

-  def ipp_enrollment_status_not_passed?
+  def ipp_enrollment_status_not_passed_or_in_fraud_review?


This method could benefit from a comment / usage doc since it's public.

fixed in 2edd2c2

shanechesnutt-ft · 2025-02-11T15:49:37Z

app/services/usps_in_person_proofing/enrollment_helper.rb

      #
      # @param user [User] The user model
-      def cancel_establishing_and_pending_enrollments(user)
+      def cancel_in_progress_enrollments(user)


I am going to update this method to cancel_establishing_and_in_progress_enrollments to remove confusion as to what an in_progress enrollment means. See user model current_in_progress_in_person_enrollment_profile method for consistency. Which leads me to think I should add IN_PROGRESS_ENROLLMENT_STATUSES to the InPersonEnrollment model to help establish this.

Updated in 2edd2c2

gina-yamada · 2025-02-12T16:27:31Z

app/controllers/idv/welcome_controller.rb

@@ -62,8 +62,9 @@ def create_document_capture_session

    def cancel_previous_in_person_enrollments
      return unless IdentityConfig.store.in_person_proofing_enabled
-      UspsInPersonProofing::EnrollmentHelper


Is check IdentityConfig.store.in_person_proofing_enabled needed? (I know this code predates you and you did not change it.)

If we disable in_person_proofing_enabled because of an outage and the user begins again, wouldn't we want a clean slate even if they are not able to move through ipp? Can you think of any disadvantages to deleting the check?

This is a good question. I'm not (yet) sure where I fall on this topic, but I am curious to hear more about it.

Cc @matthinz because I feel like this is the type of thing we discussed recently. This method is called from the welcome controller's update method.

I think that makes sense, but I feel that this change would be better in a different PR/User Story.

cc: @eileen-nava

@shanechesnutt-ft Would you be up for writing a ticket to address this feedback in a separate PR?

WilliamBirdsall · 2025-02-12T16:36:50Z

Ran through all test steps successfully! Great job with this :)

gina-yamada · 2025-02-12T17:01:32Z

app/models/user.rb

-    pending_in_person_enrollment&.profile ||
-      profiles.where.not(activated_at: nil).order(activated_at: :desc).first
+  def find_in_person_in_progress_or_active_profile
+    current_in_progress_in_person_enrollment_profile || find_active_profile


Originally, the only behavior was to find an active profile. When we enabled the epic, the default behavior will be to find an in person in progress or active profile. What do you think about changing the order of this so the default is to first look for an active profile because that was the original behavior? I think it would have a smaller affect on pw reset. (If for some reason in person enrollments was not getting cleaned up properly at some point- it would have a small impact because it would only happen if there was not an active profile.) I did not consider this in your previous pr.

What are your thoughts?

find_active_profile || current_in_progress_in_person_enrollment_profile

So in the last Password Reset PR I prioritized the pending profile first because when the personal key is generated for a profile it will replace the previous personal key. This can occur when the user has an active legacy profile and a pending non-legacy profile. My logic was that since the personal key is replaced, the previous active account is dead when the user performs a password reset. So, rather than having them lose both profiles I would prioritize the latest profile (the pending profile) which would allow the user to use their latest personal key.

@jmhooper does this sound reasonable? I know you reviewed the last PR and this didn't come up. I just wanted to make sure the way this is implemented makes sense.

@gina-yamada Good question! I agree with Shane's explanation and logic. Please feel free to say if you have more questions about this.

Shane and I walked through this together prior to his post yesterday. He posted for visibility. I am okay with this now that I have more information. Thank you

eileen-nava

Approved, this looks good.

eileen-nava · 2025-02-12T16:50:34Z

app/controllers/idv/welcome_controller.rb

@@ -62,8 +62,9 @@ def create_document_capture_session

    def cancel_previous_in_person_enrollments
      return unless IdentityConfig.store.in_person_proofing_enabled
-      UspsInPersonProofing::EnrollmentHelper


This is a good question. I'm not (yet) sure where I fall on this topic, but I am curious to hear more about it.

eileen-nava · 2025-02-12T16:57:48Z

app/forms/reset_password_form.rb

@@ -104,7 +104,9 @@ def extra_analytics_attributes

  def pending_profile_invalidated?
    if FeatureManagement.pending_in_person_password_reset_enabled?
-      pending_profile.present? && !pending_profile.in_person_verification_pending?
+      pending_profile.present? &&


Thanks for updating this.

eileen-nava · 2025-02-12T16:59:48Z

app/jobs/get_usps_proofing_results_job.rb

@@ -142,8 +143,7 @@ def check_enrollment(enrollment)

  def cancel_enrollment(enrollment)
    enrollment_outcomes[:enrollments_cancelled] += 1
-    enrollment.cancelled!
-    enrollment.profile.deactivate_due_to_in_person_verification_cancelled
+    enrollment.cancel


spec/controllers/concerns/idv_step_concern_spec.rb

eileen-nava · 2025-02-12T19:09:17Z

spec/controllers/idv/please_call_controller_spec.rb

+        allow(IdentityConfig.store).to receive(:in_person_proofing_enforce_tmx).and_return(false)
+      end
+
+      it 'returns nil' do


Tests look clear and thorough.

eileen-nava · 2025-02-12T19:20:45Z

spec/forms/reset_password_form_spec.rb

+          it 'includes that the profile was not deactivated in the form response' do
+            expect(@result.extra).to include(
+              user_id: user.uuid,
+              profile_deactivated: false,


👍🏻 to testing this

eileen-nava · 2025-02-12T19:22:22Z

spec/forms/reset_password_form_spec.rb

+          let(:profile) { enrollment.profile }
+
+          before do
+            @result = form.submit(params)


I have a question about test syntax and will follow up in a synchronous 1:1.

eileen-nava · 2025-02-12T19:27:10Z

spec/lib/action_account_spec.rb

+        let!(:profile) { enrollment.profile }
+
+        before do
+          subtask.run(args:, config:)


I have a question about test syntax and will follow up in a synchronous 1:1.

eileen-nava · 2025-02-12T19:29:42Z

spec/models/in_person_enrollment_spec.rb

@@ -509,6 +518,7 @@
      expect(expired_enrollment.eligible_for_notification?).to eq(false)
      expect(passed_enrollment_without_notification.eligible_for_notification?).to eq(false)
      expect(failed_enrollment_without_notification.eligible_for_notification?).to eq(false)
+      expect(in_fraud_review_enrollment.eligible_for_notification?).to eq(false)


eileen-nava · 2025-02-12T20:24:03Z

spec/services/usps_in_person_proofing/enrollment_helper_spec.rb

-        subject.cancel_establishing_and_pending_enrollments(user)
-      end
+        before do
+          subject.cancel_establishing_and_in_progress_enrollments(user)


I have a question about test syntax and will follow up in a synchronous 1:1.

eileen-nava

Changes look good. 👍🏻

eileen-nava · 2025-02-13T16:10:53Z

app/jobs/fraud_rejection_daily_job.rb

@@ -5,6 +5,7 @@ class FraudRejectionDailyJob < ApplicationJob

  def perform(_date)
    profiles_eligible_for_fraud_rejection.find_each do |profile|
+      profile.in_person_enrollment&.failed!


changelog: User-facing Improvement, In-person Proofing, Allow users to perform a password reset on pending in-person profiles in fraud review without losing progress if the user supplies their personal key.

- Update enrollment helper method based on changes

gina-yamada · 2025-02-13T21:08:06Z

spec/lib/action_account_spec.rb

+        end
+
+        it 'passes the enrollment and activates the profile' do
+          expect(enrollment.status).to eq('passed')


👏 Thanks for this spec! I was checking to ensure we updated the InPersonEnrollment status so it was no longer in_fraud_review.

n1zyy

Sorry for not getting to this sooner. There's a lot to make sense of here but it looks good, and I'm grateful that this long-standing issue causing users pain is being fixed. 👏

I have a couple of questions inline, but I'm giving this an approval conditional on the answer not being "Oh no everything is broken." 😉

n1zyy · 2025-02-13T20:22:53Z

app/models/user.rb

@@ -223,9 +223,14 @@ def in_person_enrollment_status
    pending_profile&.in_person_enrollment&.status
  end

-  def ipp_enrollment_status_not_passed?
+  # Whether the user's in person enrollment status is not passed or in_fraud_review. Enrollments use


Suggested change

# Whether the user's in person enrollment status is not passed or in_fraud_review. Enrollments use

# Whether the user's in person enrollment status is not passed or in_fraud_review. Enrollments used

The most trivial nit ever, but my eyes noticed it.

n1zyy · 2025-02-13T20:36:07Z

app/services/usps_in_person_proofing/enrollment_helper.rb

@@ -91,13 +91,15 @@ def cancel_stale_establishing_enrollments_for_user(user)
          .find_each(&:cancelled!)
      end

-      # Cancel a user's associated establishing and pending in-person enrollments.
+      # Cancel a user's associated establishing, pending, and in_fraud_review in-person enrollments.


Oxford comma FTW!

n1zyy · 2025-02-13T20:43:38Z

app/jobs/get_usps_proofing_results_job.rb

@@ -641,7 +641,7 @@ def send_enrollment_status_sms_notification(enrollment:)
  end

  def notification_delivery_params(enrollment)
-    return {} unless enrollment.passed? || enrollment.failed?
+    return {} unless enrollment.passed? || enrollment.failed? || enrollment.in_fraud_review?


I feel like I've gotten rusty in this section of code. Is the intent here to start sending delayed notices of fraud-review status? It's just not obvious to me what the significance of this is.

Yeah this isn't very obvious, but in the code before when the user passed at the post office and had been flagged for fraud review we would update the in-person enrollment to have a status of passed and send the please call email. In this PR we are changing things up a little bit by adding the new in_fraud_review status. We wanted to keep the same behavior with sending the email in the same way (with a delay) so I had to add the status check here.

n1zyy · 2025-02-13T20:59:20Z

lib/action_account.rb

@@ -281,6 +282,7 @@ def run(args:, config:)
        elsif FraudReviewChecker.new(user).fraud_review_eligible?
          profile = user.fraud_review_pending_profile
          profile_fraud_review_pending_at = profile.fraud_review_pending_at
+          profile.in_person_enrollment&.passed!


This is another "Apologies that I don't remember this so well..." one, but I'm trying to make sure I understand what happens here in non-obvious cases.

If I have an IPP enrollment, but don't actually go to the post office because I'm a fraudster, this won't mark me as a pass because I'm not fraud_review_eligible?, right?

If I get in one of the muddled states where I abandon IPP, and continue with doc auth and get myself into fraud review, this won't mark me as passed because I don't have an enrollment, right?

This is a case where I think the logic is good but I just want to make sure we're not accidentally creating a vulnerability.

Yeah that seems to be correct because user has not been to post office for their enrollment/profile to be updated. IPP enrollments profiles are not updated with a fraud_review_pending_at timestamp until the user goes to the post office.

Yeah think that is also the case because the profile associated with the enrollment would be different from the one associated with doc auth. I can do some checks around this today. What exactly to do you mean by "muddled states where I abandon IPP, and continue with doc auth"? I want to make sure I test this case correctly.

gina-yamada · 2025-02-13T21:56:31Z

@shanechesnutt-ft
👌 For Scenario: Fraud review in-person enrollment and user password resets without personal key: An LG-99 email was delivered immediately after I reset my PW and just after the PW reset email "got delivered". I would not expect this email to be delivered again. ~~Double check if you observe this. (I feel like it should have occurred in test 1 as well but I may have just missed it.) Maybe a question for product if you see this behavior too.~~

UPDATE: After looking at the code, this email is only kicked off from the USPS job and is on a delay. I think just funny timing.

shanechesnutt-ft requested review from a team and WilliamBirdsall February 7, 2025 19:33

shanechesnutt-ft force-pushed the sc/LG-15216 branch 2 times, most recently from d8e42d5 to 4ccd4e7 Compare February 10, 2025 15:58

WilliamBirdsall reviewed Feb 11, 2025

View reviewed changes

shanechesnutt-ft commented Feb 11, 2025

View reviewed changes

gina-yamada reviewed Feb 12, 2025

View reviewed changes

WilliamBirdsall approved these changes Feb 12, 2025

View reviewed changes

gina-yamada reviewed Feb 12, 2025

View reviewed changes

eileen-nava approved these changes Feb 12, 2025

View reviewed changes

eileen-nava reviewed Feb 13, 2025

View reviewed changes

jmdembe approved these changes Feb 13, 2025

View reviewed changes

mdiarra3 approved these changes Feb 13, 2025

View reviewed changes

shanechesnutt-ft added 6 commits February 13, 2025 15:21

LG-15216 Handle password reset for in-person enrollments in fraud review

924badc

changelog: User-facing Improvement, In-person Proofing, Allow users to perform a password reset on pending in-person profiles in fraud review without losing progress if the user supplies their personal key.

Cancel in_fraud_review enrollments when user does not have personal key

0531588

Minor code clean up

a894405

Add in progress enrollment statuses to InPersonEnrollment models

6352e2d

- Update enrollment helper method based on changes

Minor test clean up

b9ec889

Update daily fraud rejection job

38a2b86

shanechesnutt-ft force-pushed the sc/LG-15216 branch from 23b9af9 to 38a2b86 Compare February 13, 2025 20:21

gina-yamada reviewed Feb 13, 2025

View reviewed changes

n1zyy approved these changes Feb 13, 2025

View reviewed changes

Documentation fixes

fc44f72

	# Whether the user's in person enrollment status is not passed or in_fraud_review. Enrollments use
	# Whether the user's in person enrollment status is not passed or in_fraud_review. Enrollments used

LG-15216 Handle password reset for in-person enrollments waiting for fraud review #11855

Are you sure you want to change the base?

LG-15216 Handle password reset for in-person enrollments waiting for fraud review #11855

Conversation

shanechesnutt-ft commented Feb 7, 2025 • edited Loading

🎫 Ticket

🛠 Summary of changes

📜 Testing Plan

In-Person Password Reset enabled

In-Person Password Reset disabled

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shanechesnutt-ft Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WilliamBirdsall commented Feb 12, 2025

gina-yamada Feb 12, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gina-yamada Feb 13, 2025 • edited Loading

Choose a reason for hiding this comment

eileen-nava left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eileen-nava left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

n1zyy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gina-yamada commented Feb 13, 2025 • edited Loading

shanechesnutt-ft commented Feb 7, 2025 •

edited

Loading

shanechesnutt-ft Feb 11, 2025 •

edited

Loading

gina-yamada Feb 12, 2025 •

edited

Loading

gina-yamada Feb 13, 2025 •

edited

Loading

gina-yamada commented Feb 13, 2025 •

edited

Loading