Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger
Marten Gajda <marten@dmfs.org> Wed, 08 June 2016 19:35 UTC
Return-Path: <marten@dmfs.org>
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 0E4CA12D73B for <webfinger@ietfa.amsl.com>; Wed, 8 Jun 2016 12:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level:
X-Spam-Status: No, score=-2.019 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org
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 179ggxwsSauU for <webfinger@ietfa.amsl.com>; Wed, 8 Jun 2016 12:35:16 -0700 (PDT)
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 78E5F12D79C for <webfinger@ietf.org>; Wed, 8 Jun 2016 12:35:11 -0700 (PDT)
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:in-reply-to: references; bh=qyLBGKBqho8MR9X3CLrhCY/Nu8ZKVi14ZSXyZ8xCNO4=; b=JuQbPxVeXF81rh96uyIkC+bMgE3e5KmcceuxQpmtUnfhhyVJWvyBUd6dF5kzeTfO+h5iwMh1VD0fF LMpehu+B8DJvesVqh7vbuPlr3WmO2Jbzjt4Z52EDfcmgmJcdGkd01kojvU36F5Sf+KnF7IYEFE4i3m MmZ6RHTQYelAB92w=
X-HalOne-Cookie: 835a0043f271a4e1170ef8ef287d3768c070bc3a
X-HalOne-ID: 1aff6b81-2db0-11e6-a0c6-b82a72cffc46
Received: from smtp.dmfs.org (unknown [217.234.102.98]) by smtpfilter4.public.one.com (Halon Mail Gateway) with ESMTPSA for <webfinger@ietf.org>; Wed, 8 Jun 2016 19:35:07 +0000 (UTC)
Received: from localhost.localdomain (p5DDA907C.dip0.t-ipconnect.de [93.218.144.124]) by smtp.dmfs.org (Postfix) with ESMTPSA id 3AAB42FB for <webfinger@ietf.org>; Wed, 8 Jun 2016 21:30:41 +0200 (CEST)
Message-ID: <57587369.20405@dmfs.org>
Date: Wed, 08 Jun 2016 21:35:05 +0200
From: Marten Gajda <marten@dmfs.org>
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: <em44c60c65-2d14-46a0-adb3-a52d38d160ed@helsinki> <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org>
In-Reply-To: <575492E1.2000805@dmfs.org>
Content-Type: multipart/alternative; boundary="------------060503040007080101090807"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webfinger/_6ZSDMbSJuiPDqcDe2iFCYyHvDU>
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger
X-BeenThere: webfinger@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Wed, 08 Jun 2016 19:35:20 -0000
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.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 >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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
- 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