Me/dpc 5484 flag primary csp email

[MEspositoE14s]

🎫 Ticket

https://jira.cms.gov/browse/DPC-5484

🛠 Changes

• Adds a "primary" column to the user_emails table.
• Successful login sets the primary flag based on the users most recent primary email as verified by their CSP.

ℹ️ Context

Eventually, if a user logs in with a new CSP we want to be able to tell them that they previously signed up under a previous CSP along with the email attached to it. To do this, we need to know what their primary, verified email is with each CSP.

🧪 Validation

• Deployed to dev here.
• Ran locally, logged in and verified primary column was populated correctly.

[MEspositoE14s]

This will probably have to be different for each CSP. Login.gov just happens to send the primary email in auth.info.email.

[ashley-weaver]

could you make this a method so it can be easily changed by controller? like

def user_email(auth)
    auth.info.email
end

[MEspositoE14s]

No problem! This is probably the more "Railsy" way of doing it.

[ashley-weaver]

🙌

[Jose-verdance]

LGTM!

[ashley-weaver]

👍

[ashley-weaver]

nitpicky, but do you want to change this column to 'verified' too?

[MEspositoE14s]

Maybe nitpicky, but still a good idea.

[manojwadhwa81]

I see some confusion around the usage of primary vs verified terms for an email. Here is a quick summary of the differences:
a) For all assurance levels, CSPs will only be returning verified emails.
b) Of all the verified emails, one will be marked a primary. So a primary email is always a verified email and a verified email may or may not be primary
c) In order to make the distinction, the primary email is returned in the email claim and all emails are returned in 'emails_confirmed' or 'all_emails' claims in user_info endpoint.
d) The reason we see variation in the naming of the key used for confirmed emails is because this isn't standardized in OIDC specs, so it's left to the provider. However email and email_verified are standard OIDC claims, with the later being a boolean field.
e) The definition of Primary for an email for a CSP is again dependent on CSP. For id.me, it would be just a flag set by the user to mark an email of all the verified emails as primary. For others, it could be the id used to log into CSP's portal.

For all purposes, DPC will borrow the primary flag and utilize it to provide it a hint to the user to use the right CSP and email.

[MEspositoE14s]

I see some confusion around the usage of primary vs verified terms for an email. Here is a quick summary of the differences: a) For all assurance levels, CSPs will only be returning verified emails. b) Of all the verified emails, one will be marked a primary. So a primary email is always a verified email and a verified email may or may not be primary c) In order to make the distinction, the primary email is returned in the email claim and all emails are returned in 'emails_confirmed' or 'all_emails' claims in user_info endpoint. d) The reason we see variation in the naming of the key used for confirmed emails is because this isn't standardized in OIDC specs, so it's left to the provider. However email and email_verified are standard OIDC claims, with the later being a boolean field. e) The definition of Primary for an email for a CSP is again dependent on CSP. For id.me, it would be just a flag set by the user to mark an email of all the verified emails as primary. For others, it could be the id used to log into CSP's portal.

For all purposes, DPC will borrow the primary flag and utilize it to provide it a hint to the user to use the right CSP and email.

Ok 👍 , renaming verified back to primary.

[Jose-verdance]

LG!