Make email optional on a Customer

[Psvensso]

Today Customers have to have an email, this is a deeply integrated part of the application and not easy to override with a plugin. This limits other authentication options that don't rely on emails like Phone OTP or e-signatures.

I see that the user concept are "identifier type" agnostic, so i could do my own user resolution in my authentication strategy (today i do it via ExternalAuthenticationService methods) but this flow of Customer (basically a lot in CustomerService) would need some rethinking.

Any thoughts?

[michaelbromley]

Can you give me an example of something that is problematic as a result of the assumption of an email address? I've not used OTP or other non-email based auth flows myself, so I am probably missing a lot of context here.

[Psvensso]

interface Identifyer: {
 strategy: string; //AuthenticationStrategy.name
 data: Record<string, string> //AuthenticationData
 verified: boolean;
}

interface User {
 identifiers: Identifyer[]
 ...
}

Is user verified: user.identifiers.any > verified
Get user email: user.identifiers.find.strategy > "native" > data.email
Change user email: NativeAuth.changeIdentifyerValue() > verification flow

And so on.

Disclamer:
I do understand this is probably not the way to solve it and that it oversimplified here, I'm just trying to "get some meat" on the discussion.

[Psvensso]

The eID flow is very similar as any other OAuth flow. But in eID you often use some sort of national identification number or other SSID instead of email. So I think this boils down to not using the email as the common denominator.

You imagine this by just implementing a Google strategy but instead of storing the email one would store the SSID from Google. If that was supported then I think most other use-cases would fit.

[Psvensso]

Had another look as i got home from work and a lot of this is already implemented on the User, it stores the strategy and externalIdentifier. External identifyer for Google is PID i think and UUID for Facebook. Doesn't really matter what. It's the external id. So i think most moving parts are there, its just make email optional on the Customer and to merge the concepts of "identifyer" "authenticationMethods" and "verified" on the User and most of the use cases would be covered..

[michaelbromley]

Thanks for all the ideas on this, that's really helpful input.

So here's what I think: right now I can't make any breaking changes to the way auth is handled. The main missing part is having the "verified" status on a per-authentication method basis, rather than a single flag per User.

For now, you'll have to work with what is there. Hopefully you can work around the current design and still implement what you need. As you do so you'll run into the edges of what is currently possible and it would be useful to document and keep a track of these limits, so that we may improve things in the next major version.

I invite you to open an actual issue rather than a discussion - I think there is enough substance here to warrant an actual feature request. You can do that now or later when you have a more concrete idea of what should be changed.

[Psvensso]

Thank you Michael,
i toally understand this is nothing that's easily fixed, it would be a pretty big breaking change so not expecting anything. Also this is a quite unique use-case anyway. Most stores today just use the email as unique id and dont bother about the other options. So this is a "nice to have" feature i think. But before i continue playing with it and i just wanted to hear some of your thoughts in a discussion format. :)