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

[Marten Gajda <[e-mail]>]

Am 19.07.19 um 03:00 schrieb Paul E. Jones:
>
> 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.

Yes, that's exactly what I'm suggesting. In fact, the driver behind the
original draft was a company which had a setup similar to your wife's
company. They had offices in the US and in Europe and their employee's
user accounts where hosted in their respective locations.

We need to bootstrap authentication though (e.g. to support OAuth and
provide links to support and account management sites). My suggestion
would be to serve a redacted services.json to unauthenticated users
which doesn't contain user specific service entries and add a flag
indicating that you need to authenticate to get the entire set of data.

Marten

> Paul
>
> ------ Original Message ------
> From: "Marten Gajda" <[e-mail] <mailto:[e-mail]>>
> To: "[e-mail]" <[e-mail] <mailto:[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

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