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

"Paul E. Jones" <> Mon, 11 July 2016 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39B2812D0C3 for <>; Mon, 11 Jul 2016 14:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.288
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4Fhs2PrAuBjg for <>; Mon, 11 Jul 2016 14:31:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4472312D0B7 for <>; Mon, 11 Jul 2016 14:31:53 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (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;; 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" <>
To: Marten Gajda <>, "" <>
Date: Mon, 11 Jul 2016 21:31:52 +0000
Message-Id: <em1601bf25-0972-435d-8537-b3a6d19b5b33@sydney>
In-Reply-To: <>
References: <em44c60c65-2d14-46a0-adb3-a52d38d160ed@helsinki> <> <> <> <>
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 ( []); Mon, 11 Jul 2016 17:31:48 -0400 (EDT)
Archived-At: <>
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger
X-Mailman-Version: 2.1.17
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, 11 Jul 2016 21:31:56 -0000


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?


------ Original Message ------
From: "Marten Gajda" <>
To: "" <>
Sent: 6/8/2016 3:35:05 PM
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via 

>I've created a GitHub repository to track open issues with the current 
>draft, see
>You're welcome to contribute to the discussion, either by creating a 
>new issue or by commenting on an existing one.
>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.
>>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.
>>>On 6/3/16 10:44 AM, Marten Gajda wrote:
>>>>Note that the idea behind 
>>>>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 " : ""
>>>>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 
>>>>     "rel " :  "service-configuration",
>>>>     "href " : ""
>>>>     "rel " :  "service-configuration",
>>>>     "href " : ""
>>>>Without that it would be more difficult to setup your account at 
>>>> with your login "". 
>>>> would have to issue some kind of user-identifier 
>>>>like for auto-configuration purposes, even 
>>>>though you don't use it for authentication (because you use 
>>>> 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
>>>>Regarding SSO: There is an RFC that extends SASL based 
>>>>authentication to support the token authentication mechanisms as 
>>>>used by OAuth1 and OAuth2, see
>>>>So SSO already works with IMAP, POP3 and SMTP.
>>>>Am 03.06.2016 um 15:40 schrieb Paul E. Jones:
>>>>>>So how would the UI work?
>>>>>>1) User enters user identifier, most likely an email address, like 
>>>>>> and hits "next"
>>>>>>2) Client sends a Webfinger request to 
>>>>>> 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 " : 
>>>>>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 "" 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 in step 2b? If the user tries to 
>>>>>>configure calendar sync with "" where his login 
>>>>>>happens to be he might not be prepared to 
>>>>>>being asked for his password. Maybe I'm just paranoid 
>>>>>>or overcautious, but I think that it might easily happen that the 
>>>>>>users sends his password to 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 and do not provide a 
>>>>>password if that is not the name of the configuration server 
>>>>>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 
>>>>>     "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 
>>>>> 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.)
>>>>>_______________________________________________ webfinger mailing 
>>>>-- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden 
>>>>GERMANY phone: +49 177 4427167 email: Managing 
>>>>Director: Marten Gajda Registered address: Dresden Registered No.: 
>>>>AG Dresden HRB 34881 VAT Reg. No.: DE303248743
>>>>_______________________________________________ webfinger mailing 
>>-- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden 
>>GERMANY phone: +49 177 4427167 email: Managing 
>>Director: Marten Gajda Registered address: Dresden Registered No.: AG 
>>Dresden HRB 34881 VAT Reg. No.: DE303248743
>>_______________________________________________ webfinger mailing list 
>-- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden 
>GERMANY phone: +49 177 4427167 email: Managing 
>Director: Marten Gajda Registered address: Dresden Registered No.: AG 
>Dresden HRB 34881 VAT Reg. No.: DE303248743