User needs a way to get back to the original application even if they decide to abort the process at any stage of the process.

This is the final API endpoint that provides API compatibility with the existing MyUSA API. Implement the notifications API endpoint and associated tests.

User can add missing information to their profile at the stage that they approve applications, such as fields requested by the application but not yet provided by the user.

Sensitive attributes (most attributes in Profile) must be encrypted at the database level.

Points against Songkick:

1. No activity on the repo in the past 3 months, including accepting our PR
2. They're deliberately not bringing their OAuth2 implementation in line with the standard (see songkick/oauth2-provider#52 ), though we don't know enough about how this affects clients in practice.

Alternative to consider: https://github.com/doorkeeper-gem/doorkeeper

When directed to authenticate, user can use an external identity provider (google) to authenticate.

Users need access to common Q&A's, such as a FAQ based on user type (developers, agencies, end users).

User needs access to "legal stuff" from the homepage

This includes

• Privacy policy
• Terms of service [#108]
• What we do with your information (can be part of one of the above)
• SORN
• PIA
• PRA / OMB Control #
• Linking Policy

18F has API Standards. The MyUSA API needs to make sure we meet our own 18F standard.

Does anyone see anything in our API that does not meet what is specified in the standard? /cc @adam-at-mobomo @RyanRusnak @yozlet

18F API Standards
https://github.com/18F/api-standards

User needs a way for partner apps to log them out, such as in "kiosk mode".

For whatever mechanism MyUSA provides, the developer needs to know in which cases this should be used.

User needs to know what help / support / assistance they can expect.

For example, MyUSA may be in alpha and not provide the full range of support options available in production applications.

User is able to learn more about why MyUSA benefits agencies.

What value do agencies get from using MyUSA?

Users need the ability to say "hey, this is not me!". They need the ability to log out and/or switch to another user account.

This story applies to an already logged in user that is in process at some point in the approval / authentication flow (eg, the first screen that the user sees is to approve the application).

For external identity providers.

We need:

• IdentityProvider table
• ExternalUserIdentity table joining User to IdentityProvider, and includes a uid and maybe other information? (Do we store the OAuth token?)

OpenID connect specifies the claims that should be provided by OpenID providers.

The current api/profile endpoint provides our own format of each field.

We should either:

• Update api/profile to match OpenID Connect (note: this may break current clients)
• Create a new api/profile/openid that provides OpenID Connect formatted profile response (alternatively, provide api/openid or api/profile-openid

Full list of claims:
http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

Note that we should add fields for:

• email verified
• phone verified

Obviously some of the claims do not apply to us at this stage (eg, picture).

Users need to know why they should sign up for a MyUSA account and what value they get from having a MyUSA account.

Create new tests or port existing tests to bring the MyUSA API server up and running.

Can use a task list to assign and check off tasks, eg:

• Create issue for tasks (@polastre)
• Create list of initial tests (@adam-at-mobomo)
• ...

User needs a way to learn more about MyUSA when they arrive from another application

Define, create tests, and implement APIs and an API scope for a front-end server to implement authentication (username/password check, or OAuth login).

After completion of the profile API implementation, implement the tasks endpoint.

Some of the server endpoints are open to all (OAuth), and some are only for the use of myusa-web and the Dashboard. This differentiation needs to be marked and testable.

We need a development/test environment on AWS to test features that we're working on. It should use the provisioning described in #16.

In interacting with MyUSA, in some aspects of the application, users may need additional context in order to successfully complete their action or navigation.

In what places do users need such assistance?

User has the ability to recover their account based on other information provided previously.

On the homepage, the user is able to access the information necessary to connect their application with MyUSA, such as how to implement their application to communicate with MyUSA APIs.

Create the framework in devel for the new server. Assign to @jgrevich

We need to change the config/initializers/devise.rb to be a ".example" file since it contains keys. For example:

  # The secret key used by Devise. Devise uses this key to generate
  # random tokens. Changing this key will render invalid all existing
  # confirmation, reset password and unlock tokens in the database.
  # config.secret_key = 'f2d9d5c8d1e6f7a0a43a19bb09e9379ea49a5b6757f8c135c11f59b27c3c3de92f8a460903f8e1aa4ddd0cd2899eaef6846832501d518eed3b72752be10be257'

User has the ability to contact MyUSA program with questions / enchancements

Fields include:

• Name
• Email
• Description / text entry

Complete the integration of the Songkick version of the OAuth Provider Gem. We previously used our own fork of the Gem. Also, this means bringing over all of the code and setting up the database tables.

User is able to create an account from the MyUSA homepage

User needs to know how to get another login email with a valid link if the current one no longer works.

This involves:

• Webpage feedback / view
• Instructions
• Form/interaction that generates another link

Question: If MyUSA uses other authentication mechanisms from passwords (eg, emails, SMS, etc), do users notice the difference in logging in and (if they notice) what is their reaction?

User needs to know how to complete their login through email. The user receives an email and needs to know:

• How to complete the login process
• Any important information about the link provided

User needs device-agnostic access to MyUSA (my.usa.gov), such as responsive layout and design.

If MyUSA gives users the ability to provide additional information (that previously has not been provided) when they are authorizing an application, will they provide it?

User can deny an application.

Yep, basically give the user the option to deny an application in the approval flow.

Questions to test: Are there any indicators that users will decide to not use social account logins to access MyUSA? Are users willing to use certain services with government (MyUSA) more than others?

This may be done through market research, surveys, prototypes, paper prototypes, or a combination of both in order to test conscious and unconscious response.

When approving an application, user needs to know why they're being asked this information (or additional information) and what we do with the information.

need to implement omniauth consumer flow

User has the ability to use either email authentication or EIP authentication after previously signing up with either email or EIP.

Examples:

• Sign up with Google. Next time the user authenticates, they type in their email address and go through the standard authentication flow (providing missing info as necessary)
• Sign up using email address. Go through standard auth flow. The next time the user logs in, they log in with Google which uses the same email address. The same MyUSA account is used for the user instead of creating a new user.

For automating server deployment, create scripts with puppet or chef that automatically set up our dev/test/qa/staging/production instances on AWS.

Tagging @jgrevich who may be best suited to do this for the new MyUSA server? Or @adam-at-mobomo?

User needs to know why they can trust MyUSA / why this is the authentic MyUSA.

User need to know why they were redirected to MyUSA

Break out API Doc generation into multiple rake tasks so that we can specify dependencies.

token authentication flow added in #33 needs real language

• https://github.com/18F/myusa-server/blob/feature/authentication_token/app/controllers/sessions_controller.rb#L17
• https://github.com/18F/myusa-server/blob/feature/authentication_token/app/controllers/sessions_controller.rb#L30

User needs to know what's wrong when filling out a form, how to fix the error, and given a pathway to success.

User can restrict what information is provided to applications during app approval, such as turn off particular scopes/fields.

User needs an option to stay signed in longer than default short sessions.

This may require modification of the gem to generate docs using the same format that we use.

Bring over the API server components for the /profile API endpoint, and get the tests to pass (assuming user is already authenticated through some other TBD mechanism, see #5)