[OAUTH-WG] New draft: OAuth Profile for Open Public Clients

[Neil Jenkins <[e-mail]>]

Hello all,

I have published a draft document I'd like to introduce to the working group to consider: OAuth Profile for Open Public Clients <https://www.ietf.org/archive/id/draft-jenkins-oauth-public-00.html>.

*Background*

I work for Fastmail <https://www.fastmail.com/>, and we organised a conference at the end of last year with a bunch of the other major mailbox providers to work on interoperability and improving the open ecosystem. The topic most on everyone's minds was authentication.

Unlike all the walled garden messaging systems, email remains to a large extent open. There are standard protocols (IMAP [RFC9051] <https://www.rfc-editor.org/rfc/rfc9051.html>, SMTP [RFC5321] <https://datatracker.ietf.org/doc/html/rfc5321>, and more recently JMAP [RFC8620] <https://datatracker.ietf.org/doc/html/rfc8620>[RFC8621] <https://datatracker.ietf.org/doc/html/rfc8621>) so you can have clients and servers built by different vendors, with no pre-existing relationship. Indeed, there are probably thousands of clients, and hundreds of thousands of servers out there. The situation is similar with contacts and calendars.

Most server providers (and indeed many client authors) would like to move to a more secure authentication system, but at the moment basic auth is the only interoperable mechanism. Many clients have hardcoded Gmail/Microsoft OAuth flows (as those companies are big enough to force them to do so!), but this does not scale. At the conference we worked on building an OAuth profile that we believe can significantly increase security compared to the current status quo, to allow native Email/Contacts/Calendar clients to authenticate with an arbitrary server.

I have talked to a few of you individually at the last couple of IETF meetings, and have finally had time to write up our proposal.

*Next steps*

First of all, hopefully the working group can agree that this is a problem space that is significant, and worth addressing. If so, I hope it chooses to adopt this document as  a good starting point. I am not sure whether this should be a BCP rather than Standards Track — it deliberately does not introduce anything new, just combines a lot of existing standards in a specific way suitable for this use case.

I will not be in Vancouver in person, but will join remotely. I do plan to be in Dublin. My current understanding is there are vendors such as Apple looking to start implementing something in this space in the nearish future, and obviously we would all like an agreed profile to ensure interoperability! They may be able to send someone to Vancouver.

I would be very happy to bring on a co-author (or indeed largely pass it over to them, as I am very busy with other work at the moment, hence the delay in getting this draft together). I will certainly remain involved in any discussions around this area of course.

I look forward to your feedback.

Cheers,
Neil.