Presumably because they'll most likely provide additional login mechanisms that are at least just as convenient (Google / Facebook Sign-in to start?)
User privacy is a great thing, and most of us smaller developers have nothing against it. However, it needs to be done in a way that doesn't threaten our business continuity.
I’m saying if you refuse to support Apple’s sign in because you want more user info, your company is not that special that users are going to hate quit Apple in outrage.
If your business is dependent on giving away user privacy to Facebook or Google unless you are doing something that integrates with them - it deserves to fail.
I don't know what any of you are talking about. You are taking my observations and making wildly incorrect assumptions about my motivations.
I don't want to know who someone really is.
I don't care how little information I get through these systems. I don't want it.
What I do want to know is that I can exclude throw-away Google/FB/Apple accounts made five minutes ago specifically to establish a new whitewashed identity on my site.
Right now I don't offer Facebook or Google login at all—specifically because I think the consequences (both privacy and the further entanglement of powerful entities) are not worth it.
Correct but irrelevant. For aiding the registration of legit users, verifying an email address is beneficial as a way for them to ensure they are able to recover their password.
For dealing with non-legit users the email address itself isn't so important. We don't ignore it—we happily reject attempts from ~10k throwaway domains and also some whole TLDs—but it's only one in a set of signals. The reason why the click-link-in-email process is so useful is mostly because it's a way for me to inject confusing and uncertain failures to the process to make it incrementally harder to game/predict our registration system. And it lets us inject plausible yet artificial slowness so that a persistent arsehole is never able to move faster than our people.
(Far more important are the subtle signals, particularly how the user behaves prior to registration. For example if a totally clean browser goes straight to the registration page it's likely to be an arsehole in a private browsing window. Legit users almost invariably browse content immediately prior to registering.)
Correct but irrelevant. For aiding the registration of legit users, verifying an email address is beneficial as a way for them to ensure they are able to recover their password.
You can still verify their email address for password resets. You send the link with the email address to the alias and Apple forwards it to the user.
But the whole purpose of using SSO is that you are not responsible for passwords - the IDP is. You should just be able to store the user id.
How is this a relevant reply? I offered further details about my fine-grained strategies and multi-faceted custom solution, and your response is to offer a random set of blindingly obvious facts about SSO and SIWA.
Well. Seeing that you were arguing that you didn’t want to use a “random email” that could be created in five minutes. Your whole spiel about not wanting to use a random email created by Apple as if a troll couldn’t create a random email on at least a dozen different platforms makes your whole argument against using Apple’s randomly generated email kind of nonsensical.
Besides, why use any third party identity provider if you are still managing passwords? You said that you needed an email address to send a password reset link.
Correct but irrelevant. For aiding the registration of legit users, verifying an email address is beneficial as a way for them to ensure they are able to recover their password.
Why do you need to help them recover their password if you’re using a third party?
User privacy is a great thing, and most of us smaller developers have nothing against it. However, it needs to be done in a way that doesn't threaten our business continuity.