Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger

[Marten Gajda <[e-mail]>]

So how would the UI work?

1) User enters user identifier, most likely an email address, like 
"[e-mail]" and hits "next"

2) Client sends a Webfinger request to 
https://exampe.com/.well-known/webfinger?... to see if there is a 
configuration document

   -> response 404 Not Found
    a) Client falls back to "manual setup" or another auto-configuration 
mechanism

   -> response 401 Unauthorized
    b) Client asks for password at "example.com" and goes back to step 2 
(this time with authentication)

   -> response 200 Ok
    c) client moves on to next step

3) (optional) Client presents found services to the user to let him 
select the services to set up

4) Client runs the setup handler for each selected service


I think in general that could work but it raises two questions:

1) How to make sure the user really understands that he's authenticating 
at example.com in step 2b? If the user tries to configure calendar sync 
with "acme-calendar.com" where his login happens to be 
"[e-mail]" he might not be prepared to being asked for his 
example.com password. Maybe I'm just paranoid or overcautious, but I 
think that it might easily happen that the users sends his 
acme-calendar.com password to example.com in that case (since Basic 
authentication is still the most common mechanism, the client basically 
sends the password in plain text).

2) How does the client know which credentials to use to set up the 
individual services in step 4? Should the client ask the user for the 
credentials for each service or can it assume that some of them share 
the same credentials? Is that something an auto-configuration document 
can help with?

Ideally the server supports some kind of SSO mechanism like OpenID 
Connect, so you don't need to enter your password multiple times. But a 
working auto-configuration is really the precondition for this, because 
an OpenID Connect implementations needs a way to discover the OAuth2 
scope tokens to request from the server and auto-configuration is really 
the way to do that, IMO. For this it would be helpful to have some 
mechanism to request a broader scope from the user (without allowing him 
to switch to a different account), but that's a different topic I guess.

Cheers,

Marten





