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

[Marten Gajda <[e-mail]>]

Am 24.07.19 um 16:22 schrieb Steffen Nurpmeso:
> The barcode was a little irony; You seem to have in mind a totally
> free world where you move in between say wireless networks and you
> get automatically configured access wherever you are.

No, I just want to configure my devices without having to enter all the
addresses of the services I use very time. At present this only works
well for proprietary software (e.g. MS Exchange) and dedicated clients
(e.g. setting up a Google account on Android or iCloud on an Apple
device). It's still a pain with arbitrary, generic clients and open
standard protocols.

The UX I'm striving for goes like this:

Me: configure "[e-mail]"

UA: Do you want to configure the account "[e-mail]" at Example
Inc. (<provider icon>)?
(provider name and Icon discovered automatically)

Me: yep, that's my provider

UA: Please enter your password for "[e-mail]"
(or whatever the commonly supported authentication method ofclient and
provider requires)

Me: *************************

UA: Congratulations, your Email, Calendars and Contacts are now synced.
    Btw, you if you install one of these apps you can also chat    with
other users: ......
Entering more details would only be necessary if the provider I want to
set up is not "example.com" but that's still part of my account
identifier. Some providers allow you to pick a login name which is an
email address of another provider. Average users don't recognize the
difference between email address and account identifier, hence the extra
step.

> I hope i get informed and have to "ok" who debits my money, and
> please let me wonder how this should work for anything but plain
> transport providers?

Sorry, I don't get your irony. What does this have to do with
service-discovery? The sole purpose is to allow UAs to detect service
configuration parameters that you would have to enter manually otherwise.

Also, what's a "plain transport provider"?

> I was talking about user interfaces.
> Take the city München who moved from Linux back to another vendor,
> just like Wien did many years before that.  All voices i have
> heard were not talking about technical problems.

I still don't get it. Auto-discovery of service configurations enables
UAs to build user-friendly setup routines.

> How can a JSON file be better than that?  Or is it dynamically
> created when a user authenticates via client certificate, with
> content exactly as desired for that user?

Yes, that's how it's supposed to work. An authenticated user would
essentially see his/her "personal" service configuration, dynamically
generated. The user specific configuration may vary for a lot of
reasons, some of them are:

* user accounts are stored on different hosts because they are hosted in
a data center close to the user's office
* different users may have subscribed to different services
* different users may have different SLAs

For simple use cases a statically hosted document could work well, for
more complex use cases the configuration could be generated dynamically
for each user.

>  |address. A simple GET request to a well-known address, on the other
>  |hand, is barely an issue. There may be use cases in which it may not be
> 
> Is it still that easy with HTTP/2?

It may be difficult on older platforms if the server only supports
HTTP/2 and not HTTP/1.1. However it's easier to overcome that with a 3rd
party library than it is to overcome lack of support for DNS. With
HTTP/2 you can use a library and you're done. With DNS you still need
the address of a DNS server trusted by the user. And that's a platform
specific issue.

> I see this differently, and i tell you why.  I think it deserts
> the infrastructure.  You have a thing here, and a thing there, and
> all those parts move on individually and need to be tracked, and
> of course administred, too.
> 
> For example, email.  From the three protocols SMTP, IMAP and POP3
> the last one is deserted, no one ever cared that it requires
> a really stable internet connection because if you loose
> connection after doing twenty things the server will have
> forgotten you did so.  And DKIM, DMARC and AUTOCRYPT were
> introduced happily, massively increasing the size of message
> headers, not updating POP3 to have a "body-only" command (even
> though it seems trivial to add the counterpart to the "TOP"
> command that anyway exists).

Yeah, I know. It's also getting harder and harder to buy floppy disks.
Looks like most stores have neglected them since CDs and DVDs became
hip. And no one cared about increasing their capacity anymore.

I hate to break it to you, but IMAP will probably have the same future.
The potential successor is already in the works:
https://datatracker.ietf.org/wg/jmap/about/

> You ask for auto-configuration, do you?  What shall be in that
> JSON file you proclaim?

