LG-7012 LG-7010 Add/Integrate new DDP Proofer

[stevegsa]

Why: To add several lexis nexis fraud based indicators via products such as fraudpoint, EmailAge, device fingerprinting, etc. and eventually have the DDP proofer be a drop in replacement for RDP proofer used at the InstantVerify step (so we would not have to make 2 api calls). Initially this call will be made before InstantVerify and the RDP instantverify step will be left alone. Note that DDP and threatmetrix are sometimes used synonymously. RDP is the legacy platform that runs instant verify, phone finder, true id. DDP is their new platform where we will call threatmetrix.
How: Use the proofing framework provided in Proofing::Base and Proofing::LexisNexis:Proofer. The proofing call will call all the relevant products behind the scenes via one API call in DDP using the Session Query API https://portal.threatmetrix.us/kb/implementation/apis/session_query_api.htm . It will piggyback on the existing async ResolutionProofingJob adding new params: user_id (to get email), and threatmetrix_session_id from #6694 for device profiling. Add a feature flag lexisnexis_threatmetrix_enabled to call threatmetrix before instant verify. Note the new fields added to resolution proofing will be: threatmetrix_session_id (a unique session identifier created with the front end added LexisNexis javascript for device profiling, etc.), email, and the PII packet now uses drivers_license_number (like the previous AAMVA document check which validates the actual drivers license info with the state if the state supports it). We dup the instant verify PII packet and add in the extra PII values and package it up for the call to DDP. All this info allows lexis to formulate a risk score. The job will continue to instant verify regardless of if the threatmetrix results or score and further on in the flow the user will face a sad screen upon fraud detection.

How to test this locally:

Update application.yml to:

development:
lexisnexis_threatmetrix_api_key: XXXX <--- fill these in
lexisnexis_threatmetrix_base_url: XXXX
lexisnexis_threatmetrix_org_id: XXXX
lexisnexis_threatmetrix_enabled: true
proofing_device_profiling_collecting_enabled: true

The proofers: document (trueid), resolution (instant verify), address (phone finder) are mocked by default (proofer_mock_fallback: true) so you can go through the verification process with bogus data (images,etc.). But we want the threatmetrix live locally so just hardcode out that mock on the lexisnexis_ddp_proofer memoization line:

def lexisnexis_ddp_proofer
    @lexisnexis_ddp_proofer ||=
      if false # IdentityConfig.store.proofer_mock_fallback <- forcibly skip mock

Probably unwise to add in code to make it run locally (and override the global mock flag) with another feature flag as we might accidentally set one live in the lower environments where mocking is necessary.

Create an account and on the account screen type in the path /verify and verify your identity up to the confirm information screen.

After submitting there you should see an entry in (async jobs) workers.log:

{"name":"ThreatMetrix","user_id":"f36cef72-199c-48c1-9c1c-6bf915d29124","threatmetrix_request_id":"ddp-mock-transaction-id-123","threatmetrix_success":true}

Note: request_id can be used with LN to track individual calls. In costing it's added to transaction_id. On Lexis legacy system this was conversation_id.

Remember that not all test data in idv is equal. You can feed it specific scenarios to generate pass/fail conditions noted here: https://developers.login.gov/testing/

Assumptions: a decision was made not to send phone even though we have it with users that have a phone mfa already configured.

Notes: username, password are part of the legacy rdp that used basic auth. the new ddp uses api keys and org id. Also workflow modified the path associated with the request in the legacy rdp system (instant verify, etc.). We are calling one endpoint here so no workflow is required.

[jskinne3]

I like the idea of self-documenting code as much as the next person, but I don't think we have achieved that here. I don't know what, for example, metric_name and stage :resolution designate. The code's purpose is also not explained; there is no mention of device fingerprinting, for example. Could we clarify with code comments?

[zachmargolis]

this will return for network failures only right? (we still want to continue with the proofing process if we successfully hear back from LN but get a negative result)

[stevegsa]

ah yes. we spoke about this today. it should always continue if fraud check fails and no it doesn't return on network failures because all exceptions are caught. i'll change it so it proceeds on failure. let me know if threatmetrix network failures should stop instant verify and I'll add that too.

[zachmargolis]

so I see that we're passing user_id, but I think that ActiveJob will correctly serialize/deserialize ActiveRecord models, we should just pass user if we wanted to I think

[stevegsa]

I modeled it after AddressProofingJob which takes user_id

[zachmargolis]

I am not convinced this helper method is worth it?

[stevegsa]

was difficult to test multiple logger calls especially because old instant verify code was doing a partial check. this made it much more simple to test

[stevegsa]

it's also a tad bit DRYer

[jskinne3]

I'm approving this with the proviso that we need to document the testing process at a minimum, and ideally write broader documentation

[zachmargolis]

is there a list of other event types? this is more like an account upgrade typically than an account create

[stevegsa]

[stevegsa]

seems to be the best option. ie create a verified profile

[zachmargolis]

My earlier comment was made for the request fixture, not the response fixture (oops)

But maybe would our specs be easier to maintain if we inlined this into the spec file instead of putting it in a fixture? JSON is easier to inspect than XML

[zachmargolis]

I'd consider extracting methods for these _hash attributes so we could unit test them, which would allow us to check and verify the regexes like state_id_number_for_hash or ssn_for_hash

[stevegsa]

Agree. This particular code is covered but it's quick and dirty.