Subject: [webfinger] Mail client configuration via WebFinger

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 07 Feb 2016 22:46:17 +0000

Folks,

When we undertook the work on WebFinger, one of the use cases we had in
mind was the ability to allow an email client to automatically provision
itself.  What we wanted was for a user to be able to enter an email
address and password and for the email client to be able to determine
via WebFinger exactly what protocols to use, what ports, the name of the
SMTP server, and the name of the POP3 or IMAP server (or both).

We did not have that fully described and it conflicted with work that
others were doing on a more general aggregated services configuration
solution.  Namely, draft-daboo-aggregated-service-discovery-03.
Unfortunately, that work did not progress.

Still, I personally am frustrated with entering configuration data into
my mobile phone, tablets, desktop, and laptop every time I install a new
email client or get a new device.  It's only made worse when I have to
repeat the process for every member of the family.  So, I'd really like
a solution to this problem.

I don't think I'm alone in having this need (or having this
frustration).  Every hosting company has to articulate in detail how
customers go about configuring email for their hosted domains.  Many
(perhaps all) Universities do the same for students so they can access
email, with some going to great lengths to detail the steps needed to be
taken for every OS platform, popular clients, etc.

RFC 6186 exists and it addresses much of what I want, though client
support is lacking.  That begs the question of "why?"  Would defining
something that builds on WebFinger encourage client developers to add
support?

A couple of issues with RFC 6186 are:
   1) Information about services is exposed to the world and some prefer
      to not expose the names of servers, ports, protocols, etc.,
      especially internal ones to a company
   2) It does not allow for user-specific configuration: the entire
      domain is set to use the same information

Issue (2) is an issue with larger enterprises that associate users to
specific servers, as opposed to having some intelligent load balancing
mechanism.  However, there are smaller companies with distributed
offices and servers wherein some users are configured to use servers in
one geography and others in another geography.

Issue (2) also presents challenges with hosting providers.  DNS services
are independent of email services.  So, when a configuration change is
made to email, it has to be coordinated with the DNS side of the house.
If we use WebFinger, it does couple the web server with email, but the
DNS server never has to change.  Further, no additional change is
required to the WebFinger service operating at the root of the domain.
Thus, changes to the email configuration can happen in the back-end
without impact on users and can be used to reconfigure clients when
back-end services change.

I'd like to suggest we tackle this one narrow email provisioning problem
using WebFinger, but want to get feedback before spending time drafting
a formal proposal.

The idea is basically this:
  * User enters [email-masked] into the email client and email 
password
  * Email client queries 
https://example.com/.well-known/webfinger?resource=acct%3Apaulej%40example.com
  * The client would look for a link with a rel value of, say,
    "email-configuration".  This might look like this:
       {
         "rel" : "email-configuration",
         "href" : "https://email.example.com/user/paulej"
       }
  * The client would then query the above URI and receive a JSON document
    that we would define in this proposed spec that conveys the server
    configuration information, including server names for SMTP/IMAP/POP3,
    transport required (e.g., TCP or TLS), port numbers, login
    information (username "paulej" vs. email ID, possibly different
    passwords for each service, and a display name), etc.
  * The above resource would be password protected using the email ID and
    password assigned to the user, with the data conveyed over TLS

The client could be configured to re-fetch this information from
time-to-time, such as when the client starts, when stored credentials
are rejected, or on demand.

I'd like to hear your thoughts. Do others feel this could be a valuable
specification?  Are there client developers interested in helping to
solve this problem and willing to implement something here?

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 08 Feb 2016 00:45:20 +0000

John,

