Process improvement: verify auth experience for non-LOA3 users at staging review

[sterkenburgsara]

Describe the problem

Since VA has plans to sunset both DS Logon & My HealtheVet login credentials by EOY, users are beginning to receive messaging that nudges them to set up MFA accounts with ID.me or Login.gov.

The problem is that neither ID.me or Login.gov account creation process ever send users down the path of actual ID-proofing. But users don't know this. After creating a non ID-proofed account (LOA1) they come back to VA.gov, and most auth applications don't recognize those accounts. Instead, most VFS teams currently address access in two ways: 1.) give users access to the stuff, 2.) serve them an alert message that tells people they have no access. But for LOA1s, we don't actually know if they have access. They need to go and ID-proof first so that we know who they are, then we can tell them whether they have access or not.

A new "verify your identity" alert is in place on MyVa and My HealtheVet landing pages already to address this problem, and has been implemented at several entry point pages on benefit hubs. But it is likely that users enter many apps through "side doors" (they could Google something and get sent straight to a specific app, bypassing those major landing pages where these alerts already live). So, teams with auth apps must recognize LOA1 accounts & give them a different alert that asks them to go and verify their identity before telling them whether or not they "have access."

Who will benefit

This will help actual Veterans! Users who set up new accounts may not realize they have LOA1 accounts. They need to know what next steps to take in order to access their authenticated data & complete tasks or check on their information.

I am not sure exactly how widespread it is - but it's a pretty big deal. The need here is to ID the complete list of applications on VA.gov that require LOA3 authentication in order to serve content. Those are the applications that need to recognize and serve a "verify your identity" alert upon sign-in to any users who come in with low-level credentials. The alert must live on all direct static page entry point(s) to their application, tool, or form.

Describe your idea

Suggesting that governance team potentially add an LOA1 review for any auth products that come through collab cycle at staging review. To ensure that these alerts are in place and LOA1 users have clear next steps.

Provide evidence

At least 10% of Medallia feedback from My HealtheVet came back during December-January naming this problem. We believe that to be an underrepresentation of how often it is happening on VA.gov. Other teams, such as the claims status tool team, have also seen this report during user research. This mural includes user flows that articulate what happens in various situations.

Platform Mission

• [X] Keeps these products and services available, stable, and secure.
• [X] Ensures they are consistent and meet high standards of quality in Veteran-centered user experience and technical approach.
• [ ] Provides shared tools, software, support, and technical infrastructure to accelerate their development.
• [ ] Other

Other:

No response

[shiragoodman]

Governance team is reviewing this with our PO @humancompanion-usds

[gopixelsgo]

Hi @shiragoodman and @humancompanion-usds - it looks like this one is making some progress. Are there any updates, or is it still considered in Review?

[shiragoodman]

Thanks @gopixelsgo . I would say this is still in review. Let me follow up.

[humancompanion-usds]

I've got an issue from CAIA to add more Sign-in Alerts into the Design System. However, it's just not a priority until we are through the USWDS upgrade (July). But this is definitely on the radar for next quarter. Once those are there then governance can start enforcing their use.

[gopixelsgo]

Hi @humancompanion-usds - thanks for the added context. Would you say this is in Backlog in the meantime?

[humancompanion-usds]

Okay, there are a number of issues in flight now tangentially related to this one:

• #2556

• 76785

• #3105

The designers on the Design System team are going to get the proposed new sign-in related Alerts from CAIA into Figma and then into guidance. We should be able to code these up ourselves as well given that they are just instances of Alert. However, the last one in the list requires a new mash-up of Alert - Warning and lock icon so those may take a bit longer.

[humancompanion-usds]

@sterkenburgsara - I want to be sure you are getting what you need related to authentication and alert messaging. Can you outline how this request differs from Experimental Design - Recognize + serve LOA1 users a "Verify your identity" alert upon sign-in? Is this request broader? Also, can you confirm that the proposed Sign-in Alerts that CAIA has written up for us to add include what you need in both this request and in the one linked above. If they don't include what you need then please do work with Laura to reconcile that.

I understand now the Governance element of this. Once these alerts are in the Design System, and the guidance details the context for using them (the when, where, and how), then Governance will point teams towards them just like any other component.

[sterkenburgsara]

This request is very closely related to the actual alert design/dev work, but slightly different.

I'm suggesting that governance team require an extra test use case for teams that require ID-verified account credentials (LOA3) when you evaluate them at staging review. The point is to ensure that users who authenticate with lower-level credentials understand what steps to take in order to get access. Today, most teams throw error alerts that are not correct. Instead, they need to move toward displaying the appropriate "verify your identity" alert from the design tickets linked above.

Governance team members would sign in with an LOA1 test user to validate that those users see "go verify your identity" alerts in place on the app being evaluated during staging review. If that is not in place, I am suggesting that you may want to launch-block it. Sort of an extra QA hoop if that makes sense?

[sterkenburgsara]

I should caveat what I just wrote in the previous comment.

@mnorthuis and I discussed routing + where access alerts should appear across the site. She decided that we should enforce ID-verification before allowing users to proceed to auth-only applications, which means that these alerts should live on unauth entry points instead of the apps themselves (i.e. benefit hub static Drupal pages, R&S pages, etc). So maybe this isn't an issue? Was just a thought to try and cover our bases while we move toward that goal.

She's OOO today, but will hopefully see this next week.

[sterkenburgsara]

Oh, sorry for the spam - but forgot to answer your other question. Yes, these are the same alerts as what Laura sent you - she and I have been paired on this for months.

The difference for My HealtheVet is that we have additional complexity that isn't relevant for the rest of VA.gov. I wonder if maybe we just need to maintain our own custom sign-in alert for that instead of asking VADS to draft it since it doesn't scale? That's what we've done for now (it's in prod). The My HealtheVet versions of these alerts, as well as the sitewide ones are all drawn up in this Figma file, which we shared with design system team when we met with them yesterday.

[mnorthuis]

I think there are a number of things that have progressed since these auth widget tickets were first discussed, created, and evaluated so I want to make sure everyone is working from the same page. And make sure that I understand these tickets...

This ticket, is suggesting a change to the governance process to review and enforce standard use of all display states of a sign in widget - sign in, verify your identity, and the connect your account version in MHV. Is that correct?

Experimental Design - Recognize + serve LOA1 users a "Verify your identity" alert upon sign-in is the initial fix put in place by MHV to prompt users to verify their identity in a standard way and a standard location within a process.

Experimental Design LOA1 Identity Verification Alert appears to be an older ticket that looked to fix the inconsistency in the verify identity alerts.

What I don't see - that I thought the identity team was going to lead - is a ticket for establish the standard identity alerts component and guidance for use and placement of those alerts. That would go further than just the LOA3 alert the older ticket #2284 references, build off Sara's #2556 to expand beyond MHV and utilize Laura's content guidance.

Am I missing the broader ticket for that work?