Add alternate_emails prop to OIDC userinfo

[jmhooper]

Why: So that if SPs have users with multiple email addresses, they can access those email addresses

This is a proposal for dealing with:

a.) A feature request from SPs to be able to see all of a user's email addresses
b.) A feature request from SPs to have a mechanism for selecting email addresses when a user signs in with a PIV (i.e. without an email)

Users with multiple email addresses will have the email addresses they did not use to sign in under an alternate_emails property. Users with only one email address will have an empty array there:

Additionally, I updated the consent screen to demonstrate that all of the user's email addresses are being shared. We should likely make this change anyway given that we may share a user's alternate email with an SP if they use it to sign in:

[aduth]

For the consent screen, I might worry that it's easy to miss there being multiple emails shared, given the singular "Email address" label and single line of comma-separated emails. It might be helped with a pluralized "Email addresses" and/or one-email-per-line, though I think it'd be good to get UX weigh-in.

[jmhooper]

I've added a new scope for the alternate email addresses. I'm thinking through how that should work in the UI for consent.

I'm thinking that we should show all email addresses regardless of which of the scopes is requested. My reasoning here is that any of the email addresses could be shared with the partner even if they aren't in that session. Does that make sense?

I think the other alternative is to split them out into 2 categories. Something like "Email address you sign in with" and "Other email addresses on your account". The "Other email addresses on your account" field would require an empty state.

[zachmargolis]

I've added a new scope for the alternate email addresses. I'm thinking through how that should work in the UI for consent.

I also realized that having a separate scope means this is easier to apply to SAML, it's just another attribute

I'm thinking that we should show all email addresses regardless of which of the scopes is requested. My reasoning here is that any of the email addresses could be shared with the partner even if they aren't in that session. Does that make sense?

I think the other alternative is to split them out into 2 categories. Something like "Email address you sign in with" and "Other email addresses on your account". The "Other email addresses on your account" field would require an empty state.

I'm imagining this is like a new attribute, so when only the existing email is requested we show that default email (maybe label it as "current email"). Only when additional emails are requested do we show a second line for "additional email addresses" and show the full list there

[jmhooper]

Okay, I've gone ahead and thrown together a UI that we can start cleaning up. Here is what it like in a few cases. I still need to go through and add some tests for the behavior.

Here is signing in without the alternate_emails scope:

Here is signing in with the scope, but no other email addresses:

Here is what it looks like with a single other email address:

Here is what it looks like with more than 2 email addresses:

[zachmargolis]

Okay, I've gone ahead and thrown together a UI that we can start cleaning up

yes! love it

[jmhooper]

Met up with @anniehirshman-gsa and went over this. Here is the feedback I got:

1. Let's keep all of the email addresses in the same row
2. We should use the label to indicate what is being requested. Just email address if they are requesting the sign in email addresses. If they are requesting all email addresses, change the label to "All email addresses on your account"
3. Each email should be on its own line

And reminder: We still need to consider what happens when information and how consent works there.

[jmhooper]

Need to add a test for this behavior

[jmhooper]

Okay, I've got some UI updates incorporating @anniehirshman-gsa's and @zachmargolis's feedback.

Here is what it looks like if the SP requests just the sign in email. No changes here:

Here is what it looks like if the SP requests all email addresses:

Here is what it looks like if the SP requests all email addresses and there is only 1 email address:

Finally, no need for an empty state since we changed the attribute to "all emails" instead of "all emails that aren't the sign in one".

[anniehirshman-gsa]

Just one typo: label should be Email addresses on your account instead of Emails addresses. Otherwise looks great, thanks!

[aduth]

We're also using this success-bullets class here, which hasn't been updated yet in this branch to apply the new class to its li children:

identity-idp/app/views/sign_up/completions/_requested_attributes.html.erb

Line 12 in 47bd4f0

<li><%= item %></li>

Note to self: We should consider moving to design system Icon List component.

Edit: Ticket at LG-5226.

[jmhooper]

Yeah, the reason for renaming the class was to prevent it from apply the success bullets list styles to this list item.

There may be a better way to accomplish that, but I don't know what it is.

[zachmargolis]

should/can we add a negative spec (ex bar@example is not shown when only single email scope is requested?)

[jmhooper]

@anniehirshman-gsa: Good catch on the typo. I fixed when I added translations

@zachmargolis and @aduth: I added tests, translations, and some other finishing touches. PTAL and lmk what you think!

[zachmargolis]

LGTM! only gap is SAML but this seems good enough for now. Should we track with a JIRA?