Right now, we can support only a select few providers with OAuth2 which we have specifically and manually signed up with. There is no standard procedure, we need to create an acccount with the provider, and find out how register our client. We often need to accept contracts from the provider, which is highly problematic in principle. It's similar in effect to software patents, in that the provider can dictate whatever terms they want on us. We currently support tens of thousands of different IMAP servers. That would be impossible with OAuth2 and manual client registration. So, this bug is highly important for the openness of email in general. It would be interesting to implement this. There are a few problems with the spec in itself. The spec makes open registration optional, allowing the client registration to be subject to authentication which happens out of band, which then of course renders the whole thing useless. Furthermore, the spec allows the server to require the client to constantly update the registration "during the lifetime of the client", which of course massively complicates matters even further. But all that depends on the concrete implementations. That said, it's pointless to implement in the client, if the servers/email providers don't support it. Does anybody know the status of implementation for: * Microsoft * Google * Yahoo * Yandex * All the others who support OAuth2 on IMAP? But the biggest issue with the spec that I see is that there is no discovery protocol. I didn't see anything that tells me how to find the "client registration endpoint". I need to know how to go from email domain (or imap server hostname) to the "client registration endpoint" URL. Nothing tells me what this is. So, I cannot call it, because I don't know its URL/hostname.
Bug 1602166 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Right now, we can support only a select few providers with OAuth2 which we have specifically and manually signed up with. There is no standard procedure, we need to create an acccount with the provider, and find out how register our client. We often need to accept contracts from the provider, which is highly problematic in principle. It's similar in effect to software patents, in that the provider can dictate whatever terms they want on us. We currently support tens of thousands of different IMAP servers (without OAuth2). That would be impossible with OAuth2 and manual client registration. So, this bug is highly important for the openness of email in general. It would be interesting to implement this. There are a few problems with the spec in itself. The spec makes open registration optional, allowing the client registration to be subject to authentication which happens out of band, which then of course renders the whole thing useless. Furthermore, the spec allows the server to require the client to constantly update the registration "during the lifetime of the client", which of course massively complicates matters even further. But all that depends on the concrete implementations. That said, it's pointless to implement in the client, if the servers/email providers don't support it. Does anybody know the status of implementation for: * Microsoft * Google * Yahoo * Yandex * All the others who support OAuth2 on IMAP? But the biggest issue with the spec that I see is that there is no discovery protocol. I didn't see anything that tells me how to find the "client registration endpoint". I need to know how to go from email domain (or imap server hostname) to the "client registration endpoint" URL. Nothing tells me what this is. So, I cannot call it, because I don't know its URL/hostname.
Right now, we can support only a select few providers with OAuth2 which we have specifically and manually signed up with. There is no standard procedure, we need to create an acccount with the provider, and find out how register our client. We often need to accept contracts from the provider, which is highly problematic in principle. It's similar in effect to software patents, in that the provider can dictate whatever terms they want on us. We currently support tens of thousands of different IMAP servers (without OAuth2). That would be impossible with OAuth2 and manual client registration. So, this bug is highly important for the openness of email in general. It would be interesting to implement this. There are a few problems with the spec in itself. The spec makes open registration optional, allowing the client registration to be subject to authentication, which happens out of band, which then of course renders the whole point moot and the thing useless. Furthermore, the spec allows the server to require the client to constantly update the registration "during the lifetime of the client", which of course massively complicates matters even further. But all that depends on the concrete implementations. That said, it's pointless to implement in the client, if the servers/email providers don't support it. Does anybody know the status of implementation for: * Microsoft * Google * Yahoo * Yandex * All the others who support OAuth2 on IMAP? But the biggest issue with the spec that I see is that there is no discovery protocol. I didn't see anything that tells me how to find the "client registration endpoint". I need to know how to go from email domain (or imap server hostname) to the "client registration endpoint" URL. Nothing tells me what this is. So, I cannot call it, because I don't know its URL/hostname.