mailing list archives

Hello,

This is a message mostly directed to our fine Gmail server maintainers 
who happen to be listening on this list, but I think the issues here are 
relevant to other people who would read this list and I value the 
feedback of others, so I'm posting this publicly.

Google's recent announcement 
(<http://googleonlinesecurity.blogspot.co.uk/2014/04/new-security-measures-will-affect-older.html>) 
about its authentication polices, I have been led to believe, is in part 
a plea for clients to implement OAuth2.0-based authentication, and an 
intent to degrade experience of users for clients that remain 
authenticating based on common IMAP authentication passwords. I believe 
that I have a duty to the users of Thunderbird to provide them the best 
experience I can, but I believe that I also have the responsibility to 
help ensure that this experience can be easily had by both users of 
other email services and other email clients; the OAuth 2.0 requirements 
as I have found them put these responsibilities in conflict, and I do 
not want to be in the position of having to choose which is the more 
important one.

So far, I've read the OAuth 2.0 RFC (6749), Google's documentation on 
its OAuth 2.0 implementation [1], and even the most recent draft of 
integrating OAuth into SASL 
(<http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14>), which is 
what I view AUTH=XOAUTH2 in GMail's support as being analogous to. I 
have not yet had time to fully digest all the related emails about OAuth 
and SASL on the kitten working group. There has also been a discussion 
on this on Thunderbird's development mailing list 
(<https://mail.mozilla.org/pipermail/tb-planning/2014-April/003236.html>), 
if you're interested in seeing some of the discussion that has already 
been brought up and my or others' personal views on the quality of OAuth 
2.0.


Pieces of information:
* 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.

* Authorization endpoint: Arguably the biggest flaw in the entire 
process is that I see no way to build the HTTPS request to an OAuth 
authorization endpoint without hardcoding specific values.

* Token endpoint: Similar to the authorization endpoint, the location of 
this is also left indeterminable.

* Scope: It seems to me that this part, though technically optional in 
the OAuth specification, is meant to basically be required. For a single 
standardized name, it seems to me that, given that SASL mandates that 
applications using it describe a service name (cf. RFC 4422, section 4), 
it makes sense to use this parameter (or some simple derivation thereof) 
to use as the scope parameter. [2]

* Refresh tokens: Google's documentation on this is vague. At times, it 
implies that these last essentially forever unless the user revokes 
access. At other times (and apparently in experiments), it seems that 
these last only for long-ish terms (e.g., a few weeks). This need to 
"refresh" the refresh tokens would be troubling to me, since it implies 
that I should be attempting to do more things in my power to autofill 
the server's authentication mechanisms without the user knowing, in 
accordance with the user's wish to not have to retype passwords implied 
by saving these credentials in our password manager. This sort of action 
appears to be contrary to the goals of OAuth 2.0, though.

Providing this information via some sort of autoconfigurable, 
autodiscoverable mechanism given only the user's email and/or server 
name is, in my mind, absolutely necessary before any attempt to 
implement this in Thunderbird is started. While tying the records to DNS 
is theoretically better since a chain of trust can be followed with 
DANE, many clients may find it easier to look it up at some well-known 
URL similar to how Thunderbird's autoconfiguration mechanism already works.

[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.

[2] On careful rereading of the SASL OAUTHBEARER draft it seems that it 
is possible to automatically infer the desired scope... but only by 
executing a AUTHENTICATE command that fails, which is rather suboptimal 
workflow for trying to develop client behavior in this regard. It means, 
e.g., I can't wrap the OAUTH support in a generic SASL provider 
mechanism and expect to have it pick up the desired scope information. 
It's also suboptimal that the information about scope is revealed but 
not any other hints about how to go about requesting authorization.

-- 
Joshua Cranmer
Thunderbird contributor
DXR coauthor

I'm not our expert on oauth, he's welcome to pipe up here in a bit.

I'd also point you to our documentation here,
https://developers.google.com/gmail/oauth_overview which at the least has
working examples.



On Tue, Apr 29, 2014 at 10:53 PM, Joshua Cranmer <Pidgeot18@verizon.net>wrote:

> Hello,
>
> This is a message mostly directed to our fine Gmail server maintainers who
> happen to be listening on this list, but I think the issues here are
> relevant to other people who would read this list and I value the feedback
> of others, so I'm posting this publicly.
>
> Google's recent announcement (<http://googleonlinesecurity.
> blogspot.co.uk/2014/04/new-security-measures-will-affect-older.html>)
> about its authentication polices, I have been led to believe, is in part a
> plea for clients to implement OAuth2.0-based authentication, and an intent
> to degrade experience of users for clients that remain authenticating based
> on common IMAP authentication passwords. I believe that I have a duty to
> the users of Thunderbird to provide them the best experience I can, but I
> believe that I also have the responsibility to help ensure that this
> experience can be easily had by both users of other email services and
> other email clients; the OAuth 2.0 requirements as I have found them put
> these responsibilities in conflict, and I do not want to be in the position
> of having to choose which is the more important one.
>
> So far, I've read the OAuth 2.0 RFC (6749), Google's documentation on its
> OAuth 2.0 implementation [1], and even the most recent draft of integrating
> OAuth into SASL (<http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-
> 14>), which is what I view AUTH=XOAUTH2 in GMail's support as being
> analogous to. I have not yet had time to fully digest all the related
> emails about OAuth and SASL on the kitten working group. There has also
> been a discussion on this on Thunderbird's development mailing list (<
> https://mail.mozilla.org/pipermail/tb-planning/2014-April/003236.html>),
> if you're interested in seeing some of the discussion that has already been
> brought up and my or others' personal views on the quality of OAuth 2.0.
>
>
> Pieces of information:
> * 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.


> * Authorization endpoint: Arguably the biggest flaw in the entire process
> is that I see no way to build the HTTPS request to an OAuth authorization
> endpoint without hardcoding specific values.
>
> * Token endpoint: Similar to the authorization endpoint, the location of
> this is also left indeterminable.
>
> * Scope: It seems to me that this part, though technically optional in the
> OAuth specification, is meant to basically be required. For a single
> standardized name, it seems to me that, given that SASL mandates that
> applications using it describe a service name (cf. RFC 4422, section 4), it
> makes sense to use this parameter (or some simple derivation thereof) to
> use as the scope parameter. [2]
>
> * Refresh tokens: Google's documentation on this is vague. At times, it
> implies that these last essentially forever unless the user revokes access.
> At other times (and apparently in experiments), it seems that these last
> only for long-ish terms (e.g., a few weeks). This need to "refresh" the
> refresh tokens would be troubling to me, since it implies that I should be
> attempting to do more things in my power to autofill the server's
> authentication mechanisms without the user knowing, in accordance with the
> user's wish to not have to retype passwords implied by saving these
> credentials in our password manager. This sort of action appears to be
> contrary to the goals of OAuth 2.0, though.
>
> Providing this information via some sort of autoconfigurable,
> autodiscoverable mechanism given only the user's email and/or server name
> is, in my mind, absolutely necessary before any attempt to implement this
> in Thunderbird is started. While tying the records to DNS is theoretically
> better since a chain of trust can be followed with DANE, many clients may
> find it easier to look it up at some well-known URL similar to how
> Thunderbird's autoconfiguration mechanism already works.
>

Yes, as far as I know, there is no discoverability mechanism as of yet.


> [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.

[2] On careful rereading of the SASL OAUTHBEARER draft it seems that it is
> possible to automatically infer the desired scope... but only by executing
> a AUTHENTICATE command that fails, which is rather suboptimal workflow for
> trying to develop client behavior in this regard. It means, e.g., I can't
> wrap the OAUTH support in a generic SASL provider mechanism and expect to
> have it pick up the desired scope information. It's also suboptimal that
> the information about scope is revealed but not any other hints about how
> to go about requesting authorization.
>
> --
> Joshua Cranmer
> Thunderbird contributor
> DXR coauthor
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140429/70cce914/attachment.html>

> * Authorization endpoint: Arguably the biggest flaw in the 
> entire process is that I see no way to build the HTTPS request 
> to an OAuth authorization endpoint without hardcoding specific 
> values.

+1 on this.

> * Refresh tokens: Google's documentation on this is vague. At 
> times, it implies that these last essentially forever unless the 
> user revokes access. At other times (and apparently in 
> experiments), it seems that these last only for long-ish terms 
> (e.g., a few weeks).

Both are sort of true: Every time you use the refresh token you restart the 
clock.

You may look at it like this: The access token is short-lived and often 
exposed on the wire. But if snooped, the snooper has only brief access and 
cannot extend the access period. The refresh token is exposed less often, 
but is valid for a long time. It's like a client-specific revocable 
subpassword.

I implemented it and quited liked the behaviour.

Arnt

Hi,

> This is a message mostly directed to our fine Gmail server maintainers who happen to be listening on this list, but I think the issues here are relevant to other people who would read this list and I value the feedback of others, so I'm posting this publicly.


The Oauth2.0 issue is beginning to be more important as Gmail is not the only large IMAP server supporting AUTH=XOAUTH2 by now, notable others would be Outlook.com/Hotmail and Mail.ru.

I found this when I created a simple script to fetch IMAP capabilities from a list of "well known? services which can be found here: http://capa.kreata.ee/

Best regards,
Andris Reinman


On 30.04.2014, at 8:53, Joshua Cranmer <Pidgeot18@verizon.net> wrote:

> Hello,
> 
> This is a message mostly directed to our fine Gmail server maintainers who happen to be listening on this list, but I think the issues here are relevant to other people who would read this list and I value the feedback of others, so I'm posting this publicly.
> 
> Google's recent announcement (<http://googleonlinesecurity.blogspot.co.uk/2014/04/new-security-measures-will-affect-older.html>) about its authentication polices, I have been led to believe, is in part a plea for clients to implement OAuth2.0-based authentication, and an intent to degrade experience of users for clients that remain authenticating based on common IMAP authentication passwords. I believe that I have a duty to the users of Thunderbird to provide them the best experience I can, but I believe that I also have the responsibility to help ensure that this experience can be easily had by both users of other email services and other email clients; the OAuth 2.0 requirements as I have found them put these responsibilities in conflict, and I do not want to be in the position of having to choose which is the more important one.
> 
> So far, I've read the OAuth 2.0 RFC (6749), Google's documentation on its OAuth 2.0 implementation [1], and even the most recent draft of integrating OAuth into SASL (<http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14>), which is what I view AUTH=XOAUTH2 in GMail's support as being analogous to. I have not yet had time to fully digest all the related emails about OAuth and SASL on the kitten working group. There has also been a discussion on this on Thunderbird's development mailing list (<https://mail.mozilla.org/pipermail/tb-planning/2014-April/003236.html>), if you're interested in seeing some of the discussion that has already been brought up and my or others' personal views on the quality of OAuth 2.0.
> 
> 
> Pieces of information:
> * 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.
> 
> * Authorization endpoint: Arguably the biggest flaw in the entire process is that I see no way to build the HTTPS request to an OAuth authorization endpoint without hardcoding specific values.
> 
> * Token endpoint: Similar to the authorization endpoint, the location of this is also left indeterminable.
> 
> * Scope: It seems to me that this part, though technically optional in the OAuth specification, is meant to basically be required. For a single standardized name, it seems to me that, given that SASL mandates that applications using it describe a service name (cf. RFC 4422, section 4), it makes sense to use this parameter (or some simple derivation thereof) to use as the scope parameter. [2]
> 
> * Refresh tokens: Google's documentation on this is vague. At times, it implies that these last essentially forever unless the user revokes access. At other times (and apparently in experiments), it seems that these last only for long-ish terms (e.g., a few weeks). This need to "refresh" the refresh tokens would be troubling to me, since it implies that I should be attempting to do more things in my power to autofill the server's authentication mechanisms without the user knowing, in accordance with the user's wish to not have to retype passwords implied by saving these credentials in our password manager. This sort of action appears to be contrary to the goals of OAuth 2.0, though.
> 
> Providing this information via some sort of autoconfigurable, autodiscoverable mechanism given only the user's email and/or server name is, in my mind, absolutely necessary before any attempt to implement this in Thunderbird is started. While tying the records to DNS is theoretically better since a chain of trust can be followed with DANE, many clients may find it easier to look it up at some well-known URL similar to how Thunderbird's autoconfiguration mechanism already works.
> 
> [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.
> 
> [2] On careful rereading of the SASL OAUTHBEARER draft it seems that it is possible to automatically infer the desired scope... but only by executing a AUTHENTICATE command that fails, which is rather suboptimal workflow for trying to develop client behavior in this regard. It means, e.g., I can't wrap the OAUTH support in a generic SASL provider mechanism and expect to have it pick up the desired scope information. It's also suboptimal that the information about scope is revealed but not any other hints about how to go about requesting authorization.
> 
> -- 
> Joshua Cranmer
> Thunderbird contributor
> DXR coauthor
> 
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol

I have used oauth 2 with Gmail and it works well for my purpose.  I have 
seen the refresh token work several months after
first obtaining it with no intervening use.  To change the subject just 
a it, I wonder if Google could comment on the continuing
use of oauth 1 with Gmail?  Currently that is the only method I know 
that will allow me to grab Google Apps email data using
only administrative credentials, i.e. the client secret.  If there is a 
way to do that with oauth 2 I would appreciate detailed
low level documentation (not a library function).  But I sure hope that 
oauth 1 support is not going away anytime soon.

On 4/29/2014 11:55 PM, Brandon Long wrote:
> I'm not our expert on oauth, he's welcome to pipe up here in a bit.
>
> I'd also point you to our documentation here, 
> https://developers.google.com/gmail/oauth_overview which at the least 
> has working examples.
>
>
>
> On Tue, Apr 29, 2014 at 10:53 PM, Joshua Cranmer 
> <Pidgeot18@verizon.net <mailto:Pidgeot18@verizon.net>> wrote:
>
>     Hello,
>
>     This is a message mostly directed to our fine Gmail server
>     maintainers who happen to be listening on this list, but I think
>     the issues here are relevant to other people who would read this
>     list and I value the feedback of others, so I'm posting this publicly.
>
>     Google's recent announcement
>     (<http://googleonlinesecurity.blogspot.co.uk/2014/04/new-security-measures-will-affect-older.html>)
>     about its authentication polices, I have been led to believe, is
>     in part a plea for clients to implement OAuth2.0-based
>     authentication, and an intent to degrade experience of users for
>     clients that remain authenticating based on common IMAP
>     authentication passwords. I believe that I have a duty to the
>     users of Thunderbird to provide them the best experience I can,
>     but I believe that I also have the responsibility to help ensure
>     that this experience can be easily had by both users of other
>     email services and other email clients; the OAuth 2.0 requirements
>     as I have found them put these responsibilities in conflict, and I
>     do not want to be in the position of having to choose which is the
>     more important one.
>
>     So far, I've read the OAuth 2.0 RFC (6749), Google's documentation
>     on its OAuth 2.0 implementation [1], and even the most recent
>     draft of integrating OAuth into SASL
>     (<http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14>),
>     which is what I view AUTH=XOAUTH2 in GMail's support as being
>     analogous to. I have not yet had time to fully digest all the
>     related emails about OAuth and SASL on the kitten working group.
>     There has also been a discussion on this on Thunderbird's
>     development mailing list
>     (<https://mail.mozilla.org/pipermail/tb-planning/2014-April/003236.html>),
>     if you're interested in seeing some of the discussion that has
>     already been brought up and my or others' personal views on the
>     quality of OAuth 2.0.
>
>
>     Pieces of information:
>     * 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.
>
>     * Authorization endpoint: Arguably the biggest flaw in the entire
>     process is that I see no way to build the HTTPS request to an
>     OAuth authorization endpoint without hardcoding specific values.
>
>     * Token endpoint: Similar to the authorization endpoint, the
>     location of this is also left indeterminable.
>
>     * Scope: It seems to me that this part, though technically
>     optional in the OAuth specification, is meant to basically be
>     required. For a single standardized name, it seems to me that,
>     given that SASL mandates that applications using it describe a
>     service name (cf. RFC 4422, section 4), it makes sense to use this
>     parameter (or some simple derivation thereof) to use as the scope
>     parameter. [2]
>
>     * Refresh tokens: Google's documentation on this is vague. At
>     times, it implies that these last essentially forever unless the
>     user revokes access. At other times (and apparently in
>     experiments), it seems that these last only for long-ish terms
>     (e.g., a few weeks). This need to "refresh" the refresh tokens
>     would be troubling to me, since it implies that I should be
>     attempting to do more things in my power to autofill the server's
>     authentication mechanisms without the user knowing, in accordance
>     with the user's wish to not have to retype passwords implied by
>     saving these credentials in our password manager. This sort of
>     action appears to be contrary to the goals of OAuth 2.0, though.
>
>     Providing this information via some sort of autoconfigurable,
>     autodiscoverable mechanism given only the user's email and/or
>     server name is, in my mind, absolutely necessary before any
>     attempt to implement this in Thunderbird is started. While tying
>     the records to DNS is theoretically better since a chain of trust
>     can be followed with DANE, many clients may find it easier to look
>     it up at some well-known URL similar to how Thunderbird's
>     autoconfiguration mechanism already works.
>
>
> Yes, as far as I know, there is no discoverability mechanism as of yet.
>
>     [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.
>
>     [2] On careful rereading of the SASL OAUTHBEARER draft it seems
>     that it is possible to automatically infer the desired scope...
>     but only by executing a AUTHENTICATE command that fails, which is
>     rather suboptimal workflow for trying to develop client behavior
>     in this regard. It means, e.g., I can't wrap the OAUTH support in
>     a generic SASL provider mechanism and expect to have it pick up
>     the desired scope information. It's also suboptimal that the
>     information about scope is revealed but not any other hints about
>     how to go about requesting authorization.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140430/91cff5b1/attachment.html>

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>

An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140430/130fa9e8/attachment.html>

Tyro alert! Sorry to be thick here - I'll try to keep it brief.

On 30 Apr 2014 at 10:40, Joshua Cranmer wrote:

> 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. 

Could you explain what "IMAP ID" you're talking about here? Is this 
something specific to the OAUTH2 specification, or has some kind of ID 
been added to post-RFC3501 IMAP while I was asleep?

Secondly, could someone send me a link showing the intended use of 
OAUTH in an IMAP implementation? Am I correct in assuming that you are 
intended to submit a user's GMail short-term token to login to GMail instead 
of using a username/password or other SASL mechanism?

Finally, could someone comment on how real any of this is? The Wikipedia 
article on OAUTH (I know, I know - Wikipedia is Wikipedia, but it's useful 
despite all its shortcomings) paints a picture of a vague, fractured, 
poorly-designed mechanism being torn apart by internal bickering and 
infighting.

   http://en.wikipedia.org/wiki/OAuth

Links to overview sources that could help bring me up to speed on the broad 
issues would be gratefully received.

Cheers!

-- David --

------------------ David Harris -+- Pegasus Mail ----------------------
Box 5451, Dunedin, New Zealand | e-mail: David.Harris@pmail.gen.nz
           Phone: +64 3 453-6880 | Fax: +64 3 453-6612

Thought for the day:
    A penny saved is ridiculous.

On 4/30/2014 8:34 PM, David Harris wrote:
> Could you explain what "IMAP ID" you're talking about here? Is this
> something specific to the OAUTH2 specification, or has some kind of ID
> been added to post-RFC3501 IMAP while I was asleep?
Bron Gondwana already explained this.

> Secondly, could someone send me a link showing the intended use of
> OAUTH in an IMAP implementation? Am I correct in assuming that you are
> intended to submit a user's GMail short-term token to login to GMail instead
> of using a username/password or other SASL mechanism?

The IETF group that maintains SASL is developing a specification for a 
SASL OAUTHBEARER mechanism, which is what Google's (and Microsoft's) 
AUTH=XOAUTH2 is based on (different name because the RFC is still in 
flux and could (and has) change from the current implementation). The 
purpose of this specification is to use an OAuth 2.0 Bearer token (a 
short term token that appears to last ~1 hour?) instead of other SASL 
mechanisms. Attempting to read between the lines, it looks like the 
intent is to move away from storing username/passwords in the local 
password store but rather to store long-lived limited-access tokens, but 
the documentation on how clients should be handling the password store 
is completely nonexistent.

> Finally, could someone comment on how real any of this is? The Wikipedia
> article on OAUTH (I know, I know - Wikipedia is Wikipedia, but it's useful
> despite all its shortcomings) paints a picture of a vague, fractured,
> poorly-designed mechanism being torn apart by internal bickering and
> infighting.
>
>     http://en.wikipedia.org/wiki/OAuth

The former editor of OAuth 2.0 resigned in the middle of the process and 
became very bitter, and most of the OAuth 2.0 page seems to rely pretty 
one-sidedly on his comments. I spent some time attempting to dig up less 
biased and more recent security analyses of OAuth 2.0. The only one I've 
found I can recommend bothering to look at is 
<http://security-architect.blogspot.com/2013/06/rest-uneasy-do-we-need-to-worry-about.html>.

The best way to summarize the security of OAuth 2.0 is that "it's not 
impossible to secure, but it's not required to be secure": the RFC is 
extremely light on describing anything useful for building a client. If 
I had a choice, I'd rather use, say, SCRAM over OAuth 2.0, but this 
isn't exactly a choice I can make.

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

On Thu, May 1, 2014, at 11:34 AM, David Harris wrote:
> Could you explain what "IMAP ID" you're talking about here? Is this 
> something specific to the OAUTH2 specification, or has some kind of ID 
> been added to post-RFC3501 IMAP while I was asleep?

It's only post-RFC3501 if you have a time machine, I guess.

http://www.ietf.org/rfc/rfc2971.txt

Cheers,

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm