From nobody Sun Feb 7 14:45:53 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A6C1A6F39; Sun, 7 Feb 2016 14:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.707 X-Spam-Level: X-Spam-Status: No, score=0.707 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uQQ57Vu_fsm; Sun, 7 Feb 2016 14:45:50 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABFF1A6F53; Sun, 7 Feb 2016 14:45:50 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u17MjmWm004471 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 17:45:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1454885149; bh=0D/O2XStpPzyyu8iXnKIvygZtF0LYFXdic5dWjI6jYw=; h=From:To:Subject:Date:Reply-To; b=BC6HG5xsgdf+IIhq1Sxsuwtiyp4t3VctfnI/aYgf2m3UhxfFM/hyz1zY2QjDTrrQD bUzbouY07+3hxwac1zntGb+r9Y9qcf+iutlCqLat682LcwHldtQhar8wa8UG2XrUrA UVEESLDR0bP83fQ6uRFigX8SJgVS4kwHI+LfgXis= From: "Paul E. Jones" To: apps-discuss@ietf.org, webfinger@ietf.org Date: Sun, 07 Feb 2016 22:46:17 +0000 Message-Id: User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.14 (dublin.packetizer.com [10.109.150.103]); Sun, 07 Feb 2016 17:45:49 -0500 (EST) Archived-At: Subject: [webfinger] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" 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: Sun, 07 Feb 2016 22:45:52 -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 paulej@example.com into the email client and email=20 password * Email client queries=20 https://example.com/.well-known/webfinger?resource=3Dacct%3Apaulej%40exampl= e.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 nobody Sun Feb 7 16:44:57 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901981A8733; Sun, 7 Feb 2016 16:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWbhYlT0_Kzv; Sun, 7 Feb 2016 16:44:54 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279921A8732; Sun, 7 Feb 2016 16:44:54 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u180iqa6014083 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 19:44:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1454892293; bh=9sABXvTC2p/ZRAkqSmHdXkXDjTtqsb5daTRhd8ZFqwg=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=N05eDZMyPqK/Jz6EPdDQTwgDTy+zgSxw3JkaBmtSqKRvM3XJcBxzTGrIPhpv99k9C AGOyWLXSnA7JX1QtxLSmzKSrOd4FVj/ZN09geZnBL3tD3nC9zhjpkT1xS5l4JwRvcn f/fgIAxqsK74DWSR36zHBPPPAKuaX6Gik1cb+iPQ= From: "Paul E. Jones" To: "John C Klensin" , apps-discuss@ietf.org, webfinger@ietf.org Date: Mon, 08 Feb 2016 00:45:20 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.14 (dublin.packetizer.com [10.109.150.103]); Sun, 07 Feb 2016 19:44:53 -0500 (EST) Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" 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 00:44:56 -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? >> >> 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 > >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=20 something actually deployed? ACAP is not a trivial protocol and it's=20 scope is broad. I'm not even aware of any client implementations today=20 and I've only seen some historical server implementations. Nonetheless,= =20 I'm not opposed to any solution that people will actually get behind and= =20 make happen. I would not recommend DHCP, because this is useful for hosting=20 providers. It's even not very useful for many enterprises, since not=20 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=20 object that contains pointers to whatever data we're seeking, along with= =20 a specific syntax for what those pointers look like. Most of the world=20 has infinitely more experience with an HTTP GET request than virtually=20 anything else and processing a JSON object is a pretty trivial exercise.= =20 WebFinger is used for a few applications, though in only one standard = I=20 know at present: OpenID Connect. So, it's not quite the hammer you=20 suggest it is. However, it was designed specifically for discovering=20 information like this, not knowing anything but a "subject" and a=20 domain. Given we're just talking about a couple of HTTP queries, I=20 think the barrier to acceptance is going to be lower than most other=20 solutions we might devise. >> The idea is basically this: >> * User enters paulej@example.com into the email client and >> email password >> * Email client queries >> https://example.com/.well-known/webfinger?resource=3Dacct%3Apaul >> ej%40example.com >>... > >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,=20 hosting providers, etc. will continue to use the username/password=20 combination for a very long time. That said, WebFinger (by virtue of=20 the fact it is nothing more than an HTTPS query) can use any HTTP-based=20 authentication scheme we want, including certificates,=20 username/passwords, or whatever else we night propose. I only suggest=20 username/password, as I have yet to personally encounter use of anything= =20 else. Whatever solution we devise that replaces the username/password,=20 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= =20 and I doubt it will, but I'm absolutely not opposed if we were to=20 somehow get a bunch of major client developers on board. We'd need some= =20 server software that is well-supported, too. We either have to resign=20 to the fact that it's not going to solve the problem I think we should=20 solve, that nobody cares to solve this problem, or that we need=20 something simpler (e.g., a couple of HTTP queries to get config info). Paul From nobody Sun Feb 7 17:45:50 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78ED71A884C; Sun, 7 Feb 2016 17:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK54vJC5czbD; Sun, 7 Feb 2016 17:45:47 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1441A884B; Sun, 7 Feb 2016 17:45:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5ED80BE4C; Mon, 8 Feb 2016 01:45:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlSyzNEYqKGn; Mon, 8 Feb 2016 01:45:43 +0000 (GMT) Received: from [10.87.48.75] (unknown [86.42.24.160]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7FCDBBE3F; Mon, 8 Feb 2016 01:45:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1454895943; bh=W75Yno5oosrpzjvJh6bk59+5BGa9yHHVMP2qfQHekEc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=st4R4alWv9OCUraR9TSjR950umlsXNSPHEAbKGxF1BD5YjigOVH20kq4RYmLEwhBK uQiiuR1EURZ9BPjR13+E4Bd6GNk6nThJM7h+AZN6RDgRgfAEEKolaeI5zm8S4qqtsQ rC07GqSVAI7eIabqP79ZL5zbX6oKF7xVQcMHSAWI= To: "Paul E. Jones" , John C Klensin , apps-discuss@ietf.org, webfinger@ietf.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56B7F345.9060505@cs.tcd.ie> Date: Mon, 8 Feb 2016 01:45:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org 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 01:45:49 -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 nobody Sun Feb 7 17:56:07 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643CB1A89FD; Sun, 7 Feb 2016 17:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtMkU0e4kb21; Sun, 7 Feb 2016 17:56:03 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E251A8872; Sun, 7 Feb 2016 17:56:03 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u181txaX020054 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 20:56:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1454896560; bh=N6seHTmtDd6J3hF2vP1dDCeMOGuiPIxWNC/kjIF838E=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=OYxeAJP7RJkoovu4ZIzuWlml/9oe9Ia75EKdQvM4l9Mw/WTMmEOSsnw5JWrbYnNP0 OLUnb2DcktpHxFedsqw1WX45RjHQA4Bqb+lzYKuonPwYxF9pHNoFihEG/+VB7zl0tz iEkNTOnEGQi2lvvvkRpqZSfVPcBuS9H90lZJ8Pj4= From: "Paul E. Jones" To: "Stephen Farrell" , "John C Klensin" , apps-discuss@ietf.org, webfinger@ietf.org Date: Mon, 08 Feb 2016 01:56:28 +0000 Message-Id: In-Reply-To: <56B7F345.9060505@cs.tcd.ie> User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.14 (dublin.packetizer.com [10.109.150.103]); Sun, 07 Feb 2016 20:56:00 -0500 (EST) Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" 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 01:56:04 -0000 Stephen, >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;-) In the case of WebFinger, all requests go over HTTPS only. That said, I= =20 think your suggestion is a good one. It's entirely possible that the=20 authentication mechanism might not be password based and we won't know=20 what that is until the query is made to the server hosting the=20 configuration document. Paul From nobody Mon Feb 8 00:42:15 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B521ACDA4 for ; Mon, 8 Feb 2016 00:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Weuymou_jeMt for ; Mon, 8 Feb 2016 00:42:00 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAAE1ACD9B for ; Mon, 8 Feb 2016 00:41:59 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id p63so102334105wmp.1 for ; Mon, 08 Feb 2016 00:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XaoGp6F6Vpjyv9pV1D8RU9/NrvwV2NEwt7qKJYzXhvI=; b=RIlNrIdyQc06aevnjetWKAjij7jrYHZDj9RinzPWwmE0HCiOxlLyDsBJfofsLwaEfj uPt2E86arCqbM56VEwLFNZ1ieKcf5qzyvZ1FcieEnoDP1vGpo3qti3VNtsAV/tOoTPlP 0Fvv72EhoZZWF4bu5szqVBTfCctwEH6R/QOVQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XaoGp6F6Vpjyv9pV1D8RU9/NrvwV2NEwt7qKJYzXhvI=; b=mGLFCICrkGEJz4TXw+htffioeCqLR4/Z3CdlO90aLH0kp8L/VTmLr2seSW2lgbjVPu d5PRBfDv+UB7ZAhA+gcOPGzRHEsV3oqZkmwAbBmVTCKIVEkwAUsJ8nVsKFxj4LFod89K ZzI6XlFGQOX7AcjIU64CJ4j5eKVat5JV79bj2jRD4Q2crlKirZQ44bPqZv2GQcTTNgoC 9erf4vT2Cvz+Bgd3dTz6WlHcEtC4tIFWVnZnf4GmvLoGwm+wJgHlx2bNBQncmj8BYWLW klUkCcjH37OrblEI6ZqdZVWVDb5hylJ/bmUL3Ne0xRKZ5GrHDO5pg/L6C8dcLbmCisym V2BA== X-Gm-Message-State: AG10YOR6gL0qwYo52dsuwJv8+/fXTptAB3ZdNbL/cBukQGlmJM7eDfBbp2wHZBwtoJ7qaQ/N9oYBwUl++ZswjH7N MIME-Version: 1.0 X-Received: by 10.28.30.198 with SMTP id e189mr28057362wme.60.1454920918231; Mon, 08 Feb 2016 00:41:58 -0800 (PST) Received: by 10.28.47.151 with HTTP; Mon, 8 Feb 2016 00:41:58 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Feb 2016 08:41:58 +0000 Message-ID: From: Dave Cridland To: John C Klensin Content-Type: multipart/alternative; boundary=001a114b33de820c33052b3e2c83 Archived-At: Cc: "Paul E. Jones" , "apps-discuss@ietf.org" , webfinger@ietf.org Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org 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 08:42:02 -0000 --001a114b33de820c33052b3e2c83 Content-Type: text/plain; charset=UTF-8 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 wrote: > > > --On Sunday, February 07, 2016 22:46 +0000 "Paul E. Jones" > wrote: > > > 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). > >... > > 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? > > > > 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 > > 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 > 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. > > > 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. > > > > The idea is basically this: > > * User enters paulej@example.com into the email client and > > email password > > * Email client queries > > https://example.com/.well-known/webfinger?resource=acct%3Apaul > > ej%40example.com > >... > > 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'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. > > john > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a114b33de820c33052b3e2c83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

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

