Thanks for writing this up! I remember talking about this with you at a past IETF meeting.
I agree this is a useful profile for this ecosystem. I would be happy to help with this document, as well as help prepare a presentation on this at the next IETF meeting. --- Aaron Parecki On Thu, May 16, 2024 at 8:56 PM Neil Jenkins <neilj= 40fastmailteam....@dmarc.ietf.org> wrote: > 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. > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
