User authentication: As a permit purchaser, I need a way to login before I buy a permit so that I can enter into a legal agreement with the USFS and so that my permit is enforceable

[MelissaBraxton]

Background Related to #109 around folks entering required information. Currently, ID and signature are "required" to verify ID in-office, and if ID verification remains required, we've identified login.gov as means of doing that online. Login.gov is required by the USDA as an access control.

Acceptance criteria

• [ ] Users are directed to Login.gov to be authenticated
• [ ] Users understand that they will be redirected to login.gov
• [ ] Once user logins, they are taken back to the firewood permitting application so that they continue on in the permit purchase process
• [ ] Users who do not have a Login.gov account will be invited to create one
• [ ] Users who decide to opt out of Login.gov will be directed to how they can purchase a permit

Tasks

• [x] Check number of authentications allowed with current login.gov agreement, estimate max number of authentications for pilot forests, and ensure that agreement can handle additional load. Related to #90
• [x] Confirm if login.gov will be used or not
• [x] Review how special use implemented login.gov and identify if there is any modifications necessary
• [x] Finalize Login.gov button and associated messaging
• [x] Design review of mockups
• [ ] Implement Login.gov
• [ ] Implement login.gov opt out message
• [ ] Validation of acceptance criteria completed
• [ ] Design review the UI
• [ ] PO Approved

Definition of Done

• [ ] e2e tests are updated for application routing changes.
• [ ] e2e tests are functioning.
• [ ] Child routes for existing pages are working.
• [ ] Pull requests meet technical definition of done.
• [ ] Usability tested.

[MelissaBraxton]

Here are mocks of different button designs to communicate the transition to login.gov. We didn't get an opportunity to test these in the first phase.

[MelissaBraxton]

The team is revisiting the decision to go with Login.gov for ID verification and exploring whether a lighter weight option could meet the need. We've laid out some options and tradeoff here

[carlsonem]

For the Ironwood Sprint, expect to only achieve the design aspect of this specific card.

[Rebekah-Hernandez]

Mock and data flow diagram for this story and login.gov process

[MelissaBraxton]

Noticing that somehow the design review box was left off this one. Adding that task and tagging in @jstrothman!

[jstrothman]

Current Text: "You can buy firewood permits online using login.gov or in-person at one of out district offices.

If you would prefer not to create a Login.gov account, you will need to go to your local district office to purchase a firewood permit."

Change to: "You can buy firewood permits online or in-person at one of our district offices."

Let's leave out the requirement to create a login.gov account for two reasons:

• It calls attention to it as something people might not want to do and we don't want to scare them off.
• They may already have an account, in which case they won't have to create one, so much as log in.
• It will be clear that they can't get to the permit form unless they create an account or log in

I'm concerned people will think they should click on the "Sign in with LOGIN.GOV" I'd lean toward leaving this out entirely and just having the button (basically as it is now, except changing the button text to "Buy a firewood permit" as you have it in this mock-up.

Here's what the page they'll be taken to looks like, except that we'll replace USAJOBS with US Forest Service.

I think we'll need to specify the USFS logo that should be used in the header of the login.gov page.

[jstrothman]

@aQuib What do you think about running usability tests on the buy workflow before implementation, including the login steps for create account (perhaps using versions with and without the "Sign in with LOGIN.gov" line above the Buy button)?

[aQuib]

@jstrothman - Thank you for the suggestions. I agree with removing the language of "If you would prefer not to create..." since that language can be a discouragement to users. But I am concern that not informing the user about it in any way would confuse new to users and doesn't fulfil the acceptance criteria #2.

Regarding testing, sound like a good idea but I would prefer to test the entire workflow since it getting close to being developed.

@Rebekah-Hernandez - Can you please make the following edits to the design:

1. change language based on Julie's recommendations.
2. Update button treatment with design 2.d

[Rebekah-Hernandez]

Mockup updated and ready for development

[Rebekah-Hernandez]

Sorry, noticed one thing off, here is the mockup

[jstrothman]

Great--let's try this, and per discussion do usability testing after implementation because it would be a minor change to adjust the display in this page.