>>  When we undertook the work on WebFinger, one of the use cases
>>  we had in mind was the ability to allow an email client to
>>  automatically provision itself.  What we wanted was for a user
>>  to be able to enter an email address and password and for the
>>  email client to be able to determine via WebFinger exactly
>>  what protocols to use, what ports, the name of the SMTP
>>  server, and the name of the POP3 or IMAP server (or both).
>>...
>>  Still, I personally am frustrated with entering configuration
>>  data into my mobile phone, tablets, desktop, and laptop every
>>  time I install a new email client or get a new device.  It's
>>  only made worse when I have to repeat the process for every
>>  member of the family.  So, I'd really like a solution to this
>>  problem.
>>...
>>  RFC 6186 exists and it addresses much of what I want, though
>>  client support is lacking.  That begs the question of "why?"
>>  Would defining something that builds on WebFinger encourage
>>  client developers to add support?
>>
>>     1) Information about services is exposed to the world and
>>  some prefer to not expose the names of servers, ports,
>>  protocols, etc., especially internal ones to a company
>>     2) It does not allow for user-specific configuration: the
>>  entire domain is set to use the same information
>
>Paul, I wonder whether it is time to revisit ACAP.  Its
>predecessor, IMSP, was specifically designed for the types of
>email cases you describe and it and/or ACAP were supported in a
>reasonable range of mail clients.  Use of a 6186 mechanism to
>locate an ACAP server that required authentication (and, where
>appropriate, user identification so different information could
>be delivered) before giving out information would seem to
>mitigate the two issues identified above and use of an existing
>protocol (DHCP might be another candidate but has, IMO, never
>really taken off for application-layer client configuration and
>has issues when used across WANs on the public Internet).  It

I'm not opposed to revisiting anything, but what will it take to see 
something actually deployed?  ACAP is not a trivial protocol and it's 
scope is broad.  I'm not even aware of any client implementations today 
and I've only seen some historical server implementations.  Nonetheless, 
I'm not opposed to any solution that people will actually get behind and 
make happen.

I would not recommend DHCP, because this is useful for hosting 
providers.  It's even not very useful for many enterprises, since not 
everyone is behind the corporate firewall.

>seems to me that upgrading something with which we have
>significant experience might be a better alternative than
>deciding Webfinger is the latest hammer with which to hit all
>nails, especially nails that are not specifically web-related
>and that such an approach might be more easily accepted.

WebFinger is merely a defined place to go query via HTTPS to get a JSON 
object that contains pointers to whatever data we're seeking, along with 
a specific syntax for what those pointers look like.  Most of the world 
has infinitely more experience with an HTTP GET request than virtually 
anything else and processing a JSON object is a pretty trivial exercise. 
  WebFinger is used for a few applications, though in only one standard I 
know at present: OpenID Connect.  So, it's not quite the hammer you 
suggest it is.  However, it was designed specifically for discovering 
information like this, not knowing anything but a "subject" and a 
domain.  Given we're just talking about a couple of HTTP queries, I 
think the barrier to acceptance is going to be lower than most other 
solutions we might devise.

>>    * User enters [email-masked] into the email client and
>>  email password
>>    * Email client queries
>>...
>Given all of the discussions we have been having about security
>and privacy lately, if enterprises are, as you suggest,
>sensitive about giving out information about how they are
>configured, developing a new system that depends on email
>addresses as identifiers and passwords for authentication seems
>unwise at best.  Of course, ACAP would need examination and
>probably upgrading for serious security as well, but...

I am willing to bet that the majority of independent domain operators, 
hosting providers, etc. will continue to use the username/password 
combination for a very long time.  That said, WebFinger (by virtue of 
the fact it is nothing more than an HTTPS query) can use any HTTP-based 
authentication scheme we want, including certificates, 
username/passwords, or whatever else we night propose.  I only suggest 
username/password, as I have yet to personally encounter use of anything 
else.  Whatever solution we devise that replaces the username/password, 
though, will be supported in HTTP and, therefore, WebFinger.

>>...
>>  I'd like to hear your thoughts. Do others feel this could be a
>>  valuable specification?  Are there client developers
>>  interested in helping to solve this problem and willing to
>>  implement something here?
>
>Again, see above.  This isn't a strong pitch for ACAP, but is
>just a thought about the possibility of a well-known tool with
>which we have significant experience as an alternate starting
>point.

If ACAP was going to take off, I think it would have by now.  It did not 
and I doubt it will, but I'm absolutely not opposed if we were to 
somehow get a bunch of major client developers on board.  We'd need some 
server software that is well-supported, too.  We either have to resign 
to the fact that it's not going to solve the problem I think we should 
solve, that nobody cares to solve this problem, or that we need 
something simpler (e.g., a couple of HTTP queries to get config info).

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Feb 2016 01:45:41 +0000

