Hi Neil, Thanks for publishing this, it's really great and will be most helpful. The explanation of when the server uses DPoP and therefore when the client uses DPoP is pretty clear, but is it the intent that the HTTP-based protocols MUST use DPoP or is that really a RECOMMENDED for HTTP-based servers ? Ie. did you intend "RECOMMEND use DPop" to mean "MUST if you can but not if you can't" ?
I know your document says that a separate document will define the scopes, but if you pull the scopes into this document ISTM it will really be a complete solution to many use cases. Without the scopes this does not stand alone and implementable and interoperable, whereas I think that just adding scopes will make it so. (Also, I don't think the autodiscovery document will need to be a dependency but I may be wrong. ). You've clearly already thought about whether the scopes should be in this document or not, can you expand on that? I would love it if this went to the Standards Track. Lisa Dusseault 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
