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

Marten Gajda <> Wed, 08 June 2016 19:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E4CA12D73B for <>; Wed, 8 Jun 2016 12:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.019
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 179ggxwsSauU for <>; Wed, 8 Jun 2016 12:35:16 -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 78E5F12D79C for <>; Wed, 8 Jun 2016 12:35:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; 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 (unknown []) by (Halon Mail Gateway) with ESMTPSA for <>; Wed, 8 Jun 2016 19:35:07 +0000 (UTC)
Received: from localhost.localdomain ( []) by (Postfix) with ESMTPSA id 3AAB42FB for <>; Wed, 8 Jun 2016 21:30:41 +0200 (CEST)
Message-ID: <>
Date: Wed, 08 Jun 2016 21:35:05 +0200
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
References: <em44c60c65-2d14-46a0-adb3-a52d38d160ed@helsinki> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------060503040007080101090807"
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: Wed, 08 Jun 2016 19:35:20 -0000


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.
> 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
>>> 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
>>> CEO
>>> dmfs GmbH
>>> Schandauer Straße 34
>>> 01309 Dresden
>>> 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
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> 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

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