On 08/02/16 00:45, Paul E. Jones wrote:
> 
> If ACAP was going to take off, I think it would have by now.

That seems correct to me.

I think solving this problem in isolation would be worthwhile
if folks deployed a solution. (IOW, let's not generalise too
much.)

My own ask here is that the user not be expected to enter a
password until after whatever automatable checks can be done,
have been done. I really hate entering a password into a new
device before I've gotten any feedback that that device is not
going to send the password in clear over the network. And yes
that may be a minority concern, but it is still I think one
we ought not ignore, esp. as it should be quite possible to
encourage good behaviour here (it's as easy as encouraging
bad behaviour;-)

S.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 08 Feb 2016 01:56:28 +0000

Stephen,

>encourage good behaviour here (it's as easy as encouraging

In the case of WebFinger, all requests go over HTTPS only.  That said, I 
think your suggestion is a good one.  It's entirely possible that the 
authentication mechanism might not be password based and we won't know 
what that is until the query is made to the server hosting the 
configuration document.

Paul

---

From: Dave Cridland <[email-masked]>
Date: Mon, 8 Feb 2016 08:41:58 +0000

John,

I suspect that in this space, we run something of a risk of assuming the
question is which hammer to use rather than deciding what nail we have.

I'm mildly amused that criticisms of RFC 6186 are around exposure and
per-user configuration, since I've never seen either be a problem - but we
could, of course, declare these vital requirements. As a relative newcomer
to email, having only spent a couple of decades on the subject, even I am
well aware that there are as many niche requirements as grains of sand, and
no solution will ever encompass them all.

Instead, there are two extreme approaches we can usefully take, and there's
middle ground as well:

a) We prescribe a sane configuration.

The MUA, given an email address, can programmatically determine the servers
and authentication details without using the network.

b) We define a discovery solution.

The MUA uses network services to locate the servers and authentication
details.

An example of the middle-ground would be that we say servers should be able
to use an email address as an authentication identifier, and that all
services should use the same credentials, and that RFC 6186 records should
be used for discovery. I think that just by adding RFC 6186 records, the
vast majority of services will immediately work. (Many MUAs performing
ad-hoc discovery essentially synthesize 6186 records where the MX is
recognized, after all).

If you want more, you'll need to add more infrastructure, and the costs
here are quite high - especially since you need not only a new service at
the server end, but changes in every client.

There are, in existence, XCAP, ACAP, IMSP, and WebFinger in this space.

You could also usefully add XMPP into the mix - it's never had problems
with server discovery, the addresses and authorization identifiers it uses
are compatible with the vast majority of email addresses out there, and it
can provide a pub-sub based arbitrary data storage via its PEP
functionality which is well deployed.

Which one to use doesn't depend on syntax - though that might be, of
course, a tie-breaker - it depends on exactly what user-experience we want
to deliver.

Dave.

On 7 February 2016 at 23:13, John C Klensin <[email-masked]> wrote:

>
>
> --On Sunday, February 07, 2016 22:46 +0000 "Paul E. Jones"
> <[email-masked]> wrote:
>
> > Folks,
>
> > I'd like to suggest we tackle this one narrow email
> > provisioning problem using WebFinger, but want to get feedback
> > before spending time drafting a formal proposal.
>
> See above.
>
>
>      john
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 08 Feb 2016 09:54:56 -0500

Hi,

--On February 8, 2016 at 12:45:20 AM +0000 "Paul E. Jones" 
<[email-masked]> wrote:

> and I doubt it will, but I'm absolutely not opposed if we were to somehow
> get a bunch of major client developers on board.  We'd need some server
> software that is well-supported, too.  We either have to resign to the
> fact that it's not going to solve the problem I think we should solve,
> that nobody cares to solve this problem, or that we need something
> simpler (e.g., a couple of HTTP queries to get config info).

