search

w3c-fedid / FedCM

A privacy preserving identity exchange Web API
https://w3c-fedid.github.io/FedCM/
Other
375 stars 72 forks source link

concerns about email in Accounts List #317

Open kittock opened 2 years ago

kittock commented 2 years ago

§ 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 commented 2 years ago

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 commented 2 years ago

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.

https://github.com/fedidcg/FedCM/issues/242#issuecomment-1146493676

hlflanagan commented 1 year ago

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 commented 5 months ago

+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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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.