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.

[ekovac]

Would it be worth enumerating types of unique account identifiers in the wild?
See, eg, how Blizzard BattleNet and Discord's user identifiers work. They aren't usernames, they aren't emails, but they are a user-facing identifier (of the form "name#1234".)

Steam and LinkedIn also make a distinction between your "username" and a name that's used for your profile page's link.

Would "handle" be a useful disambiguation from "name" here? "Name" is the fluffy, maybe frequently-changing human-facing thing, "handle" is more persistent/long-lived and typically machine-interpreted identifier. That might be too anchored in a specific time and culture though.

[gffletch]

If the goal is to allow users to disambiguate, why not let the user attach whatever they want to the identity so they can identify it in the future? This data could be kept on device or maybe by the IDP. This is kind of what happens today with a password manager where the user has multiple entries for the same site. I get to name the entry with my own string and when the password manager is engaged, it shows me the names I've set and not the underlying details.

[hlflanagan]

Discussed on 4 February 2025 CG/WG call