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

[Steffen Nurpmeso <[e-mail]>]

Marten Gajda wrote in <[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.

You want to present them a barcode that they can scan with their
smart phone and which is made available via some local registry to
any interested application (via some kind of IPC, say DBUS), then.

  (Please take into account that white-race-first-world develops
  diabetes in teenage age, overweight, a massive front of teenage
  allergies, increasing antibiotic resistencies due to misuse,
  drug misuse in general (shouldn't be buried even, only as
  special waste, that sort of), and decreased fertility, and much,
  much more.  Is this related; maybe not.)

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

You made a contract with a provider, and it has given you
credentials to use.  The provider has an IP address, and you have
submissions, pop3s and imaps access.  On the web site's welcome page
the services URLs were noted.  (Let's say imap.XY.Z.)

 |* provide links to support channels, reset password pages, account \
 |management,

Ha!  If it were that easy to find these pages on the web site of
your provider!!  Shiny happy people there will be, i bet.

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

I personally have problems with OAuth.  Not because of the
standard group split, but mostly because you have to go over
dedicated web sites (likely), granted, today without advertising.
You can also go over onion to avoid IP-based location tracking
(maybe, still), i develop fears this may not legally be possible
anymore in a not too distant future.  (I do not use onion.)

It would be nicer to have a client certificate (with password,
possibly), that can be very easily refreshed/replaced, maybe as
part of normal TLS payload, through whatever protocol i am
currently connected to my provider, may it be SMTPS, IMAPS, POP3S,
(HTTPS).  With a master account key.  And the possibility to
revoke the old client certificate and refetch a new one simply by
establishing a normal TLS session followed by a normal login with
that key.  You can diverse that and use diverse client id, client
secret and an access token.

I just have implemented OAUTHBEARER for my MUA's SMTP, POP3 and
IMAP parts.  While testing i needed the refresh token once an
hour, and the client id, and the client secret.  So, once an hour,
i need to load/decrypt the file which stores that triple.  It does
not contain the account's master password, this is true.
When i close the lid of my notebook i am protected, because the
encrypted filesystem will then be automatically unmounted, but
different to kdestroy(1) -A the token is still valid for some
time.

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

Wow.  A different scenario.  You are the employee of a company and
have been sent via airplane (which i would refuse to do, since
airplanes are killers) to a different state/country, to another
subsidiary of the company.  You are expected to login via their
local net.  (I would wonder why they do not use some kind of
company VPN, and if it is as simplicistic as via tinc.  But ok,
i have no idea for one, and second the requirement to go over
a local subdomain i could still imagine.)

This points us back to the first paragraph.  Or the second.
What is wrong with having the corresponding (A,AAAA,MX,SRV etc.)
DNS entries for state1.company.xy and state2.company.xy?
Add some more for logos (if not yet existing) or whatever.
There is also that WWW paradigm of having a favicon.ico in the
root of your web presence, it will be fetched up automatically by
browsers, why can't you?

You need to have A/AAAA for the web presence in the DNS, why can't
you have MX / SRV for the other non-HTTPS services, too?
You want personalization on a per-user level, and you do not
control your DNS zone, and you do not want to spend a little bit
of money to get your own little DNS zone?  You would spawn a DNS
server on your box to overcome this, but getaddrinfo(3) does not
allow specifying which DNS server is to be asked?  Aha!  Yes, that
is a problem.  You want to furtherly enforce decentralisation by
moving responsibility away from the controlled and otherwise
constrained DNS to anyway running "private" HTTP servers.  (A
company could still have a VPN to overcome this, me thinks.)

If it is because DNS is controlled and constrained then following
the pigeon RFC there should possibly be an albatross RFC.  So that
slow people like me understand the issue, finally.  There is
mischief!  There is mischief!  I see more robots passing by that
collect all the information stored in .well-known.  I see people
getting bombed because of information stored under .well-known,
for nothing, who could they ask instead of a lawyer in that case?
In DNS you have at least the zone above, and their
administrator(s), which you could ask to ok that content in such
a case.   Would be cool to have S/MIME certificates via that
mechanism.  And POP3 would be cool if the current state of affairs
could be SYNCed, and if only the body of a message could be loaded
(especially autocrypt blows the headers enormously, and doing
a RETR after the summaries' TOP is a shame).

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

The draft[1] contains examples.

  [1] https://tools.ietf.org/html/draft-jones-webfinger-email-autoconfig-00

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)