LG-13761: ProofingComponents to store real vendor used to verify document PII by lmgeorge · Pull Request #11499 · 18F/identity-idp

lmgeorge · 2024-11-12T21:41:30Z

Why

Prior to this change, we always stored 'aamva' in a User's proofing_components.source_check column regardless of whether a call to AAMVA was made or not. Accuracy is good and storing the actual "vendor_name" will align our analytics across our events.

How

Instead of hard-coding vendor_name in proofing_components.source_check, we dig into the result object (as produced by the ResultAdjudicator) for the actual vendor_name. This value should always be present even though we don't have any validators for it.
This makes testing a little messier, but cleaning up the various vendor names in our specs should be done in future work. For now, a new constant with the known source_check names has been added (Idv::Constants::Vendors::SOURCE_CHECK).
No new specs have been added as the functionality hasn't changed, but one end-to-end feature test has been updated to check the vendor name is in the expected list.

changelog: Internal, Analytics, Store correct vendor name in ProofingComponents

🎫 Ticket

Link to the relevant ticket:
LG-13761

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

Complete IdV using the unsupervised remote path
Complete IdV using the in-person proofing path (where your residential address == your id address)
Complete IdV using the in-person proofing path (where your residential address != your id address)

lmgeorge · 2024-11-12T21:44:38Z

app/services/idv/proofing_components.rb

A/N: This seems less than ideal, but there doesn't seem to be any good means to pulling the supplied vendor_name out like I did in the VerifyInfoConcern#add_proofing_components method.

I think there are 2 options here:

Add a value to the session to indicate whether we performed an AAMVA check and use that

Inspect the value of the issuing jurisdiction in pii_from_user or pii_from_doc and infer from that whether AAMVA was contacted

Option 1 may be slightly preferable since it stores the result of what the job actually does. The weakness is it involves adding another value to the session. As a result we'll need to break this into 2 deploys. One deploy to write the new value and a second to read and use it.

Okay, I think I've addressed this here, so let me know what you think!

lib/idp/constants.rb

n1zyy

Not leaving an approval as this is still marked as a draft and Hooper's comment implies a pending change, but 👍 to where it's at so far.

lmgeorge · 2024-11-18T19:48:23Z

app/controllers/concerns/idv/verify_info_concern.rb

A/N: I feel like these two methods could be merged into an handle_success_updates_for_idv_session method, but leaving as is for now.

lmgeorge · 2024-11-18T19:49:31Z

spec/services/idv/proofing_components_spec.rb

A/N: Is there a better way to test this or is the captured by the end_to_end_idv feature spec?