Am 03.06.2016 um 07:42 schrieb Paul E. Jones:
> Marten,
>
> At the end of all of all of this, the email client is still going to 
> need the password for the SMTP and IMAP/POP3 service. I guess some 
> even use different passwords for those, since email clients ask for it.
>
> I personally use Google Calendar with my email and authenticate that 
> separately today (which looks like oauth given how it integrates).
>
> So what I would expect is a UI that asks for the passwords for each 
> service that is being accessed, much like today. We really can't get 
> around that. The client just has to make it clear to the user.
>
> I only suggested to use the same password to retrieve the mail config 
> as for using email. In truth, I don't even see the security risk with 
> that, as I can find nearly any server. Thus, it's like security 
> through obfuscation, which we know isn't security. But, if we insist 
> on securing it, use the email password (ideally that being the same).
>
> Calendar or other services could each have their own like relations 
> discovered via WebFinger. Or, that info could be bundled with the 
> email config. Either way, I think we just have to ensure the UI is 
> clear, but the starting point be the email password.
>
> Perhaps I'm overlooking something, but I'm otherwise confused how the 
> client will get that SMTP and IMAP password.
>
> Paul
>
> ------------------------------------------------------------------------
> *From:* Marten Gajda <[e-mail]>
> *Sent:* June 3, 2016 12:55:33 AM GMT+02:00
> *To:* "Paul E. Jones" <[e-mail]>, "[e-mail]" 
> <[e-mail]>
> *Subject:* Re: [webfinger] [apps-discuss] Mail client configuration 
> via WebFinger
>
> Hi Paul,
>
> the problem is that often it's possible to use the same user id with
> different services. A common example is iCloud, which allows you to use
> your Gmail address as the login name.
> In that case, to set up calendar synchronization with iCloud, a user
> would enter his login (which is the Gmail address) to start the
> auto-configuration. Of course a client would first do a Webfinger
> request ongmail.com  <http://gmail.com>  in that case. If that requires authentication the
> client needs to ask for the Gmail password first. That's where you
> really confuse users and it might happen that they enter their iCloud
> password instead, which then might be revealed to Gmail.
>
> To avoid this, it has been suggested to give users an (additional) acct:
> URI type login name which always contains the domain of the actual
> service provider. So the user would enter something like
> user%40gmail.com  <http://40gmail.com>@icloud.com or maybe some generated ID like
> [e-mail], but I don't see how we could teach users
> to understand that they need to enter a different identifier to perform
> an auto-configuration.
>
> Cheers,
>
> Marten
>
> Am 01.06.2016 um 20:39 schrieb Paul E. Jones:
>
>     Marten, I would truly love to see this move forward and have had
>     an intention of writing a draft myself. I'd be happy to
>     collaborate with you on one. Just in the past couple of weeks, I
>     had to help somebody set up their email client remotely to use an
>     IMAP server. It was incredibly painful for me to try to step them
>     through the process not having access to their screen, etc. After
>     that experience, I'm even more convinced that a solution to this
>     pr! oblem is needed. I personally don't think learning the
>     existing of an account is an issue, since I can discover that by
>     merely sending an email. However, if that is a concern, then the
>     simplest solution is for the server that is providing the
>     configuration document to requires authentication regardless of
>     the user ID presented. If I were to deploy this in my own
>     environment, I would use the same user ID and password to retrieve
>     the configuration document as is used to log into the IMAP for
>     SMTP server. Interfacing with the auth functions that already
>     exist would be fairly trivial. I don't fully understand why we
>     would want to have a different authentication mechanism, given
>     that (at least in every case I've seen) the IMAP/POP and SMTP
>     services generally validate users from the same authentication
>     functions behind the scenes. Sending credentials over HTTPS to a
>     server to then validate i! n the same manner seems to make a lot
>     of sense. So the solution I had in mind would be to query using
>     WebFinger to get the usual output for "[e-mail]". In
>     that JRD that is returned would be a link relation type
>     "mailconfig" that refers to a resource like
>     https://dublin.packetizer.com/mailconfig/?user=paulej. That web
>     interface would require just basic authentication (since the
>     password would be encrypted with TLS) and authenticate with the
>     auth function like the other mail services. If auth is successful,
>     it would return the JSON structure that would contain the mail
>     configuration information. I could easily have something like that
>     working very quickly. I'd be very hesitant to introduce more
>     complex authentication or identity procedures, personally. As for
>     the content of the file returned, while! I very much think we
>     should only be using the latest security procedures, we have to
>     allow the document to return things like "use SSLv2" if that is
>     indeed what the IMAP server supports. These policies are really
>     for the IT folks to dictate and I don't think the document we
>     produce should dictate the security mechanisms. It's really the
>     place for other documents to dictate best practices and any
>     suggestion we might make might be wrong in 5 years. :) That said,
>     I'm certainly favorable to simplicity and have no strong view on
>     exactly how the config information should be structured. I wrote
>     up an example
>     https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-03 that
>     was overly trivial. It did not consider the possibility that a
>     client might have multiple protocols, for example. I think it is
>     important to provide a JS! ON document that is an array of mail
>     transmission options then an array of mail retrieval options.
>     Within each array, I would expect an array of configuration
>     options ordered in the preferred order of the administrator. Thus,
>     the preferred security procedures can be conveyed. So, "IMAP" and
>     the host might be listed a few times with different ports and
>     transports (SSL and TLS and, gulp, no security). I have seen some
>     services offered where the host name actually differs based on
>     one's geographic location. Thus, multiple servers names might need
>     to be conveyed, along with perhaps checking the physical location
>     of the user. (But, that detail doesn't have to be a part of the
>     spec.) Importantly, since the whole process can be automated, then
>     it is entirely possible for the client to re-check the recommended
>     configuration information from time-to-time to see if there is a
>     change in the configuration details. Paul ------ Original Message
>     ------ From: "Marten Gajda" <[e-mail]> To: "Paul E. Jones"
>     <[e-mail]>; "[e-mail]" <[e-mail]>
>     Sent: 6/1/2016 9:59:58 AM Subject: Re: [webfinger] [apps-discuss]
>     Mail client configuration via WebFinger
>
>         Hi Paul, we've brought up this topic during the last
>         CalConnect conference and it was decided to revitalize the TC
>         where the draft you mentioned originated from. We have some
>         interest from software vendors and users to get this solved.
>         As mentioned before, one of the major problems to solve is
>         authentication. The issue raised was that the pure existence
>         of a link to a configuration document in the webfinger
>         response can reveal theexistence of the account. On the other
>         hand, requiring authentication for auto configuration results
>         in other possible security issues and a poor user experience.
>         The latter ones could probably be solved by making OpenID
>         Connect a requirement for auto configuration, which, on the
>         other hand, adds another layer of complexity and probably
>         makes it less attractive to smaller vendors. Does anyone see
>         any possible solution to that? I'd also like to suggest a few
>         changes in the structure of the configuration document and to
>         drop support for services not protected by TLS or any other
>         transport security layer. I'll post an updated draft as a
>         basis for discussion. I'm happy to join the upcoming IEFT
>         meeting in Berlin and have a BOF or something if there is
>         enough interest in that. cheers Marten Am 09.02.2016 um 02:03
>         schrieb Paul E. Jones:
>
>             Marten, Thanks for the encouraging words; it sounds like
>             you understand the problem that needs to be solved. I
>             always felt the server side was the trivial part. As you
>             said, it's possible to set up a simple WebFinger server
>             with a static file (or sets of files), an .htaccess file,
>             etc. I use a server that pulls data from a database,
>             myself. Importantly, though, the WebFinger protocol is
>             very simple (and I have to thank a number of folks who
>             forced that simplicity), so I see the server side as being
>             far less of a barrier. Hosting providers, for example,
>             could very quickly and easily support this server-side.
>             The clients are the challenge. As others have noted, this
>             requires code changes in the clients and deployment of the
>             clients. I'm encoura! ged that you're working on client
>             code. :) Having an RFC is going to be an extremely
>             important step to actually seeing this problem solved.
>             That said, I did not want to spend time on something that
>             would be met with total rejection. It sounds like there is
>             at least enough interest to start a meaningful dialog, so
>             I'll try to put together a draft soon and we can go from
>             there. If you're interested to collaborate on that, you're
>             certainly welcome. Paul ------ Original Message ------
>             From: "Marten Gajda" <[e-mail]> To:
>             [e-mail] Sent: 2/8/2016 5:54:58 PM Subject: Re:
>             [webfinger] [apps-discuss] Mail client configuration via
>             WebFinger
>
>                 Hi Paul, as a client developer I'm very interested in
>                 this topic. We've act! ually implemented
>                 draft-daboo-aggregated-service-discovery-03 and there
>                 is at least one groupware server product which also
>                 supports it. While working on our implementation we've
>                 identified a few minor issues with the latest draft
>                 and we've already discussed them with Cyrus. I think
>                 most of these issues are solved easily. Though, the
>                 major issue has not been addressed yet. It's the issue
>                 mentioned by Stephen. Under certain conditions a
>                 client might have to ask the user upfront to
>                 authenticate, which may disclose the user's
>                 credentials to the wrong service. We didn't release
>                 this feature in our generic CalDAV/CardDAV clients,
>                 mostly due to that issue. Anyway, I think it really
>                 starts with the server developers. Implementing the
>                 current spec is not that much work on the server side.
>                 In many cases the server configuration document could
>                 just be a static file! and setting up a simple
>                 WebFinger end point is not that hard either. Actually,
>                 for our corporate server we've just created a few
>                 static files and some redirect magic in our .htaccess
>                 file to provide the WebFinger stuff. On the client
>                 side it's more work, because it affects the account
>                 setup flow a lot. But it surely is worth the efforts
>                 if more services support it. However, before even the
>                 server developers can start, it requires an RFC. So
>                 lets start to think about how to solve the
>                 authentication issue. cheers Marten Am 08.02.2016 um
>                 20:00 schrieb Paul E. Jones:
>
>                     Cyrus,
>
>                         Right now it is not clear to me that an ASCO!
>                         T-like solution would be adopted given the use
>                         of device management. Before embarking on this
>                         we need to take a careful look at whether any
>                         solution is likely to be adopted (with the
>                         biggest burden likely being on clients/OS
>                         vendors to support it). Given the device
>                         management solutions already out there, I
>                         suspect there would be little value to m,ost
>                         of those folks to actually support ASCOT. 
>
>                     I completely agree that we should try to get a
>                     sense of the likelihood of success. Within the
>                     enterprise -- especially the larger ones -- you
>                     are entirely correct that device management
>                     systems provide a good solution for most of the
>                     employees. However, I interact with a lot of
>                     smaller businesses that do not use such systems.
>                     Many of them have a web hosting company host their
>                     domains and do not have IT staff to help them on a
>                     daily basis. I'm skeptical that a device
>                     management system would help that class of users,
>                     so arming hosting providers with tools they can
>                     deploy to their customers would help, I think.
>                     There are also a number of individuals who have
>                     their own domains, many hosted on the many, many
>                     web hosting providers out there. Same issue for
>                     most of them. So, I think there is a market need.
>                     I suspect if we were to create a solution, hosting
>                     providers were to deploy it, and client developers
>                     were to support it, people would use it. However,
>                     that's a string of "ifs". I think it starts with
>                     the client developers. If there were people
>                     interested to solve the problem, I think the rest
>                     falls into place. All that said, if client
>                     developers are uninterested, there's little point
>                     working to solve this problem.
>
>                         As an alternative, the IETF might want to take
>                         a more serious look at the overall device
>                         management solutions, and see if there might
>                         be scope for standards in that area. That
>                         would allow us to build off something that is
>                         already deployed (in a number of proprietary
>                         solutions) but is today solving the problem of
>                         account setup. 
>
>                     I think your suggestion is worthwhile independent
>                     of whether we solve the problem for smaller
>                     businesses and individual users of hosted domains.
>                     It would good if the same solution or would
>                     address those needs of smaller businesses and
>                     individuals, but if it didn't, it's still a step
>                     forward. Paul
>                     ------------------------------------------------------------------------
>                     webfinger mailing list [e-mail]
>                     https://www.ietf.org/mailman/listinfo/webfinger 
>
>                 -- Marten Gajda CEO dmfs Gmb! H Schandauer Straße 34
>                 01309 Dresden GERMANY phone: [phone] email:
>                 [e-mail] Managing Director: Marten Gajda
>                 Registered address: Dresden Registered No.: AG Dresden
>                 HRB 34881 VAT Reg. No.: DE303248743
>                 ------------------------------------------------------------------------
>                 webfinger mailing list [e-mail]
>                 https://www.ietf.org/mailman/listinfo/webfinger 
>
>         -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309
>         Dresden GERMANY phone: [phone] email: [e-mail]
>         Managing Director: Marten Gajda Registered address: Dresden
>         Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743
>         ------------------------------------------------------------------------
>         webfinger mailing list [e-mail]
>         https://www.ietf.org/mailman/listinfo/webfinger 
>


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: [phone]
email: [e-mail]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743