I thought I already made that clear. Anyway here is a (non-exhaustive)
list of potential data points

* provider information, like
  * name
  * branding information, e.g.
    * an icon
    * a color scheme
  * legal information
* contact and support information like
  * link to provider home page
  * link to provider terms of service
  * link to password reset page
  * link to account management page (e.g. where you can revoke access
tokens or set defaults)
  * link to online support
  * support hotline phone number
  * address of email support
* available services, including
  * a (ideally localized) display name of the service (e.g. "Inbox" or
"Calendars")
  * endpoint URL
  * authentication information, e.g.
    * required OAuth2 scopes
  * information about the data set
    * which services provide the same data set (e.g. a provider might
offer access to the same mailbox via IMAP, POP3, JMAP, MS Exchange,
WebMail, so a multi protocol client should pick only one of them)
  * certificate pinning information
* authentication information
  * for OAuth2 that would be the various endpoints
  * for client certificate authentication, that could be the required issuer


> Again, what should be in this JSON you want to serve?
> Is it personalized data then you need to have authenticated
> yourself already -- for this you need to have an account?

Yes, why would you need service auto-discovery if you don't have an account?

> If it is not personalized data then what is missing from SRV RRs
> ...  that cannot be provided by indirecting via some URI template
> pattern from a hypothetic SRVT?

For starters, the document can be localized, either as per location
and/or language settings in the user's account or by adhering the
ACCEPT-LANGUAGE header.

The list of services can be adjusted to the user's pricing/subscription
model, e.g. premium/paying users see more services than free users,
employees may have access to different services (developers see the git
repo, sales gets to see the salesforces URL)

If the server supports a (yet to be standardized) push protocol, the
client could subscribe to changes on the service configuration.

Scalability, multi-tenant setups can simply redirect all domains to the
same document URL. With DNS you'd have to duplicate and maintain the
entries for every domain a provider supports.

Checking for updates is cheap, you can use conditional requests and get
a "Not Modified" response if nothing has changed. I don't think you can
do that with DNS.

> What is better, something completely shiny new, like a nice little
> JSON document under a new .well-known URL, or a mechanism that has
> seen iterations and evolved to something that addresses problems
> discovered after having former iterations in use.
> (I know the former is the answer, of course, as in rewrite in C++,
> from plain text to XML, rewrite in rust, move from XML to JSON,
> etc.)

IPV4 to IPV6, HTTP/1.0 to HTTP/1.1 to HTTP/2, floppy disk to CD to DVD,
HDD to SSD, smoke signals to telephone, telnet to ssh, light bulb to LED
... that's how it works. Things get improved and eventually replaced.

"Being better" is not a matter of old vs. new. It's a matter of "does it
solve my problem?". Apparently DNS can not solve all the issues related
to auto-configuration (and it doesn't have to).

Btw, an auto-configuration document is not a new concept. MS Exchange
had it for years and one of the default mechanisms is to look up a URL
derived from the user's domain. Mozilla Thunderbird has a similar mechanism.

What's missing is an open and standardized mechanism that's not tailored
for email but very generic.

> Oh, i am totally opposed to DNSSEC.  I would go for TLS/DTLS, and
> i do not understand why the data cannot be signed with some TLS
> certificate that can simply be looked up by doing a say HTTPS
> connect to the zone's main address.

Whoa! Your refuting hosting a service-configuration document on a
webserver but you would base your DNS security on HTTPS? As per you
logic you probably should provide the certificate in another DNS RR.

If you have a better (simpler) solution than DNSSEC, why don't you write
up an RFC draft and submit it for discussion?

Anyway this is far off-topic.

> Yes.  Exactly.  And i really wonder what should be the content of
> that non-public version, and how it can be accessed, and even
> more, interpreted.

See above. Services and contact/support information could only be
accessible after authentication, because they may not be meant for the
public or be user specific (e.g. an employee in the European office
could get a different support hotline than an employee located in America).

Interpretation is easy if there is a standardized document schema.


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