concerns about email in Accounts List

[kittock]

§ 5.2. Accounts List indicates that email is required.

I am assuming that the purpose of the email field is to provide a human-readable identifier to help the user disambiguate when they have multiple accounts with the IdP (if there is some other purpose, that would be helpful context).

However, it seems conceivable that not all IdPs will use email addresses, especially in the future as email is becoming less common as a means of communication.

Therefore, I am wondering if email should be generalized with something like "human_readable_identifier" which the IdP can populate with an appropriate string: email, phone number, arbitrary username, etc.

[npm1]

That is fair. I wonder if we should have a generic field vs having various fields to populate different kinds of information to be displayed in the browser UI?

[samuelgoto]

However, it seems conceivable that not all IdPs will use email addresses, especially in the future as email is becoming less common as a means of communication.

Yeah, I think you are right.

I wonder if we should have a generic field vs having various fields to populate different kinds of information to be displayed in the browser UI?

Yeah, another option would be to have a username-like attribute.

Another suggestion that I think is worth noting is to allow the RP/IDP to choose what they'd like to share selectively.

Here is a draft of an API surface that would allow that.

#242 (comment)

[hlflanagan]

This document might be of interest. It includes when/why email addresses might be used (though the username should not be collected). These are the requirements that fed SeamlessAccess: https://groups.niso.org/higherlogic/ws/public/download/21892/NISO_RP-27-2019_RA21_Identity_Discovery_and_Persistence.pdf

[aaronpk]

+1 for renaming this field to something other than email. It is entirely possible that a user might not have an email address at an IdP, and they may use other kinds of things as an account identifier. username would be fine.

[anderspitman]

In addition to allowing generic IDs, would it be possible to include the ID type, to allow RPs that support multiple ID types to know how to handle it without trying to guess from the structure?

[npm1]

Note that the fact email is the name is not necessarily very visible in the UI itself, other than the disclosure text. But allowing username and making email optional seems reasonable. Not sure I follow the suggestion to include an ID type. Is this about the RP requesting certain data from the IDP? We do have the proposal for RPs to request different fields from the IDP.

[anderspitman]

Note that the fact email is the name is not necessarily very visible in the UI itself, other than the disclosure text. But allowing username and making email optional seems reasonable. Not sure I follow the suggestion to include an ID type. Is this about the RP requesting certain data from the IDP? We do have the proposal for RPs to request different fields from the IDP.

I think I was misunderstanding the purpose of email in the accounts list (didn't read the original issue closely enough). Sounds like it's intended to be user facing to help them pick an account, but not used for any RP processing. In that case it might not be necessary to disambiguate the type of ID.