Re: New draft rfc: OAuth Profile for Open Public Clients

Am 11.01.25 um 09:11 schrieb Andrew C Aitchison:
>
> New draft rfc: OAuth Profile for Open Public Clients
>
> https://www.ietf.org/archive/id/draft-ietf-mailmaint-oauth-public-00.html
>
> I am not sure how useful this will be for GMail and Microsoft,
> but this may make it simpler to support OAUTH with many other email
> services.
>
Hi Andrew,

thank you for the pointer.

In the end, what the Intro says is this 20-page IETF draft is pulling
together existing standards, apparently there is at least one more to be
written, but the bottom line is we're adding 20 more pages of text to
the 423 pages of existing OAuth related ones (I've discounted three that
aren't relevant to client implementors), not factoring in the W3C's Web
Authentication spec, which is very long, too.

RFC8252 specifically states

>                         OAuth 2.0 for Native Apps
>
> Abstract
>
>     OAuth 2.0 authorization requests from native apps should only be made
>     through external user-agents, primarily the user's browser.  This
>     specification details the security and usability reasons why this is
>     the case and how native apps and authorization servers can implement
>     this best practice.
So basically cementing "you must use an external browser for OAuth", or
there must be an additional fetchmail-oauth2-authorizer application that
doesn't store much to disk to complete that. Which is more or less
another browser.
Or whatever separate user-agent needs to be maintained AND SECURE (lest
we endanger client systems). Uh.

Also, the client app must implement considerable amounts of browsing and
parsing client code, all of which fetchmail has never needed.

It would specifically need a HTTPS client (meaning HTTP generator and
parser, including TLS and the necessary security bits), JSON generator
and parser (more or less REST API client-side support), JW* support for
signatures and whatnot, all the OAuth profile knowledge, for what? Just
Authentication for Mail?

How can I NOT have the impression that this is all going in the wrong
direction? If you see fetchmail as a set-up-and-forget piece of embedded
software, that entire OAuth 2 thing is nothing but reinventing wheels so
heavy that you need corporations to handle them. Looks to me that OAuth2
is wonderful because it opens so many new problems that you ever and
ever need more standards to solve problems you would not have had
without OAuth2 and design and implementation flaws in existing
OAuth2-enabled software.


Anyone who wands to help with OAuth2 nonetheless, please see
<https://gitlab.com/fetchmail/fetchmail/-/blob/next/CONTRIBUTING.txt?ref_type=heads>
(if that file doesn't exist in the future, and you read this from an
archive, see if it became a .md or a .rst file).


Best regards,
Matthias