[Extra] Advanced ("Modern & Secure") Email Authentication

[Michael Slusarz <[e-mail]>]

Hello all,

First, let me echo Bron and say congratulations and thank you to everyone that helped IMAP4rev2 become reality, especially Alexey and Barry as editors!  You have all created a substantial additional amount of work for me in coordinating efforts to ensure compliance with the new standard :)

Onto my main topic: I am looking for input regarding the proper forum to raise an initiative we are currently working on.  Very short background: within the last year, many of our largest customers have come to us asking what can be done about making authentication for email services more "modern and secure".  Specifically it is driven by the desire to stop using the legacy username/password paradigm to authenticate to core email backend services, but more abstractly the problem can be framed as a more general desire that "email services should do authentication like current mobile/web apps do".  (JMAP implements advanced auth, but our customers require support for the legacy mail protocols.)

Our initial focus was on figuring out the best way to better support "modern & secure authentication" - which we took as a mandate to spread universal availability and adoption of delegated authentication and all the benefits it provides.  Yes, this kind of exists today in some clients for a very small subset of providers (Gmail, Yahoo, etc.) - but the proper general solution cannot be hard-coded authentication endpoints in select clients for select email providers.  There needs to be access to a universal standard, or at least a best practice, that allows any mail installation to enable advanced authentication and then have immediate client access to this improve functionality.

And if we are going to spend time and energy trying to convince the ecosystem to support this, we might as well rethink the entire user email authentication experience at the same time.  Wouldn't it be great if (best case) a user installs a client, enters just an e-mail address, and the client does all the auto-configuration necessary behind the scenes to connect to the proper server and display the user the "login page" for their account, which would allow any kind of fancy modern security desired (2FA, etc.)?  We believe all of the necessary standards already exist to accomplish this today.  We believe it is just a matter of educating developers/admins on how to consistently implement this goal.

The goal is to educate on the interplay between already existing standards like Email SRV records (RFC 6186), OAUTH/OpenID autodiscovery in SASL (RFC 7628), and expected authentication flows in the various email protocols (IMAP, POP3, Submission, ManageSieve) that would enable client authors, server authors, and administrators to provide the necessary infrastructure to enable widespread adoption.  This feels like an Informational document, not a Standards Track document, as the intent is to provide a best practices way to use and link multiple concepts rather than inventing new functionality.

The question I ask today is: what is the proper WG to take discussion on this idea?  I bring the idea to extra as this is an e-mail centric WG and there is specific overlap in this proposal with several of the email protocols addressed by this WG (IMAP, ManageSieve).  But, admittedly, Submission and POP3 are currently out of scope here, and this proposal also touches on areas like DNS, OAUTH/OpenID Connect, and SASL.

I did consider taking this to direct to dispatch, but wanted to get input from the email community first, with the thought that if anybody else here is interested in the same problems that they should feel free to join us in pushing this forward :)

Thanks, and looking forward to any/all feedback.

michael