Reconsider required email field in IdentityProviderAccount

[bvandersloot-mozilla]

This can give a little flexibility to the IDP where accounts may not have an email address tied to them or be a useful way for the user to identify the account.

[cbiesinger]

I'm curious -- has this come up in practice with some IDP, or is this more a concern in principle?

[bvandersloot-mozilla]

More of a concern in principle.

However, this makes Directed Identifiers easier to integrate, which have been brought up before.

[cbiesinger]

Why do you say that regarding directed identifiers? The email field here is only used for showing to the user, it is not shared with the RP. Is the concern that this would be misleading to users? (the selective disclosure proposal also seems somewhat relevant, #242 (comment))

In general I would prefer to walk through use cases first. I know some IDPs use phone numbers as a primary identifier. An IDP like Facebook may prefer to only show photo+name (?). Ideally a change here would address all these use cases.

[yi-gu]

One challenge we should probably keep in mind when making email optional is how to help users to differentiate accounts in a user friendly fashion. e.g.

• With single IDP, if an IDP supports multiple accounts AND a user chooses the same name and profile picture for them, then those accounts won't be distinguishable. email becomes de facto required for IDPs who support multiple accounts.
• With multiple IDP, whether requiring email is somehow orthogonal to the issue here because a user can use the same email address on different IDPs. Users may need to rely on the IDP icon to tell which is which.

In previous explorations we thought about requiring a customized "identifier" bit in IdentityAccount to help users to differentiate the accounts. e.g. IDP can use email or phone number as an "identifier" and the browser will display it on the UI. This new bit works for both the single idp and multiple idp cases. (Note: we didn't go too far on this route nor thinking through all the abuse vectors due to lack of demand. Things may have changed?)

[samuelgoto]

I'm curious -- has this come up in practice with some IDP, or is this more a concern in principle?

This came up at least two times: the first, on principles, on the TAG review and the second, in practice, by hello.coop here which doesn't always result into emails being shared.

More of a concern in principle.

I think email addresses, specifically, are concerning enough from a privacy/tracking perspective, that I think it is worth finding ways to make them not required (if the IdP and the RP don't need them). We can hope that emails get directed in the future, but there are enough a global ones right now, that it is worth making them optional, I think.

[samuelgoto]

I think the cleanest way to go about this is to introduce API surface that allows a relying party to express that it doesn't need email addresses if they aren't available. I don't know what that may look like, but something we could start from is the OIDC's claim parameter and OIDC's standard claims.

Here is what this could look like in practice:

await navigator.credentials.get({
      identity: {
        fields: ["name", "picture"], // yo, just need your name and picture, not email
        // well-known enumeration of typical claims
        // claims: ["name", "nickname", "given_name", "family_name", "email", "phone", "picture"], 
        providers: [{
          url: "https://idp.example",
          clientId: "123"
        }]
      }
});

@bvandersloot-mozilla wdyt?

[bvandersloot-mozilla]

Why do you say that regarding directed identifiers? The email field here is only used for showing to the user, it is not shared with the RP. Is the concern that this would be misleading to users? (the selective disclosure proposal also seems somewhat relevant, #242 (comment))

I mention it because I forgot that it isn't necessarily included in the token :) Never mind that point!

In general I would prefer to walk through use cases first. I know some IDPs use phone numbers as a primary identifier. An IDP like Facebook may prefer to only show photo+name (?). Ideally a change here would address all these use cases.

I fear that we can't enumerate all use cases, however here are a few, broken down by how a user understands their account:

1. Username/email
2. Username/phone
3. Name/email
4. Name/phone
5. Name/username
6. Username
7. Email
8. Phone
9. Name/Government ID Number (e.g. SIN, SSN, Aadhar)

One thing that comes to mind is having a name and visible_id (or primary_name and secondary_name), rather than a name and email. This effectively generalizes the email into many more use-cases

[bvandersloot-mozilla]

I think that generalization meets this challenge by @yi-gu :

One challenge we should probably keep in mind when making email optional is how to help users to differentiate accounts in a user friendly fashion.

With single IDP, if an IDP supports multiple accounts AND a user chooses the same name and profile picture for them, then those accounts won't be distinguishable. email becomes de facto required for IDPs who support multiple accounts.

Then those IDPs can include the optional disambiguating field.

In previous explorations we thought about requiring a customized "identifier" bit in IdentityAccount to help users to differentiate the accounts. e.g. IDP can use email or phone number as an "identifier" and the browser will display it on the UI. This new bit works for both the single idp and multiple idp cases. (Note: we didn't go too far on this route nor thinking through all the abuse vectors due to lack of demand. Things may have changed?)

Interesting! Is this a literal bit or is it just an additional field instead of the "email" that was more general, like my proposal. I don't think this is currently in demand- I just don't want to overconstrain the IDP options in the API so we don't scare off adopters that are unwilling to engage deeply in W3C processes (a high bar).

[bvandersloot-mozilla]

I think the cleanest way to go about this is to introduce API surface that allows a relying party to express that it doesn't need email addresses if they aren't available. I don't know what that may look like, but something we could start from is the OIDC's claim parameter and OIDC's standard claims.

Here is what this could look like in practice:

await navigator.credentials.get({
      identity: {
        claims: ["name"], // yo, just need your name
        // well-known enumeration of typical claims
        // claims: ["name", "nickname", "given_name", "family_name", "email", "phone", "picture"], 
        providers: [{
          url: "https://idp.example",
          clientId: "123"
        }]
      }
});

@bvandersloot-mozilla wdyt?

This is a little orthogonal to the current topic, but is interesting! Would you be restricting the values in the claims sequence to the well-known enumerated values? Presumably those would be forwarded in the Account List request. I was already thinking of another alternative: permit an arbitrary string to be included in the AccountList request and require a two-click flow for it to be sent.

[jameshartig]

As an IDP think an arbitrary string is a better option. We have requests from customers to allow logging in via phone number which means we might not have an email. It seems too restrictive to require email specifically, especially if it's only to show in the account chooser. Ideally whatever is shown to the user is what they enter when they visit the IDP (whether that's an email, phone number, username, badge number, etc).

[dusekjan]

Ideally whatever is shown to the user is what they enter when they visit the IDP

I agree with @jameshartig, at our company (IdP) we already have users who only register with a phone number so they don't have an email address. In order to make FedCM available to as many users as possible, putting a phone number in the field 'email' would work for us, but is obviously confusing.

[TallTed]

I might suggest changing email fieldname to contact or contact (email or phone), at least in UI if not in schema/ontology ...

[samuelgoto]

As an IDP think an arbitrary string is a better option.

One of the problems with accepting arbitrary strings is that I think it will lead to abuse. At some point, someone will start putting "Click here to get $5" and decrease the value proposition to non-abusive IdPs. So, I'd rather start with something that is constrained and high level, rather than general purpose but abusable.

[wparad]

even worse, is that with an arbitrary string you don't know how to handle it in a useful way. I would be really annoying to figure out if a contact field is a phone or an email and to use the correct one. It is so much easier to just write:

if (email) { contactViaEmail(); }
else if (phone) { contactViaPhone(); }

[samuelgoto]

I might suggest changing email fieldname to contact or contact (email or phone), at least in UI if not in schema/ontology ...

@TallTed I was thinking we could align these field names with the ones that HTML autocomplete uses:

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill-field

WDYT?

[TallTed]

[@samuelgoto] @TallTed I was thinking we could align these field names with the ones that HTML autocomplete uses:

It's been noted above that some users don't have an email address, only a phone number. I'm sure others will have (or want to provide) only an email address, not a phone number.

The HTML autocomplete list doesn't seem to have a tel-or-email option that would handle all of those users, unless we opt for "username" which then needs (minimally) UI that prompts the user to input their choice of email address or phone number. The nightmare regex or other twisty-windy validation/sanitization needed for such input is left as an exercise for the reader.

The authors of the HTML autocomplete list should also educate themselves about falsehoods programmers believe about things including sex (which is not the same as gender!), human names, email addresses, postal addresses, and more ... and then we should all see the HTML autocomplete list change radically.

[samuelgoto]

Just wanted to cross-post this issue here with another one (in another repo) where we are running into this problem, and wanted to try to reconcile both threads:

privacysandbox/privacy-sandbox-dev-support#379 (comment)

The proposal that we arrived at in that thread is to:

1. Make email optional in the IdentityProviderAccount(https://w3c-fedid.github.io/FedCM/#dictdef-identityprovideraccount) dictionary and
2. Introduce an optional username field (as suggested here) and phoneNumber field (as @dusekjan brought up earlier) that can be used as an alternative to email in the account chooser

Would that address this issue?

[TallTed]

Every one of these fields is problematic to some extent, especially when one goal is to have one or more universally unique identifiers for each "account" (which might include "role" accounts as well as individual "user" accounts).

Requiring "any combination of one or more of these fields, each of which is optional, where the combination is unique to service x" would be a good step.