Bugzilla

> I just saw Ben's (BenB's) video from FOSDEM 2024 on this
> https://fosdem.org/2024/schedule/event/fosdem-2024-3026--security-email-autoconfiguration-and-2fa-for-email/

Thank you for referencing this here.

In this talk, I (briefly) explain how inherently flawed Client IDs are, by design. As long as the entire *concept* of Client IDs exist, ISPs can simply not offer "Dynamic registration" and force email clients into a mandatory registration. That's inherently anti-competitive, because Google and Microsoft are direct competitors.

At least with Google and Microsoft, there's a hope that we can move them to passkeys or some other mechanism. Once we do allow OAuth2 for *arbitary* email providers, on countless third party ISPs, we're going to create a legacy protocol and we'll be *forever* stuck with the troubles that OAuth2 "framework" brings on us. Please note that OAuth2 is not a protocol, it's a "framework" for building more specific protocols. I am proposing to do just that.

Given that nobody else currently can do OAuth2, the much simpler way out of the problem is "mAuth": to simply require to allow the hardcoded-string "mail" as Client ID for email applications. Those providers will also have to adhere to a few other requirements, like returning specific error code and messages, realistic expiry times etc. More details in my talk.

> I just saw Ben's (BenB's) video from FOSDEM 2024 on this
> https://fosdem.org/2024/schedule/event/fosdem-2024-3026--security-email-autoconfiguration-and-2fa-for-email/

Thank you for referencing this here.

In this talk, I (briefly) explain how inherently flawed Client IDs are, by design. As long as the entire *concept* of Client IDs exist, ISPs can simply not offer "Dynamic registration" and force email clients into a mandatory registration. That's inherently anti-competitive, because Google and Microsoft are direct competitors.

At least with Google and Microsoft, there's a hope that we can move them to passkeys or some other mechanism. Once we do allow OAuth2 for *arbitary* email providers, on countless third party ISPs, we're going to create a legacy protocol and we'll be *forever* stuck with the troubles that OAuth2 "framework" brings on us. Please note that OAuth2 is not a protocol, it's a "framework" for building more specific protocols. I am proposing to do just that.

Given that nobody else currently can do OAuth2, the much simpler way out of the problem is "mAuth": to simply require to allow the hardcoded-string "mail" as Client ID for email applications. Those providers will also have to adhere to a few other requirements, like returning specific error code and messages, realistic expiry times, and a few other pain points in OAuth2 for email. More details in my talk.