Require ID.me Identify proofing for all DS Logon accounts for DD access (Post DD launch)

[lkoenigsberg]

Due to the direct deposit data breach, remote proofing of DS Logon was disabled.. it was very Knowledge Base Authentication heavy and prone to compromise

In addition, about 3000 DS Logon accounts associated with the breach have been disabled. Those folks will be instructed to go in person to re-enable their accounts

We need to make changes that require ID.me identity proofing for all DS Logon accounts attempting to access Direct Deposit. While putting up more roadblocks, it will help counter any already compromised accounts that were not part of the identified 3000.

Summary
If a user is logged in with DS Logon but has not done ID.me identity proofing, put the user through ID.me identify proofing flow before allowing them to access direct deposit.

Design

• Design Discovery [Scope] Require ID.me Identify proofing for all DS Logon accounts for DD access #2844
• Design/Copy [Design] Create alert for the direct deposit feature that gates DS Logon users #3763

Build

• FE build
• Feature validated on staging

[lkoenigsberg]

@Justin-Pickett , please add this to the DD post launch list of items to take care of.

[Justin-Pickett]

@erikphansen will look into this item. Will follow up if additional information is needed.

[erikphansen]

So the profile itself is gated on the user being verified: https://github.com/department-of-veterans-affairs/vets-website/blob/bd4e32db6f87b800820e8dffdda02c90f0b66414/src/applications/personalization/profile360/components/ProfileView.jsx#L93

I know nothing about DSLogon; is it possible for them to be verified without going through the ID.me ID proofing procedure? Is that what this "remote proofing of DS Logon" is that is mentioned in the ticket description?

[erikphansen]

I just found the thread in Slack that is the root of this issue: https://dsva.slack.com/archives/C909ZG2BB/p1568420910001800

This change is going to be a much larger task than I had initially thought. We need to change the info we get back from the GET user endpoint. Maybe we'd include something like an idmeVerified prop next to verified on the data.attributes.profile object that we get back. That's just the first thing that comes to mind. This is going to be a change on the backend. And I have no idea what that work would look like. Will check with Anna to see what she thinks.

At a higher level: while we have a way to determine if a user is verified, we don't currently have a way to determine which method of verification they used. I currently know of ID.me and DS Logon verification. Maybe there are more? At any rate, the front end needs a way to determine if the user is ID.me verified.

[erikphansen]

Will follow up with @annaswims on Monday regarding the feasibility of expanding the user model to include something that would indicate if the user was verified via ID.me or not.

[erikphansen]

Based on a chat with Anna, we can use the authnContext value that we get from the GET user endpoint to determine if the user was verified via DSLogon. If they are, the value of authnContext is "dslogon". But we don't currently store this value in Redux. So we'll need to:

1. actually store the authnContext in the Redux store
2. gate the DD component on that value: if it's "dslogon" we should prompt them to verify their ID via ID.me
3. likely update the VerifyApp so that users won't be redirected away from it if they are verified via DSLogon; it looks like the VerifyApp will only allow users to access it if they are not verified.

Example showing authnContext: "dslogon":

[erikphansen]

We can now safely ignore my last message. We shouldn't use authnContext at all. This is still TBD, but the backend might expand on the signIn object to also keep track of the verification method. And if a user is DSLogon, we'll need to check with ID.me when they try to access DD to see if they're ID verified with ID.me. If so, we'll show them DD. If not, we'll need to prompt them to verify with ID.me.

[erikphansen]

This ticket should probably be turned into an epic now. It'll be a multi-team effort and might also require some new UX/design work as well.

[Justin-Pickett]

@erikphansen ill work on getting this broken up into a new Epic ticket.

[Justin-Pickett]

@lkoenigsberg will follow up on this item. Will set up a discussion for this item.

[Samara-Strauss]

Going to track design in #2844

[Justin-Pickett]

@samara is it okay to close out ticket 2844 since this ticket is now tracking the design work and any following work that will come from that design work?

[Samara-Strauss]

@Justin-Pickett please turn this into the epic. We'll create design/development tickets as needed for granular tasks.

[Justin-Pickett]

@Samara-Strauss gotcha! WIll do .

[Samara-Strauss]

@lkoenigsberg — After talking with Erik and Anna, we decided that the best way to handle this would be to require DS logon user to sign in with MHV or ID.me to access direct deposit. We talked through other flows that were super complex from a technical perspective, and I think this solution makes the most sense from both a UX and technical perspective. Let me know if you have any questions. We can regroup on this on Monday if you do.

@Justin-Pickett the top comment in this ticket does not need the full checklist for a project epic. Can you please clean this up? This is more of a feature instead of a product/project. We don't need to do a good portion of what's listed (user testing; UAT; reaching out to comms; etc). We really only need a centralized place to track the tickets that have to do with this feature, and for that list to be updated accordingly over time.

Also, you can just type the # sign and ticket number without including the link in order to link to a ticket. You only need to hyperlink if you're linking to a ticket that is in a different repo.

[Justin-Pickett]

@Samara-Strauss okay thank you will do.

[Samara-Strauss]

@lkoenigsberg @chrisj-usds

I circled back with Anna to ask about the following scenario re: gating direct deposit — why someone who is DS Logon LOA3 and ID.me LOA3 wouldn't be able to access direct deposit if they logged in with DS Logon. This was her response:

If a user is DS Logon LOA3 we get that information in the SAML response from id.me, but at this time we don’t have a separate attribute to let us know that they are also LOA3 through id.me.

So currently, we have no way of knowing a user who is logged in with DS Logon LOA3 might be also LOA3 through ID.me. That's why we can't just put a prompt on the profile for DS Logon users to verify their identity — they could do it, but we wouldn't be able to detect this on subsequent visits to the profile.

In theory, I think we could talk about whether we want to add an additional check that would detect whether a user has also verified through ID.me instead of just checking for their highest level of LOA, but this is a larger question for the identity team and that kind of update seems out of scope for this project. It also doesn't seem worth it given our team's longer term strategy re: login.

So, that's why we landed on this approach — we don't have to perform any extra checks or do anything technically complex and weird in order to show a prompt that tells DS Logon users to login with MHV or ID.me to update direct deposit. But we would inevitably have to do something technically weird/complex if we wanted to allow DS Logon users to login with DS logon and then access direct deposit if they were also LOA3 through ID.me.

Given this, I think we should move forward with the approach to require DS Logon user login with MHV or ID.me to access direct deposit. This should cover everything we talked about today, but let me know if you have any other specific questions.

[Samara-Strauss]

Should have closed this a while ago — DEPO team decided to not move forward with this.