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

George Fletcher <> Fri, 03 June 2016 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DCF712D85C for <>; Fri, 3 Jun 2016 11:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.026
X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 fK-jQp5BjUsL for <>; Fri, 3 Jun 2016 11:13:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7ED7912D85D for <>; Fri, 3 Jun 2016 11:13:49 -0700 (PDT)
Received: from ( []) by (Outbound Mail Relay) with ESMTP id B50E7380009F; Fri, 3 Jun 2016 14:13:48 -0400 (EDT)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (MUA/Third Party Client Interface) with ESMTPSA id 30FA938000090; Fri, 3 Jun 2016 14:13:48 -0400 (EDT)
To: Marten Gajda <>, "" <>
References: <em44c60c65-2d14-46a0-adb3-a52d38d160ed@helsinki> <>
From: George Fletcher <>
Organization: AOL LLC
Message-ID: <>
Date: Fri, 03 Jun 2016 14:13:47 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------CA1E0F0B90EEB1E064781E81"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; t=1464977628; bh=q6PsLmSGHFpLzScq9YOwyDNzdhTZ7B3MTXdjYEphOC4=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=1NvaWLEx8KFvpUv8iiD+XrwoerGW21qNRj1MMdVtYa1rHg94AHPlw82RcUj7KDarC 1iuqA7pSnwse8gbMf6EcYnBLCw/8BuWU79ar9d0HQkljR9qq6kbiMYfyS2WkQHiuxb mJTTPDIMmgb2F9busB03WC2IA9O+CQ3DAwZNy1Uo=
x-aol-sid: 3039ac1a7e4d5751c8dc09ca
Archived-At: <>
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger
X-Mailman-Version: 2.1.17
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: Fri, 03 Jun 2016 18:13:53 -0000

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 that).
> {
>     "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.
> 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 
>>> 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 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 
>> <> 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
> -- 
> Marten Gajda
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> phone: +49 177 4427167
> Managing Director: Marten Gajda
> Registered address: Dresden
> Registered No.: AG Dresden HRB 34881
> VAT Reg. No.: DE303248743
> _______________________________________________
> webfinger mailing list