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

[Marten Gajda <[e-mail]>]

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 provider XYZ now supports chatting, here are 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