Skip to content

LG-16327 Update ssn logic ial2 match sp#12326

Closed
kevinsmaster5 wants to merge 15 commits intomainfrom
update-ssn-logic-ial2-match-sp
Closed

LG-16327 Update ssn logic ial2 match sp#12326
kevinsmaster5 wants to merge 15 commits intomainfrom
update-ssn-logic-ial2-match-sp

Conversation

@kevinsmaster5
Copy link
Copy Markdown
Contributor

@kevinsmaster5 kevinsmaster5 commented Jul 9, 2025

🎫 Ticket

Link to the relevant ticket:
LG-16327

🛠 Summary of changes

Ensure the restriction of duplicate SSN checks to only those IAL2 accounts that are associated with SP (Service Provider) connections that have opted into the upcoming OneAccount functionality.

Builds upon previous #12296

@kevinsmaster5 kevinsmaster5 marked this pull request as ready for review July 9, 2025 19:19
@kevinsmaster5 kevinsmaster5 requested a review from vrajmohan July 9, 2025 19:27
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The initiating_service_provider_issuer is merely the service provider who initiated the identity verification. The current service provider may be different.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am now comparing the Profiles against the current session sp with a3e5ee0

@kevinsmaster5 kevinsmaster5 force-pushed the update-ssn-logic-ial2-match-sp branch from 7a680db to a3e5ee0 Compare July 14, 2025 15:41
@kevinsmaster5 kevinsmaster5 requested a review from vrajmohan July 14, 2025 16:07
@vrajmohan
Copy link
Copy Markdown
Contributor

I'm not seeing how this fixes the issue either.

Say there are 2 service providers: SP1 and SP2. SP2 and SP3 are in eligible_one_account_providers.
Profile P1 with SSN SSN1 that was initiated by SP1 and later used by SP2.
Profile P2 with the same SSN (SSN1) that was initiated and later used by SP2.
This should be detected as a duplicate when an IAL2 with facial match is requested by SP2.

I don't see a way to detect this without using sp_return_logs.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use different service providers? The "inactive" in the name is misleading.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the service provider generated by the factory with create(:profile, :facial_match_proof
https://github.com/18F/identity-idp/blob/main/spec/factories/profiles.rb#L105-L108

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, but that does not make it any better. It is wrong there as well.
That is an inactive service provider, which is used in tests like

context 'when the service_provider is not active' do
. It does not cause harm here but is unnecessary misdirection.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, I am cleaning up the existing problem here - #12377.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. I'm revising in my tests to avoid that as you requested.

@vrajmohan
Copy link
Copy Markdown
Contributor

Also, the merged PR appears to have modified DuplicateSsnFinder#ssn_is_unique?. That method is not relevant for the One Account work and should be left alone.

See Cloudwatch query for loss of information.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Puts this method back to where it was before per
#12326 (comment)

Comment on lines 18 to 26
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Profile.joins(:sp_return_logs)
.active
.facial_match
.where(ssn_signature: ssn_signatures)
.where(sp_return_logs: { issuer: sp_eligible_for_one_account })
.where.not(user_id: user.id)
.distinct
Profile.joins("INNER JOIN identities ON identities.user_id = profiles.user_id")
.active
.facial_match
.where(ssn_signature: ssn_signatures)
.where(identities: { service_provider: sp_eligible_for_one_account })
.where(identities: { deleted_at: nil })
.where(identities: { ial: 2 })
.where.not(user_id: user.id)
.distinct

@kevinsmaster5 kevinsmaster5 requested a review from a team July 18, 2025 17:50
@kevinsmaster5
Copy link
Copy Markdown
Contributor Author

@kevinsmaster5 kevinsmaster5 force-pushed the update-ssn-logic-ial2-match-sp branch from 0bb6bd8 to a53be99 Compare July 22, 2025 14:04
Copy link
Copy Markdown
Contributor

@vrajmohan vrajmohan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we would be better served by ensuring that the tests map to the spreadsheet with the combinations that we have created.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, but that does not make it any better. It is wrong there as well.
That is an inactive service provider, which is used in tests like

context 'when the service_provider is not active' do
. It does not cause harm here but is unnecessary misdirection.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need the session_uuid set?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's now removed from both _spec

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why have the identities associated only in this context and not in the sibling contexts? In fact, having these be associated in the next context should demonstrate that the code is wrong because the test fails.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added more tests with 857818b
These cover the spreadsheet mockup users 1 - 4. Users 5 & 6 would not ever reach the duplicate_ssn_finder class because they would be eliminated at

return unless user_has_ial2_profile? && user_sp_eligible_for_one_account?

User 5 is covered with this test
context 'when user does not have active IAL2 profile' do

User 6 is covered with
context 'when user does not have other accounts with matching profile' do

yarn.lock Outdated
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What JavaScript changes are we making to cause this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My local NPM must have done something strange. I'll revert that.

@kevinsmaster5 kevinsmaster5 force-pushed the update-ssn-logic-ial2-match-sp branch from fa5db11 to 58cd50e Compare July 30, 2025 14:13
Copy link
Copy Markdown
Contributor

@vrajmohan vrajmohan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am sorry but we don't appear to be converging: This still does not address the fundamental issue of duplicates within the requesting service provider. This will be clear if the requesting service provider from the Reduced Version spreadsheet is SP2 instead of SP1. In that case, User 3 should not come up as a duplicate when requesting for User 1 or User 2.

There are several other issues as well:

  1. The test cases are not clear
  2. Unnecessary fixture setup of session_uuid: SecureRandom.uuid
  3. Repeated context in test of "describe '#associated_facial_match_profiles_with_ssn'".
  4. Test assertion of specific profile ids with no sort specified.

Sorry to do this, but I'm creating a separate PR that leverages some of this work and that hopefully addresses all these issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants