Re: [art] Auto-configuring Email Clients via WebFinger

["Paul E. Jones" <[e-mail]>]

Marten,

It doesn't even require much complexity before we need user-specific 
data. I hate mentioning my wife's use-case again, but it is valid and I 
suspect her small company isn't the only one.  Some users use services 
on one SMTP and IMAP server in one country, and other users use those 
services in another country.  The data is stored in those respective 
countries, too, and never moved between countries, with the exception 
that the mail server for all incoming mail will forward to the server in 
the appropriate geography for the user.

If you're suggesting that the initial query for the "services.json" file 
may prompt for credentials and allow to server different JSON documents 
based on the user requesting, good. That would work.

Paul

------ Original Message ------
From: "Marten Gajda" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Sent: 7/18/2019 6:16:33 PM
Subject: Re: [art] Auto-configuring Email Clients via WebFinger

>As a client developer, I want to provide a smooth UX to our users. This 
>means I need much more information than just a server URL.
>
>For instance, I also want to
>
>* present the name or logo of the provider which hosts the user's 
>account, ideally before they enter their credentials,
>* provide links to support channels, reset password pages, account 
>management,
>* know the OAuth endpoints, if available,
>* know the OpenID Connect endpoints, so I can register my OAuth client 
>dynamically,
>* know the OAuth scope tokens I need in order to access a service,
>* know which endpoints serve the same data via different protocols,
>* know *all* the available services (not just the ones I know about), 
>so I can suggest other clients which may be useful.
>
>We had a few more discussion items at 
>https://github.com/CalConnect/AUTODISCOVERY/issues
>
>One of the initial ideas was to have the accounts managed by the 
>operating system and data access/synchronization handled by individual 
>applications. In this scenario, the operating system would provide the 
>UI to configure an account and perform the service discovery. 
>Afterwards it would delegate the service configuration along with the 
>account identifier to the applications which can handle the services 
>found. If the provider offers services for which no application is 
>present on the system, it could suggest suitable applications from the 
>app store or software repository. The operating system could rerun the 
>service discovery from time to time and notify the user about changes 
>(e.g. "Your proviare the applications you can use: ...").
>
>I don't see this as a use case for WebFinger though. The services 
>offered by a provider is not user data (although they may vary for each 
>users), it's primarily provider data. As such, I'd prefer to provide a 
>single JSON document at a well-known URL under the provider's domain, 
>e.g. at "/.well-known/services". This would make it trivial to host a 
>static document, which would do the trick in most setups. More complex 
>providers could still return per-user configurations (after 
>authentication).
>
>The attached example shows how a document might look like as per the 
>current status.
>
>Cheers,
>
>Marten
>
>
>
>
>
>Am 16.07.19 um 07:22 schrieb Bron Gondwana:
>>On Tue, Jul 16, 2019, at 05:31, Paul E. Jones wrote:
>>>ART folks,
>>>
>>>Several years ago when I was working on WebFinger, one of the use 
>>>cases I presented was using WebFinger to facilitate auto-configuring 
>>>email clients.  It was and still is a problem I deal with today.
>>>
>>>For my own family, I have to manually configure several different 
>>>clients on several different platforms for each member of the family. 
>>>  It's time consuming and really needs to be made simpler.
>>>
>>>My wife also has to deal with this issue where she works, because her 
>>>company, while just 100 or so employees, has offices in two different 
>>>countries and the mail server settings an employee uses depends on 
>>>his or her geographic location.  To use standard IETF protocols, it 
>>>means a lot of manual provisioning.
>>>
>>>I see the same sort of challenges with service providers. If one 
>>>wants to have his or her own domain, but isn't technically savvy, 
>>>they're in for a lot of "fun" trying to figure out the various 
>>>settings. Seriously, no normal person should have to understand what 
>>>SMTP or IMAP means, and definitely what port numbers or security 
>>>settings to fill in.
>>>
>>>While there has been a generic DNS-based method for email provision 
>>>for a while, it doesn't work for me. It doesn't work for my wife's 
>>>company, either. It also doesn't define everything one might need to 
>>>define (e.g., required security settings or policies).
>>>
>>>So we put together a very simple example to show how this might be 
>>>done with WebFinger.  See the draft here:
>>>https://tools.ietf.org/html/draft-jones-webfinger-email-autoconfig-00
>>
>>There's also been discussion about doing the same thing for caldav and 
>>carddav in CalConnect, which was led by Marten. It would be good to 
>>combine this work!
>>
>>Cheers,
>>
>>Bron.
>>
>>--
>>   Bron Gondwana
>>   [e-mail]
>>
>>
>--
>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