wasm-demo/demo/ermis-f/imap-protocol/cur/1600095018.22638.mbox:2,S

90 lines
4.8 KiB
Plaintext

MBOX-Line: From Pidgeot18 at verizon.net Wed Apr 30 08:40:24 2014
To: imap-protocol@u.washington.edu
From: Joshua Cranmer <Pidgeot18@verizon.net>
Date: Fri Jun 8 12:34:52 2018
Subject: [Imap-protocol] OAUTH and IMAP
In-Reply-To: <CABa8R6sJQ0SV5O_udOusA983vE5NNbuRt27VthkCPuMbAge2yA@mail.gmail.com>
References: <53608FE7.8090909@verizon.net>
<CABa8R6sJQ0SV5O_udOusA983vE5NNbuRt27VthkCPuMbAge2yA@mail.gmail.com>
Message-ID: <53611968.6010707@verizon.net>
On 4/30/2014 1:55 AM, Brandon Long wrote:
> On Tue, Apr 29, 2014 at 10:53 PM, Joshua Cranmer
> <Pidgeot18@verizon.net <mailto:Pidgeot18@verizon.net>> wrote:
>
> * Client Identifier: This is required in the RFC, and it is
> emphatic that this is neither secret nor is it to be used alone
> for client authentication. The problem I have here is the
> registration requirement: not that it is hard, but rather that it
> introduces a discrimination on the part of less common mail
> services that might wish to use this mechanism, if clients have to
> register a separate identifier for every such server. Given that
> such data will evidently be public (e.g., checked into
> Thunderbird's source code; even were it not, it's still a simple
> matter to intercept all outgoing http/https requests and obtain
> the id from that), and given that IMAP already defines an ID call
> that is used by Thunderbird and other clients, if the call is
> merely to indicate to the user the name of the program wishing to
> obtain authorization, it seems to me that deriving the client
> identifier from the ID call somehow ought to be sufficient.
>
>
> The client identifier here, from my understanding, is different in
> that its an actual registered ID, not just some string. Re-using the
> ID isn't going to work, plus, as a SASL mechanism, its supposed to be
> contained and generic for use in multiple protocols, so relying on a
> protocol specific passing of that information was probably considered
> non-ideal.
The fact that a client ID needs to be pre-registered, and pre-registered
per site, would make it impossible to implement SASL OAuth in a
non-discriminatory manner: a client would only be able to connect to
those sites for which it knows what its client ID is, and only those for
which the developer(s) have the time to go register an ID. In a world
where many servers of disparate networks implement this (as other
servers are already starting to do, see Andris's email).
My suggestion, which I think got misunderstood, was that instead of
relying on a pre-registration mechanism for the client ID, IMAP clients
should be able to construct a client ID somehow from the IMAP ID that
they send out. I didn't intend to imply that the client ID should be
extracted by the server from observing an IMAP ID on the transaction.
> [1] Which is rather infuriating and confusing if all you're trying
> to do is figure out how to use AUTH=XOAUTH2, as most of the
> documentation is clearly geared towards usecases specific to other
> APIs and not IMAP or SMTP access.
>
>
> Ah, is this the documentation I pointed out above? Happy to pass on
> any feedback to the docs folks.
Well, if you're inviting me to complain about the documentation... :-)
* The scope for IMAP and SMTP is not linked to from the OAuth2
documentation itself (it is mentioned only the xoauth2 page).
* The meaning of the return result in the error response to SASL XOAUTH2
is not clear, since only an example is given. I had to read the draft
specification at IETF to make any sorts of heads or tails out of it.
* The same flowchart is used on the "Using OAuth 2.0 for Devices" and
"Using OAuth 2.0 for Installed Applications" pages. One of them is wrong.
* There's no documentation on how to handle the case where the client
application is capable of spawning a controlled browser application and
proceeding with minimal user interaction. Right now, I think our
OAuth.jsm code works by redirecting to http://localhost/, intercepting
the redirect at the http level, and stripping the URI information from that.
* Refresh token documentation is contradictory, as mentioned above.
* There's in general very little information on what responses actually
mean. For example, is the expiry timestamp measured in milliseconds,
seconds, hours, number of total eclipses viewable from Google's
headquarters? What values are reasonably expected by these timestamps?
[This is everything I can think of off the top of my head. I'm sure
there's much more.]
--
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140430/10182541/attachment.html>