I'm mildl= y amused that criticisms of RFC 6186 are around exposure and per-user confi= guration, 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 solutio= n 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 programmaticall= y determine the servers and authentication details without using the networ= k.

b) We define a discovery solution.
The MUA uses network services to locate the servers and authen= tication details.

An example of the middle-ground = would be that we say servers should be able to use an email address as an a= uthentication identifier, and that all services should use the same credent= ials, 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 immedia= tely work. (Many MUAs performing ad-hoc discovery essentially synthesize 61= 86 records where the MX is recognized, after all).

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

Ther= e 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 i= dentifiers 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 i= ts 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 deli= ver.

Dave.
On 7 February 2016 at 23:13, John C Klensin <= john-ietf@jck.com> wrote:
<= br>
--On Sunday, February 07, 2016 22:46 +0000 "Paul E. Jones"
<paulej@packetizer.com> = wrote:

> 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.=C2=A0 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.=C2=A0 It's<= br> > only made worse when I have to repeat the process for every
> member of the family.=C2=A0 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.=C2=A0 That begs the question of "why?&= quot;
> Would defining something that builds on WebFinger encourage
> client developers to add support?
>
> A couple of issues with RFC 6186 are:
>=C2=A0 =C2=A0 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
>=C2=A0 =C2=A0 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.=C2=A0 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.=C2=A0 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).=C2=A0 It
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.

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


