Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger

Marten Gajda <> Mon, 08 February 2016 22:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EC88B1ACEEE for <>; Mon, 8 Feb 2016 14:55:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K1HAx5RX2oIG for <>; Mon, 8 Feb 2016 14:55:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 073501B3457 for <>; Mon, 8 Feb 2016 14:55:03 -0800 (PST)
X-HalOne-Cookie: 66f6e032951534c23159fb77f2f91a9026a585bb
X-HalOne-ID: fb84b7cb-ceb6-11e5-882a-b82a72cffc46
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=RPdWWHJ4d2ldyCYFAQUN2dDIpmgNtrEYU9qJIwrQTAI=; b=DajmQqltc9w+M+jHA6bwhmY334M9CYdA2FpnvqZOYV8tE3jSoYWlsfaCDGCdpsVXneBxC1AF9M8sO cE2svYZBTtwcdMotELlnnqIUZiFRHRYNxKaCr3Zx2w0nTnBva7RQW3Y+imCkRKxhVoNSiPjcf/mqva U6ENkki8MJxhb+Gw=
Received: from (unknown []) by (Halon Mail Gateway) with ESMTPSA for <>; Mon, 8 Feb 2016 22:55:00 +0000 (UTC)
Received: from localhost.localdomain ( []) by (Postfix) with ESMTPSA id 84E1156E for <>; Mon, 8 Feb 2016 23:54:59 +0100 (CET)
Message-ID: <>
Date: Mon, 08 Feb 2016 23:54:58 +0100
From: Marten Gajda <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <em67ef0b5c-33c6-4fd5-ae6a-15f29ac400d2@sydney>
In-Reply-To: <em67ef0b5c-33c6-4fd5-ae6a-15f29ac400d2@sydney>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Feb 2016 22:55:08 -0000

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.



Am 08.02.2016 um 20:00 schrieb Paul E. Jones:
> Cyrus,
>> 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.
> 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
> _______________________________________________
> webfinger mailing list

Marten Gajda

dmfs GmbH
Schandauer Straße 34
01309 Dresden

phone: +49 177 4427167

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