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