> The idea is basically this:
>=C2=A0 =C2=A0* User enters paulej= @example.com into the email client and
> email password
>=C2=A0 =C2=A0* Email client queries
> https://example.com/.well-known= /webfinger?resource=3Dacct%3Apaul
> ej%40example.com
>...

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.=C2=A0 Of course, ACAP would need examination and
probably upgrading for serious security as well, but...

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

Again, see above.=C2=A0 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.

=C2=A0 =C2=A0 =C2=A0john


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss=

--001a114b33de820c33052b3e2c83-- From nobody Mon Feb 8 06:55:08 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7A1B2C8F; Mon, 8 Feb 2016 06:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1VBbOeWA89w; Mon, 8 Feb 2016 06:55:02 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E121B2C88; Mon, 8 Feb 2016 06:55:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 83C65337E3F8; Mon, 8 Feb 2016 09:54:59 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V7TnEtz7TFR; Mon, 8 Feb 2016 09:54:59 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 7E1A1337E3E5; Mon, 8 Feb 2016 09:54:58 -0500 (EST) Date: Mon, 08 Feb 2016 09:54:56 -0500 From: Cyrus Daboo To: "Paul E. Jones" , John C Klensin , apps-discuss@ietf.org, webfinger@ietf.org Message-ID: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=4847 Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org 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 14:55:05 -0000 Hi, --On February 8, 2016 at 12:45:20 AM +0000 "Paul E. Jones" wrote: > 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). 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: . 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 nobody Mon Feb 8 11:00:02 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578891B31AB; Mon, 8 Feb 2016 10:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZqFYrJC4n8Z; Mon, 8 Feb 2016 10:59:58 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3EF1B319E; Mon, 8 Feb 2016 10:59:57 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u18IxkkA010031 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2016 13:59:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1454957988; bh=hTgR6z8Xh+bHIVecnAjbrNer5iKOsp7XII6nEgwbfwY=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=mHUqFhksNgGsx6TxYYrzq0Hou48HwtvKFExpnXkbMj5ZqxSNhu/IYjPcrZlU20dfs DujyWbkNsQlKQtcpTELHPMaPOYnvvYnleS6QZwlnKw0Jp9ES5wDhLoRkugIL1jNpHi V0EaDnLGtEL6KOMAIZUixYRze8wcf3Ujd9o/zFME= From: "Paul E. Jones" To: "Cyrus Daboo" , "John C Klensin" , apps-discuss@ietf.org, webfinger@ietf.org Date: Mon, 08 Feb 2016 19:00:16 +0000 Message-Id: In-Reply-To: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.14 (dublin.packetizer.com [10.109.150.103]); Mon, 08 Feb 2016 13:59:48 -0500 (EST) Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" 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 18:59:59 -0000 Cyrus, >Right now it is not clear to me that an ASCOT-like solution would be=20 >adopted given the use of device management. Before embarking on this we= =20 >need to take a careful look at whether any solution is likely to be=20 >adopted (with the biggest burden likely being on clients/OS vendors to=20 >support it). Given the device management solutions already out there, I= =20 >suspect there would be little value to m,ost of those folks to actually= =20 >support ASCOT. I completely agree that we should try to get a sense of the likelihood=20 of success. Within the enterprise -- especially the larger ones -- you are entirely=20 correct that device management systems provide a good solution for most=20 of the employees. However, I interact with a lot of smaller businesses= =20 that do not use such systems. Many of them have a web hosting company=20 host their domains and do not have IT staff to help them on a daily=20 basis. I'm skeptical that a device management system would help that=20 class of users, so arming hosting providers with tools they can deploy=20 to their customers would help, I think. There are also a number of individuals who have their own domains, many=20 hosted on the many, many web hosting providers out there. Same issue=20 for most of them. So, I think there is a market need. I suspect if we were to create a=20 solution, hosting providers were to deploy it, and client developers=20 were to support it, people would use it. However, that's a string of=20 "ifs". I think it starts with the client developers. If there were=20 people interested to solve the problem, I think the rest falls into=20 place. All that said, if client developers are uninterested, there's little=20 point working to solve this problem. >As an alternative, the IETF might want to take a more serious look at=20 >the overall device management solutions, and see if there might be=20 >scope for standards in that area. That would allow us to build off=20 >something that is already deployed (in a number of proprietary=20 >solutions) but is today solving the problem of account setup. I think your suggestion is worthwhile independent of whether we solve=20 the problem for smaller businesses and individual users of hosted=20 domains. It would good if the same solution or would address those=20 needs of smaller businesses and individuals, but if it didn't, it's=20 still a step forward. Paul From nobody Mon Feb 8 14:55:09 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC88B1ACEEE for ; Mon, 8 Feb 2016 14:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1HAx5RX2oIG for ; Mon, 8 Feb 2016 14:55:04 -0800 (PST) Received: from mailrelay7.public.one.com (mailrelay7.public.one.com [91.198.169.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=dmfs.org; 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 smtp.dmfs.org (unknown [79.240.230.192]) by smtpfilter4.public.one.com (Halon Mail Gateway) with ESMTPSA for ; Mon, 8 Feb 2016 22:55:00 +0000 (UTC) Received: from localhost.localdomain (p5DDA9DA4.dip0.t-ipconnect.de [93.218.157.164]) by smtp.dmfs.org (Postfix) with ESMTPSA id 84E1156E for ; Mon, 8 Feb 2016 23:54:59 +0100 (CET) Message-ID: <56B91CC2.7080809@dmfs.org> 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 To: webfinger@ietf.org References: In-Reply-To: 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-BeenThere: webfinger@ietf.org 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. cheers Marten 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 > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 From nobody Mon Feb 8 17:02:59 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CF91B3EB9 for ; Mon, 8 Feb 2016 17:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8zNaOUV9OfS for ; Mon, 8 Feb 2016 17:02:55 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739C01B3EBE for ; Mon, 8 Feb 2016 17:02:55 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u1912okd009094 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2016 20:02:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1454979771; bh=tSbFHKzlbqYt/JcwybXkHEDQVjVF45GjaUPV88/kmRM=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=cl3ExZSSdQO1vwRBA3XX6wQGgkcDiRDVCbmurX1N3f85dRhq2LkiTi78YnhsJ+mnR 3NYHL0OW67b9qzBIBo2zhrgaj9nexJWSvdRH3wVV57c8dHxtuXLfo5qFBLMX/E3aSQ oSw/GhllOnZ3X3SRPAgm1cniWdzXpnsYwkWcCOAc= From: "Paul E. Jones" To: "Marten Gajda" , webfinger@ietf.org Date: Tue, 09 Feb 2016 01:03:21 +0000 Message-Id: In-Reply-To: <56B91CC2.7080809@dmfs.org> User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.14 (dublin.packetizer.com [10.109.150.103]); Mon, 08 Feb 2016 20:02:51 -0500 (EST) Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" 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: Tue, 09 Feb 2016 01:02:58 -0000 Marten, Thanks for the encouraging words; it sounds like you understand the=20 problem that needs to be solved. I always felt the server side was the trivial part. As you said, it's=20 possible to set up a simple WebFinger server with a static file (or sets= =20 of files), an .htaccess file, etc. I use a server that pulls data from=20 a database, myself. Importantly, though, the WebFinger protocol is very= =20 simple (and I have to thank a number of folks who forced that=20 simplicity), so I see the server side as being far less of a barrier. =20 Hosting providers, for example, could very quickly and easily support=20 this server-side. The clients are the challenge. As others have noted, this requires code= =20 changes in the clients and deployment of the clients. I'm encouraged=20 that you're working on client code. :) Having an RFC is going to be an extremely important step to actually=20 seeing this problem solved. That said, I did not want to spend time on=20 something that would be met with total rejection. It sounds like there=20 is at least enough interest to start a meaningful dialog, so I'll try to= =20 put together a draft soon and we can go from there. If you're=20 interested to collaborate on that, you're certainly welcome. Paul ------ Original Message ------ From: "Marten Gajda" To: webfinger@ietf.org Sent: 2/8/2016 5:54:58 PM Subject: Re: [webfinger] [apps-discuss] Mail client configuration via=20 WebFinger >Hi Paul, > >as a client developer I'm very interested in this topic. We've actually= =20 >implemented draft-daboo-aggregated-service-discovery-03 and there is at= =20 >least one groupware server product which also supports it. > >While working on our implementation we've identified a few minor issues= =20 >with the latest draft and we've already discussed them with Cyrus. I=20 >think most of these issues are solved easily. > >Though, the major issue has not been addressed yet. It's the issue=20 >mentioned by Stephen. Under certain conditions a client might have to=20 >ask the user upfront to authenticate, which may disclose the user's=20 >credentials to the wrong service. > >We didn't release this feature in our generic CalDAV/CardDAV clients,=20 >mostly due to that issue. > >Anyway, I think it really starts with the server developers.=20 >Implementing the current spec is not that much work on the server side.= =20 >In many cases the server configuration document could just be a static=20 >file and setting up a simple WebFinger end point is not that hard=20 >either. Actually, for our corporate server we've just created a few=20 >static files and some redirect magic in our .htaccess file to provide=20 >the WebFinger stuff. > >On the client side it's more work, because it affects the account setup= =20 >flow a lot. But it surely is worth the efforts if more services support= =20 >it. > >However, before even the server developers can start, it requires an=20 >RFC. So lets start to think about how to solve the authentication=20 >issue. > >cheers > >Marten > > >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=20 >>>adopted given the use of device management. Before embarking on this=20 >>>we need to take a careful look at whether any solution is likely to=20 >>>be adopted (with the biggest burden likely being on clients/OS=20 >>>vendors to support it). Given the device management solutions already= =20 >>>out there, I suspect there would be little value to m,ost of those=20 >>>folks to actually support ASCOT. >> >>I completely agree that we should try to get a sense of the likelihood= =20 >>of success. >> >>Within the enterprise -- especially the larger ones -- you are=20 >>entirely correct that device management systems provide a good=20 >>solution for most of the employees. However, I interact with a lot=20 >>of smaller businesses that do not use such systems. Many of them have= =20 >>a web hosting company host their domains and do not have IT staff to=20 >>help them on a daily basis. I'm skeptical that a device management=20 >>system would help that class of users, so arming hosting providers=20 >>with tools they can deploy to their customers would help, I think. >> >>There are also a number of individuals who have their own domains,=20 >>many hosted on the many, many web hosting providers out there. Same=20 >>issue for most of them. >> >>So, I think there is a market need. I suspect if we were to create a=20 >>solution, hosting providers were to deploy it, and client developers=20 >>were to support it, people would use it. However, that's a string of=20 >>"ifs". I think it starts with the client developers. If there were=20 >>people interested to solve the problem, I think the rest falls into=20 >>place. >> >>All that said, if client developers are uninterested, there's little=20 >>point working to solve this problem. >> >>>As an alternative, the IETF might want to take a more serious look at= =20 >>>the overall device management solutions, and see if there might be=20 >>>scope for standards in that area. That would allow us to build off=20 >>>something that is already deployed (in a number of proprietary=20 >>>solutions) but is today solving the problem of account setup. >> >>I think your suggestion is worthwhile independent of whether we solve=20 >>the problem for smaller businesses and individual users of hosted=20 >>domains. It would good if the same solution or would address those=20 >>needs of smaller businesses and individuals, but if it didn't, it's=20 >>still a step forward. >> >>Paul >> >>_______________________________________________ >>webfinger mailing list >>webfinger@ietf.org >>https://www.ietf.org/mailman/listinfo/webfinger > >-- Marten Gajda >CEO > >dmfs GmbH >Schandauer Stra=C3=9Fe 34 >01309 Dresden >GERMANY > >phone: +49 177 4427167 >email: marten@dmfs.org > >Managing Director: Marten Gajda >Registered address: Dresden >Registered No.: AG Dresden HRB 34881 >VAT Reg. No.: DE303248743 > >_______________________________________________ >webfinger mailing list >webfinger@ietf.org >https://www.ietf.org/mailman/listinfo/webfinger