Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger
"Paul E. Jones" <paulej@packetizer.com> Mon, 11 July 2016 21:31 UTC
Return-Path: <paulej@packetizer.com>
X-Original-To: webfinger@ietfa.amsl.com
Delivered-To: webfinger@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B2812D0C3 for <webfinger@ietfa.amsl.com>; Mon, 11 Jul 2016 14:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.288
X-Spam-Level:
X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
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 4Fhs2PrAuBjg for <webfinger@ietfa.amsl.com>; Mon, 11 Jul 2016 14:31:53 -0700 (PDT)
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 4472312D0B7 for <webfinger@ietf.org>; Mon, 11 Jul 2016 14:31:53 -0700 (PDT)
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 u6BLVled030567 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Jul 2016 17:31:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1468272708; bh=5c0vPvlhliQpy9Mo8UkDKJpGCFe2kyALXNBQ+UaG2ko=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=SXnVNpWQjUXLUwUMpvbanZxnzmJrzqPnlr5JXoIgW83f+i2lYOicCHjFlnrM9Lfmg cq7CjDX8Vro2l+rZLIX3Abs29C8YxRkuPUGdeOYviFWuPfYzyCt7YO7o/F9yAMNfhy c0yxbq1/jZ+cxEJoxPwul3KrwS1D9+xldViBlmqk=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Marten Gajda <marten@dmfs.org>, "webfinger@ietf.org" <webfinger@ietf.org>
Date: Mon, 11 Jul 2016 21:31:52 +0000
Message-Id: <em1601bf25-0972-435d-8537-b3a6d19b5b33@sydney>
In-Reply-To: <57587369.20405@dmfs.org>
References: <em44c60c65-2d14-46a0-adb3-a52d38d160ed@helsinki> <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org> <57587369.20405@dmfs.org>
User-Agent: eM_Client/7.0.26482.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBA22A7604-4F2C-4CD5-9240-2B950ECCDE72"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Mon, 11 Jul 2016 17:31:48 -0400 (EDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/webfinger/eAKL6UMsTj8Y-SjfjcsPoI3HWe4>
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger
X-BeenThere: webfinger@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <webfinger.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webfinger>, <mailto:webfinger-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webfinger/>
List-Post: <mailto:webfinger@ietf.org>
List-Help: <mailto:webfinger-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webfinger>, <mailto:webfinger-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2016 21:31:56 -0000
Marten, Sorry to just be coming back to this after a whole month passed. What current draft? Did you write one that I missed? Or are these requirements for the draft you would like to see? Paul ------ Original Message ------ From: "Marten Gajda" <marten@dmfs.org> To: "webfinger@ietf.org" <webfinger@ietf.org> Sent: 6/8/2016 3:35:05 PM Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger >All, > >I've created a GitHub repository to track open issues with the current >draft, see https://github.com/CalConnect/AUTODISCOVERY/issues >You're welcome to contribute to the discussion, either by creating a >new issue or by commenting on an existing one. > >Thanks, > >Marten > >Am 05.06.2016 um 23:00 schrieb Marten Gajda: >>I think OpenID Connect already covers the discovery of everything you >>need to do OAuth2. That involves Webfinger, but there is no need to >>protect this request, because it doesn't contain personal information. >>So we don't need to reinvent the OAuth2 bootstrapping sequence. >>The only minor issue I see is that you may have to ask the user twice >>to grant access. Once to authorize the client to access the >>configuration document and another time to authorize the client to >>access the individual services. The second step is necessary, because >>the scope tokens of these services are not known when the first >>authorization request is presented to the user. The problem with that >>is, there doesn't seem to be a mechanism to broaden scope, without >>allowing the user to switch to a different account. To get access to >>the individual services, the client needs to start another >>authorization code grant. But the user is always free to log out and >>log in with a different account before granting access. >> >>Marten >> >>Am 03.06.2016 um 20:13 schrieb George Fletcher: >>>Did a quick scan of the draft document. Given that more and more >>>systems are trying to remove the need for passwords, it seems like >>>the final solution needs to support 2FA and biometric mechanisms for >>>"HTTP authentication". I definitely would not want the webfinger >>>instance releasing my config data without my "authentication". I >>>suppose OAuth2 could be used to protect the webfinger APIs though >>>there is a bit of a chicken-and-egg here:) >>> >>>I kind of like the suggestion around returning a 401 with data in the >>>WWW-Authenticate header on where to get a token to use with the API. >>>This would allow the client to start and OAuth2 flow with the >>>Authorization Server specified and that would give the user a clear >>>indication of what password/credentials are being requested. Once the >>>client gets the token, it uses it with the webfinger call and now the >>>service-configuration data is returned because the token is the >>>authorization for the specified id. >>> >>>Thanks, >>>George >>> >>>On 6/3/16 10:44 AM, Marten Gajda wrote: >>>>Note that the idea behind >>>>https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 >>>>is to put the service configuration for all services of a provider >>>>into a single document. >>>> >>>>So you would receive something like this: >>>> >>>>{ >>>> "rel " : "service-configuration", >>>> "href " : "https://example.com/service-configuration" >>>>} >>>> >>>>If a user uses the same account identifier at another provider the >>>>Webfinger request could return their configuration too (given there >>>>is some mechanism to add it and the provider actually supports >>>>that). >>>> >>>>{ >>>> "rel " : "service-configuration", >>>> "href " : "https://example.com/service-configuration" >>>>}, >>>>{ >>>> "rel " : "service-configuration", >>>> "href " : "https://acme-calendar.com/service-configuration" >>>>} >>>> >>>>Without that it would be more difficult to setup your account at >>>>acme-calendar.com with your login "user@example.com". >>>>acme-calendar.com would have to issue some kind of user-identifier >>>>like user@acme-calendar.com for auto-configuration purposes, even >>>>though you don't use it for authentication (because you use >>>>user@exampe.com for authentication). I think that's the idea behind >>>>the `acct:` URI scheme, but I don't think that you can explain to >>>>users why they need another user identifier and when to use one or >>>>the other. >>>>But that also raises the privacy concerns I mentioned earlier. If >>>>the request is not authenticated, everyone could see that you have >>>>an account at acme-calendar.com. >>>> >>>>Regarding SSO: There is an RFC that extends SASL based >>>>authentication to support the token authentication mechanisms as >>>>used by OAuth1 and OAuth2, see https://tools.ietf.org/html/rfc7628 >>>>So SSO already works with IMAP, POP3 and SMTP. >>>> >>>>Cheers >>>> >>>>Marten >>>> >>>> >>>> >>>>Am 03.06.2016 um 15:40 schrieb Paul E. Jones: >>>>>Marten, >>>>> >>>>> >>>>>>So how would the UI work? >>>>>> >>>>>>1) User enters user identifier, most likely an email address, like >>>>>>mailto:user@example.com and hits "next" >>>>>> >>>>>>2) Client sends a Webfinger request to >>>>>>https://exampe.com/.well-known/webfinger?... to see if there is a >>>>>>configuration document >>>>>> >>>>>> -> response 404 Not Found >>>>>> a) Client falls back to "manual setup" or another >>>>>>auto-configuration mechanism >>>>>> >>>>>> -> response 401 Unauthorized >>>>> >>>>>One should not get 401 querying the WebFinger information for the >>>>>user. What should happen is that the server should return a JSON >>>>>object that contains a link relation that might look like this: >>>>>{ >>>>> "rel " : "mail-config", >>>>> "href " : >>>>>"https://mailserver.example.com/config?user=paulej%40packetizer.com" >>>>>} >>>>> >>>>>Or something like that. The mail client should query that URI it >>>>>is that one that should result in a potential 401. The JSON format >>>>>that would come back here would need to be something we define. It >>>>>could be based on JRD, but would not have to be. >>>>> >>>>>Otherwise, I think the flow looks right. >>>>> >>>>> >>>>>> >>>>>> b) Client asks for password at "example.com" and goes back to >>>>>>step 2 (this time with authentication) >>>>>> >>>>>> -> response 200 Ok >>>>>> c) client moves on to next step >>>>>> >>>>>>3) (optional) Client presents found services to the user to let >>>>>>him select the services to set up >>>>>> >>>>>>4) Client runs the setup handler for each selected service >>>>>> >>>>>> >>>>>>I think in general that could work but it raises two questions: >>>>>> >>>>>>1) How to make sure the user really understands that he's >>>>>>authenticating at example.com in step 2b? If the user tries to >>>>>>configure calendar sync with "acme-calendar.com" where his login >>>>>>happens to be mailto:user@example.com he might not be prepared to >>>>>>being asked for his example.com password. Maybe I'm just paranoid >>>>>>or overcautious, but I think that it might easily happen that the >>>>>>users sends his acme-calendar.com password to example.com in that >>>>>>case (since Basic authentication is still the most common >>>>>>mechanism, the client basically sends the password in plain text). >>>>> >>>>>Yeah, that's a valid concern. The only thing I can suggest is that >>>>>the Subject CN from the certificate is presented to the user. >>>>>Alternatively, there could be two passwords: one that is the >>>>>"configuration password" and one that is the email password. >>>>>However, I don't think two passwords will help us. If I want to >>>>>hack somebody and can gain access to their WF config, I can >>>>>auto-config their email client to point to my own IMAP server and >>>>>just retrieve the password that way. >>>>> >>>>>So, I think we have to rely on the certificate presented to the >>>>>mail client and the user will have to know to trust it. The mail >>>>>provider can tell the user "when configuring email, ensure that the >>>>>configuration server is mailconfig.example.com and do not provide a >>>>>password if that is not the name of the configuration server >>>>>indicated." >>>>> >>>>>If the mail config information is not protected with a password, we >>>>>probably would want the customer to verify that the SMTP server >>>>>information is correct before the password is provided. These >>>>>would be the steps users would take if performing manual >>>>>configuration, but the software presents that information to the >>>>>user without the user having to enter it. >>>>> >>>>> >>>>>> >>>>>>2) How does the client know which credentials to use to set up the >>>>>>individual services in step 4? Should the client ask the user for >>>>>>the credentials for each service or can it assume that some of >>>>>>them share the same credentials? Is that something an >>>>>>auto-configuration document can help with? >>>>> >>>>>It would be nice if there is a config indicator that says "SMTP >>>>>server and IMAP server passwords are the same", so the client does >>>>>not have to ask. >>>>> >>>>>If we use a "config password" then we could even have the server >>>>>tell the client the password for services, which would >>>>>transparently allow those to be different. Alternatively, the >>>>>client will have to ask each about each one. >>>>> >>>>>For calendaring services, then yes: the client would have to ask >>>>>the user. It could ask if it's the same or different than the >>>>>email password or the config password. For some services, the >>>>>authentication mechanisms will be entirely different (like Google >>>>>Calendar). The mail client will just have to know how to access >>>>>the service. For that reason, I'm a little hesitant to suggest >>>>>including calendaring service config along with the email config >>>>>data. We could have each of those services listed in the users' >>>>>WebFinger document. For example, I might have this entry in my WF >>>>>document: >>>>>{ >>>>> "rel" : "calendar" >>>>> "href" : "urn:whatever:google" >>>>>} >>>>> >>>>>Note I did not provide a URL. The reason is that this is an >>>>>entirely different service that has an entirely different access >>>>>method. Maybe the client can ask the user "is >>>>>paulej@packetizer.com our user ID for your Google calendar?" In my >>>>>case, I don't think it is. Certainly, it's not my gmail ID. And, >>>>>I would not want to advertise that to the world, necessarily. >>>>>Anyway, I think we should limit the scope of what we try to do to >>>>>things that are standard OR we define a generic URN that a client >>>>>will just have to know how to deal with. >>>>> >>>>> >>>>>>Ideally the server supports some kind of SSO mechanism like OpenID >>>>>>Connect, so you don't need to enter your password multiple times. >>>>>>But a working auto-configuration is really the precondition for >>>>>>this, because an OpenID Connect implementations needs a way to >>>>>>discover the OAuth2 scope tokens to request from the server and >>>>>>auto-configuration is really the way to do that, IMO. For this it >>>>>>would be helpful to have some mechanism to request a broader scope >>>>>>from the user (without allowing him to switch to a different >>>>>>account), but that's a different topic I guess. >>>>> >>>>>I definitely like the idea of SSO. But, I struggle to see how we >>>>>would use this in practice with mail autoconfig since SMTP, IMAP, >>>>>and POP servers require a password, anyway. If we use that as a >>>>>means to have those passwords provided behind the scenes (as I >>>>>indicated above), that might be a good argument for using OpenID >>>>>Connect. In that way, the ISP can also ensure that passwords are >>>>>REALLY complex and unknown even to the user. Not a bad practice, >>>>>in that we can view those passwords as complex tokens. >>>>> >>>>>Would that kind of use of OpenID Connect to retrieve the password >>>>>be workable? (I'll admit I don't have so much experience with >>>>>OpenID Connect. I implemented OpenID 2.0, but that's not ideal for >>>>>what we'd want to accomplish here. I don't have a good feel for >>>>>how Connect might make this better.) >>>>> >>>>>Paul >>>>> >>>>> >>>>> >>>>>_______________________________________________ webfinger mailing >>>>>list >>>>>webfinger@ietf.orghttps://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 >>>> >>>>_______________________________________________ webfinger mailing >>>>list >>>>webfinger@ietf.orghttps://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 >> >>_______________________________________________ webfinger mailing list >>webfinger@ietf.orghttps://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
- Re: [webfinger] [apps-discuss] Mail client config… Dave Cridland
- Re: [webfinger] [apps-discuss] Mail client config… Paul E. Jones
- [webfinger] Mail client configuration via WebFing… Paul E. Jones
- Re: [webfinger] [apps-discuss] Mail client config… Cyrus Daboo
- Re: [webfinger] [apps-discuss] Mail client config… Paul E. Jones
- Re: [webfinger] [apps-discuss] Mail client config… Stephen Farrell
- Re: [webfinger] [apps-discuss] Mail client config… Paul E. Jones
- Re: [webfinger] [apps-discuss] Mail client config… Marten Gajda
- Re: [webfinger] [apps-discuss] Mail client config… Paul E. Jones
- Re: [webfinger] [apps-discuss] Mail client config… Paul E. Jones
- Re: [webfinger] [apps-discuss] Mail client config… Marten Gajda
- Re: [webfinger] [apps-discuss] Mail client config… Mikael Nordfeldth
- Re: [webfinger] [apps-discuss] Mail client config… Paul E. Jones
- Re: [webfinger] [apps-discuss] Mail client config… Eric Mill
- Re: [webfinger] [apps-discuss] Mail client config… Paul E. Jones
- Re: [webfinger] [apps-discuss] Mail client config… Marten Gajda
- Re: [webfinger] [apps-discuss] Mail client config… Paul E. Jones
- Re: [webfinger] [apps-discuss] Mail client config… Marten Gajda
- Re: [webfinger] [apps-discuss] Mail client config… Paul E. Jones
- Re: [webfinger] [apps-discuss] Mail client config… Marten Gajda
- Re: [webfinger] [apps-discuss] Mail client config… John Levine
- Re: [webfinger] [apps-discuss] Mail client config… Paul E. Jones
- Re: [webfinger] [apps-discuss] Mail client config… Marten Gajda
- Re: [webfinger] [apps-discuss] Mail client config… Marten Gajda
- Re: [webfinger] [apps-discuss] Mail client config… Paul E. Jones
- Re: [webfinger] [apps-discuss] Mail client config… Marten Gajda
- Re: [webfinger] [apps-discuss] Mail client config… George Fletcher
- Re: [webfinger] [apps-discuss] Mail client config… Marten Gajda
- Re: [webfinger] [apps-discuss] Mail client config… Marten Gajda