As one of the few people who implemented ACP/IMSP and all of that stack I 
have to say ACAP's time has been and gone. It was way too complicated to 
implement at the time and nothing has changed. The same could be said of 
the IETF's original calendaring server effort - CAP (RFC4324) - and in the 
end a number of people took a more pragmatic approach of building a 
calendaring protocol using existing technology (HTTP/WebDAV) resulting in 
CalDAV (RFC4791) that has (at least from my standpoint) been pretty 
successful. As it turns out I replaced use of IMSP/ACAP in my 
mail/calendar/contacts client with a simple WebDAV solution - storing 
preferences on my personal WebDAV share. For the most part that has worked 
well and is trivial to implement - most of the short comings could be fixed 
through use of more modern capabilities - likely a JSON solution using HTTP 
PATCH (RFC5789) and JSON patch/merge (RFC7396).

All that said, I do believe that the client account configuration setup is 
something that needs to be addressed. Indeed I tried to start such an 
effort at the IETF (via the AppsArea WG) and number of years ago. That was 
based on work done at the Calendaring and Scheduling Consortium (a group of 
users and vendors who recognised the need for a common configuration 
piece). At the time we titled that work "Aggregated Service Discovery" 
(which morphed into "Automated Service Configuration" (ASCOT) and the last 
draft for that (now expired) can be found here: 
<https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03>.

That draft used a webfinger-based lookup of a "service configuration 
document" that could list all relevant accounts a service provider had 
available for a user. At the time that work stalled partly because there 
was push back at the BoFs about the scope of the work, and because the 
stake holders ended up with other priorities that took precedence.

Paul and I had an exchange about this prior to him starting this thread, 
and he felt new work on this should be tightly focussed on just email. I 
personally believe we need to solve the problem for multiple services, not 
just one.

For email, calendaring and contacts we do currently have a light weight 
SRV-based account provisioning solution (RFC6186, RFC6764), which works on 
a per service basis (i.e., one set of requests for each account type). The 
calendaring/contacts piece of that has been deployed and used by a number 
of providers and clients. Unfortunately, the email piece has not - a number 
of major ISP do publish _imaps etc SRV records, but very few, if any, 
clients make use of that.

I also think that since the original ASCOT work, the world has started 
moving in a slightly different direction - specifically more towards a 
device management solution. With the wild propagation of mobile devices 
into the enterprise a number of device management solutions are now 
available that allow configuring of not only accounts, but provisioning of 
settings (password policy, VPN certs etc) and applications, documents etc,. 
These solutions are fairly wide spread in enterprise environments today. 
Less so in the "personal" device scenario.

Right now it is not clear to me that an ASCOT-like solution would be 
adopted given the use of device management. Before embarking on this we 
need to take a careful look at whether any solution is likely to be adopted 
(with the biggest burden likely being on clients/OS vendors to support it). 
Given the device management solutions already out there, I suspect there 
would be little value to m,ost of those folks to actually support ASCOT.

As an alternative, the IETF might want to take a more serious look at the 
overall device management solutions, and see if there might be scope for 
standards in that area. That would allow us to build off something that is 
already deployed (in a number of proprietary solutions) but is today 
solving the problem of account setup.

PS As it turns out I use a device management tool (one available from my 
employer - Apple) for managing all my family devices, which includes the 
ability to push profiles specific to my kids devices for locking down 
parental control settings and the like.

-- 
Cyrus Daboo

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 08 Feb 2016 19:00:16 +0000

Cyrus,

>need to take a careful look at whether any solution is likely to be 
>adopted (with the biggest burden likely being on clients/OS vendors to 
>support it). Given the device management solutions already out there, I 
>suspect there would be little value to m,ost of those folks to actually 
>support ASCOT.

I completely agree that we should try to get a sense of the likelihood 
of success.

Within the enterprise -- especially the larger ones -- you are entirely 
correct that device management systems provide a good solution for most 
of the employees.   However, I interact with a lot of smaller businesses 
that do not use such systems.  Many of them have a web hosting company 
host their domains and do not have IT staff to help them on a daily 
basis.  I'm skeptical that a device management system would help that 
class of users, so arming hosting providers with tools they can deploy 
to their customers would help, I think.

There are also a number of individuals who have their own domains, many 
hosted on the many, many web hosting providers out there.  Same issue 
for most of them.

So, I think there is a market need.  I suspect if we were to create a 
solution, hosting providers were to deploy it, and client developers 
were to support it, people would use it.  However, that's a string of 
"ifs".  I think it starts with the client developers.  If there were 
people interested to solve the problem, I think the rest falls into 
place.

All that said, if client developers are uninterested, there's little 
point working to solve this problem.

>As an alternative, the IETF might want to take a more serious look at 
>the overall device management solutions, and see if there might be 
>scope for standards in that area. That would allow us to build off 
>something that is already deployed (in a number of proprietary 
>solutions) but is today solving the problem of account setup.

I think your suggestion is worthwhile independent of whether we solve 
the problem for smaller businesses and individual users of hosted 
domains.  It would good if the same solution or would address those 
needs of smaller businesses and individuals, but if it didn't, it's 
still a step forward.

Paul

---

From: Marten Gajda <[email-masked]>
Date: Mon, 08 Feb 2016 23:54:58 +0100

Hi Paul,

as a client developer I'm very interested in this topic. We've actually 
implemented draft-daboo-aggregated-service-discovery-03 and there is at 
least one groupware server product which also supports it.

While working on our implementation we've identified a few minor issues 
with the latest draft and we've already discussed them with Cyrus. I 
think most of these issues are solved easily.

Though, the major issue has not been addressed yet. It's the issue 
mentioned by Stephen. Under certain conditions a client might have to 
ask the user upfront to authenticate, which may disclose the user's 
credentials to the wrong service.

We didn't release this feature in our generic CalDAV/CardDAV clients, 
mostly due to that issue.

Anyway, I think it really starts with the server developers. 
Implementing the current spec is not that much work on the server side. 
In many cases the server configuration document could just be a static 
file and setting up a simple WebFinger end point is not that hard 
either. Actually, for our corporate server we've just created a few 
static files and some redirect magic in our .htaccess file to provide 
the WebFinger stuff.

On the client side it's more work, because it affects the account setup 
flow a lot. But it surely is worth the efforts if more services support it.

However, before even the server developers can start, it requires an 
RFC. So lets start to think about how to solve the authentication issue.

cheers

Marten

Am 08.02.2016 um 20:00 schrieb Paul E. Jones:
>> adopted given the use of device management. Before embarking on this 
>> we need to take a careful look at whether any solution is likely to 
>> be adopted (with the biggest burden likely being on clients/OS 
>> vendors to support it). Given the device management solutions already 
>> out there, I suspect there would be little value to m,ost of those 
>> folks to actually support ASCOT.
>
> Within the enterprise -- especially the larger ones -- you are 
> entirely correct that device management systems provide a good 
> solution for most of the employees.   However, I interact with a lot 
> of smaller businesses that do not use such systems.  Many of them have 
> a web hosting company host their domains and do not have IT staff to 
> help them on a daily basis.  I'm skeptical that a device management 
> system would help that class of users, so arming hosting providers 
> with tools they can deploy to their customers would help, I think.
>
> There are also a number of individuals who have their own domains, 
> many hosted on the many, many web hosting providers out there. Same 
> issue for most of them.
>
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 09 Feb 2016 01:03:21 +0000

Marten,

Thanks for the encouraging words; it sounds like you understand the 
problem that needs to be solved.

I always felt the server side was the trivial part.  As you said, it's 
possible to set up a simple WebFinger server with a static file (or sets 
of files), an .htaccess file, etc.  I use a server that pulls data from 
a database, myself.  Importantly, though, the WebFinger protocol is very 
simple (and I have to thank a number of folks who forced that 
simplicity), so I see the server side as being far less of a barrier.  
Hosting providers, for example, could very quickly and easily support 
this server-side.

The clients are the challenge.  As others have noted, this requires code 
changes in the clients and deployment of the clients.  I'm encouraged 
that you're working on client code. :)

Having an RFC is going to be an extremely important step to actually 
seeing this problem solved.  That said, I did not want to spend time on 
something that would be met with total rejection.  It sounds like there 
is at least enough interest to start a meaningful dialog, so I'll try to 
put together a draft soon and we can go from there.  If you're 
interested to collaborate on that, you're certainly welcome.

Paul

------ Original Message ------
From: "Marten Gajda" <[email-masked]>
To: [email-masked]
Sent: 2/8/2016 5:54:58 PM
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via 
WebFinger

>-- Marten Gajda