I think the VerifyInfoController (or the VerifyInfoConcern? I'm not sure which) should have a test asserting that the value in the result object is propagated to the Idv Session

You are right, will add that now.

The closest we get to validating the result object is in the end_to_end_idv feature spec -- we have a method, #validate_verify_info_submit, that validates the ProofingComponents structure, but not much else.

With respect to the controller specs, we primarily look at what value was logged in the event (with the exception of our threatmetrix status specs).

For now, I've updated the VerifyInfoController spec to look at what was logged in the state_id stage and am open to expanding the coverage here.

app/services/idv/session.rb

matthinz · 2024-11-18T20:30:07Z

app/controllers/idv/in_person/verify_info_controller.rb

Do we have any specs for these undo_step things that need to be updated? Or do we just test this as a side effect of other tests

As far as I can tell, we test undo state primarily as a side effect and only test defaults for individual classes.

(I was waiting for the pipeline to complete to verify that assumption, so taking a look now)

Yep, seems like undo step validation is primarily tested through feature specs.

n1zyy

This is a nice fix, and it cleans up formatting a bit as well!

app/services/idv/session.rb

spec/services/idv/proofing_components_spec.rb

app/controllers/concerns/idv/verify_info_concern.rb

n1zyy · 2024-11-18T21:26:22Z

lib/idp/constants.rb

(Possible bikeshedding) Is there a clearer name for this? I.e., SOCURE and LEXIS_NEXIS are sources that we check; can we make it obvious why they don't belong in this array? STATE_ID_SOURCE_CHECK?

Suggesting only in case you agree or have a better idea; I don't feel strongly at all here.

I was on the fence about what to call this, but I wanted the relationship between this and ProofingComponents#source_check to be clear and deeply coupled.

I went back and forth about asking for state_id_source_check, but the idea here is: you have given us a document of some kind. we then verify it with the issuing source. right now that is a drivers license + AAMVA. In the near future, hopefully, that will be other document types + other verifiers.

Basically, source_check is probably good

…ment PII **Why** * Prior to this change, we always stored 'aamva' in a `User`'s `proofing_components.source_check` column regardless of whether a call to AAMVA was made or not. Accuracy is good and storing the actual "vendor_name" will align our analytics across our events. **How** * Instead of hard-coding `vendor_name` in `proofing_components.source_check`, we dig into the result object (as produced by the `ResultAdjudicator`) for the actual vendor_name. This value should always be present even though we don't have any validators for it. * Adds `:source_check_vendor` field to `Idv::Session` to capture the vendor name actually utilized to validate the state ID attributes. * Pulling `vendor_name` from the result object makes testing a little messier, cleaning up the various vendor names in our specs should be done in future work. For now, a new constant with the known `source_check` names has been added (`Idv::Constants::Vendors::SOURCE_CHECK`). * No new specs have been added as the functionality hasn't changed, but the relevant specs, including one end-to-end feature test, have been updated to check the vendor name is in the expected list or matches a placeholder value. changelog: Internal, Analytics, Store correct vendor name in ProofingComponents

matthinz · 2024-11-19T21:37:00Z

app/services/idv/proofing_components.rb


    def source_check
-      Idp::Constants::Vendors::AAMVA if idv_session.verify_info_step_complete?
+      idv_session.source_check_vendor


I think we need to tweak to account for the 50/50 state:

Suggested change

idv_session.source_check_vendor

idv_session.source_check_vendor || (Idp::Constants::Vendors::AAMVA if idv_session.verify_info_step_complete?)

(you can probably come up with a better / more ruby-ish way to do ☝️ )

Basically, if the key is not in the session, we need to fall back to the old (bad) way

matthinz · 2024-11-19T21:38:51Z

spec/controllers/idv/verify_info_controller_spec.rb

      let(:errors) { {} }
      let(:exception) { nil }
-      let(:vendor_name) { :aamva }
+      let(:vendor_name) { 'aamva_placeholder' }


will not approve without emoji vendor name

matthinz

All this looks good, just the one 50/50 state thing

lmgeorge added the status - work in progress label Nov 12, 2024

lmgeorge requested review from jmhooper and matthinz November 12, 2024 21:41

lmgeorge commented Nov 12, 2024

View reviewed changes

lib/idp/constants.rb Outdated Show resolved Hide resolved

lmgeorge requested a review from a team November 12, 2024 21:45

lmgeorge force-pushed the lmgeorge/LG-13761 branch from 83f1022 to dd97fcc Compare November 12, 2024 22:02

lmgeorge changed the title ~~LG-13671: ProofingComponents to store real vendor used to verify document PII~~ LG-13761: ProofingComponents to store real vendor used to verify document PII Nov 12, 2024

lmgeorge force-pushed the lmgeorge/LG-13761 branch from dd97fcc to 41597e5 Compare November 12, 2024 22:21

n1zyy reviewed Nov 15, 2024

View reviewed changes

lmgeorge commented Nov 18, 2024

View reviewed changes

lmgeorge marked this pull request as ready for review November 18, 2024 19:50

matthinz reviewed Nov 18, 2024

View reviewed changes

app/services/idv/session.rb Outdated Show resolved Hide resolved

matthinz reviewed Nov 18, 2024

View reviewed changes

n1zyy approved these changes Nov 18, 2024

View reviewed changes

lmgeorge added status - ready for review ruby Pull requests that update Ruby code and removed status - work in progress labels Nov 18, 2024

lmgeorge requested a review from matthinz November 19, 2024 17:17

lmgeorge force-pushed the lmgeorge/LG-13761 branch from 804fb5b to dfe0ab6 Compare November 19, 2024 20:11

lmgeorge force-pushed the lmgeorge/LG-13761 branch from dfe0ab6 to 67fcdeb Compare November 19, 2024 20:16

matthinz reviewed Nov 19, 2024

View reviewed changes

Handle 50/50 state for new Idv::Session key

8a84353

jmhooper approved these changes Nov 20, 2024

View reviewed changes

lmgeorge merged commit fa0524f into main Nov 20, 2024

lmgeorge deleted the lmgeorge/LG-13761 branch November 20, 2024 16:16

aduth mentioned this pull request Nov 21, 2024

Deploy RC 433 to Prod #11538

Merged

	idv_session.source_check_vendor
	idv_session.source_check_vendor \|\| (Idp::Constants::Vendors::AAMVA if idv_session.verify_info_step_complete?)

Conversation

lmgeorge commented Nov 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🎫 Ticket

📜 Testing Plan

Uh oh!

lmgeorge Nov 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

n1zyy left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

n1zyy left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matthinz left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

lmgeorge commented Nov 12, 2024 •

edited

Loading

lmgeorge Nov 12, 2024 •

edited

Loading