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

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 11 Jul 2016 21:31:52 +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" <[email-masked]>
To: "[email-masked]" <[email-masked]>
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 "[email-masked]". 
>>>>acme-calendar.com would have to issue some kind of user-identifier 
>>>>like [email-masked] for auto-configuration purposes, even 
>>>>though you don't use it for authentication (because you use 
>>>>[email-masked] 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:[email-masked] 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:[email-masked] 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 
>>>>>[email-masked] 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 
>>>>>[email-masked]://www.ietf.org/mailman/listinfo/webfinger
>>>>
>>>>
>>>>-- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden 
>>>>GERMANY phone: +49 177 4427167 email: [email-masked] Managing 
>>>>Director: Marten Gajda Registered address: Dresden Registered No.: 
>>>>AG Dresden HRB 34881 VAT Reg. No.: DE303248743
>>>>
>>>>_______________________________________________ webfinger mailing 
>>>>list 
>>>>[email-masked]://www.ietf.org/mailman/listinfo/webfinger
>>>
>>
>>-- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden 
>>GERMANY phone: +49 177 4427167 email: [email-masked] Managing 
>>Director: Marten Gajda Registered address: Dresden Registered No.: AG 
>>Dresden HRB 34881 VAT Reg. No.: DE303248743
>>
>>_______________________________________________ webfinger mailing list 
>>[email-masked]://www.ietf.org/mailman/listinfo/webfinger
>
>-- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden 
>GERMANY phone: +49 177 4427167 email: [email-masked] Managing 
>Director: Marten Gajda Registered address: Dresden Registered No.: AG 
>Dresden HRB 34881 VAT Reg. No.: DE303248743

---

From: Marten Gajda <[email-masked]>
Date: Thu, 14 Jul 2016 00:32:01 +0200

Hi Paul,

the "current draft" is still the one at
https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03
and the issues at GitHub are discussion items for the upcoming draft.
I wanted to clarify a few points before I start to work on the draft. If
you have anything to add to these points or if you have any other
concerns, please let me know, so we can address them.
Unless there is some more interest in the certificate stuff, I'm not
going to add this to the draft. We still can add that later on if it
turns out to be useful.

Cheers,

Marten

Am 11.07.2016 um 23:31 schrieb Paul E. Jones:
> From: "Marten Gajda" <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked]" <[email-masked] <mailto:[email-masked]>>
>> I've created a GitHub repository to track open issues with the
>> current draft, see https://github.com/CalConnect/AUTODISCOVERY/issues
>>> 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.
>>> 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
>>> 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
>>>> 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
>>>> 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
>>>>
>>>>> Webfinger request could return their configuration too (given
>>>>> there is some mechanism to add it and the provider actually
>>>>> supports that).
>>>>>
>>>>> {
>>>>> [email-masked] 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.
>>>>>>> 1) User enters user identifier, most likely an email address,
>>>>>>> like mailto:[email-masked] and hits "next"
>>>>>>>
>>>>>>> https://exampe.com/.well-known/webfinger?... to see if there is
>>>>>>> a configuration document
>>>>>>>
>>>>>> 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.
>>>>>>  
>>>>>>> happens to be mailto:[email-masked] 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. 
>>>>>> 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
>>>>>>> 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
>>>>>> server and IMAP server passwords are the same", so the client
>>>>>> does not have to ask.
>>>>>>  
>>>>>> WebFinger document.  For example, I might have this entry in my
>>>>>> WF document:
>>>>>> {
>>>>>>     "rel" : "calendar"
>>>>>> [email-masked] 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.
>>>>>>  
>>>>>> 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
>>>>>>  
>>>>>>
>>>>>>
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/webfinger
>>>>>
>>>>>
>>>>> -- 
>>>>> Marten Gajda
>>>>> CEO
>>>>>
>>>>> dmfs GmbH
>>>>> Schandauer Straße 34
>>>>> 01309 Dresden
>>>>> GERMANY
>>>>>
>>>>> phone: +49 177 4427167
>>>>> email: [email-masked]
>>>>>
>>>>> Managing Director: Marten Gajda
>>>>> Registered address: Dresden
>>>>> Registered No.: AG Dresden HRB 34881
>>>>> VAT Reg. No.: DE303248743
>>>>>
>>>>>
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/webfinger
>>>>
>>>
>>> -- 
>>> Marten Gajda
>>> CEO
>>>
>>> dmfs GmbH
>>> Schandauer Straße 34
>>> 01309 Dresden
>>> GERMANY
>>>
>>> phone: +49 177 4427167
>>> email: [email-masked]
>>>
>>> Managing Director: Marten Gajda
>>> Registered address: Dresden
>>> Registered No.: AG Dresden HRB 34881
>>> VAT Reg. No.: DE303248743
>>>
>>>
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/webfinger
>>
>> -- 
>> Marten Gajda
>> CEO
>>
>> dmfs GmbH
>> Schandauer Straße 34
>> 01309 Dresden
>> GERMANY
>>
>> phone: +49 177 4427167
>> email: [email-masked]
>>
>> Managing Director: Marten Gajda
>> Registered address: Dresden
>> Registered No.: AG Dresden HRB 34881
>> VAT Reg. No.: DE303248743
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 14 Jul 2016 06:19:34 +0000

Marten,

I'll comment on each point:

General:
While I supported the original work a few years ago, it was killed 
partly because some people stood up and said "we already have several 
discover protocols, why do we need another.  And you were presented with 
much the same on this list when people asked why the DNS mechanism is 
insufficient.  You provided some good arguments, of which I think 
individualized configuration is most important.  Let's make sure the new 
draft is scoped to just mail configuration.  (If we want to go further 
with calendar, contacts, etc. then arguably those should be separate 
URLs.  My mail and calendar is not provided by the same provider, for 
example.)

Caching: HTTP allows one to dictate that how long cached data can live. 
I don't think we need to specify it further.  A client will pull the 
config when the user configures the client.  There's no reason to cache 
it beyond that point.  In the off chance it queries a second time, it's 
not a big deal.  It might get pulled from web cache or perhaps go back 
to the server.  It really does not matter, since this should not be 
queried over and over.  Only in the event that a config change is made, 
the client might need to re-query the config data.  I'm not sure if the 
client should automate that process or prompt the user "would you like 
me to re-validate the configuration settings?" Personally, I like the 
latter.

Certificate pinning: Why? One fetches the mail config file.  The client 
will authenticate the certificate. Is this just to catch the very rare 
case where somebody hacks DNS and gets a fake certificate?  That's 
really a broader Internet infrastructure issue that I think we should 
solve generically.  (For example, use of notaries, DNSSEC/DANE, etc. 
Personally, I use DNSSEC/DANE, but somewhere close to zero people make 
use of that data.)

Certificate Auth: I'm not sure what the problem is here, unless people 
want to use enterprise-issued certificates (i.e., those that are not 
from a public CA).  If that is the case, I would not want my mail client 
to insert those into my trusted certificate store.  So, would those be 
one-time uses?  Not very useful.  I'd say the IT department needs to 
install whatever root certs are needed.  A client should authenticate 
the certificates it sees, but we don't need more words about it other 
than to say the TLS connection must be authenticated.

Document structure:  I think keeping this simple is really best.  I 
don't think we need multiple mail providers. If the email address is 
[email-masked], then I think it's reasonable to assume example.com is 
the provider.  Yes, a user could go enter WebFinger information for some 
other provider, but the average person will not want to do that.  That's 
having the user configure the server so it can configure the client.  
Not much gained there.  I would have something that's no more complex 
than something like this:

>{
>  "incoming" :
>  [
>    {
>      "description" : "IMAP",
>      "protocol" : "imap",
>      "servers" :
>      [
>        {
>          "host" : "imap-01.example.com",
>          "port" : 143,
>          "transport" : "starttls"
>        },
>        {
>          "host" : "imap-02.example.com",
>          "port" : 143,
>          "transport" : "starttls"
>        }
>      ]
>    },
>    {
>      "description" : "POP",
>      "protocol" : "pop3",
>      "servers" :
>      [
>        {
>          "host" : "imap-01.example.com",
>          "port" : 110,
>          "transport" : "starttls"
>        },
>        {
>          "host" : "imap-02.example.com",
>          "port" : 110,
>          "transport" : "starttls"
>        }
>      ]
>    }
>  ],
>  "outgoing" :
>  [
>    {
>      "description" : "SMTP",
>      "protocol" : "smtp",
>      "servers" :
>      [
>        {
>          "host" : "smtp-01.example.com",
>          "port" : 587,
>          "transport" : "starttls"
>        },
>        {
>          "host" : "smtp-02.example.com",
>          "port" : 587,
>          "transport" : "starttls"
>        },
>        {
>          "host" : "smtp-01.example.com",
>          "port" : 465,
>          "transport" : "tls"
>        },
>        {
>          "host" : "smtp-02.example.com",
>          "port" : 465,
>          "transport" : "tls"
>        }
>      ]
>    }
>  ]
>}

I use a arrays to offer different protocols (POP3 and IMAP) with 
descriptions to let the user choose.  If there is only one choice (as in 
the case of SMTP), then the user need not be bothered with selection. 
There are multiple servers, each intended to be an alternative listed in 
order of preference.

I would define a document for each service that might be made available 
through WebFinger (email config, calendar config, contacts config).  
And, each of these documents would be discovered via a different URI.  
So, in the JRD returned via the WebFinger query, there might be this a 
"rel" of type "email" with a URI and another of type "contacts", 
"calendar", etc.  (I did not check to see which rel values are used, but 
the names are not important.)

When a user enters his or her email address, the client can discover 
which of those services are available and offer them, allowing the user 
to use or not use each one.  In my case, calendaring is not provided at 
my domain.  So, I would go to my email program and say "add an account" 
and enter a new email address.  Since each set of services is 
individually selectable by the user, it's easy to mix and match email, 
calendaring, contacts, or whatever from different places.  It will 
require entering different account credentials, but I think that should 
be the way it works.

TLS ought to be required, but it could be left to the admin.  WebFinger 
requires it, but I seriously do not see the security concerns with a 
simple mail config file like the above.  But, if people want to secure 
it, they can.  And security should be through whatever mechanisms HTTP 
presents to the user.  I would not want to invent new ones or try to 
solve how to do something hypothetically.  My mail server requires a 
password and I think it's reasonable the HTTP server require the same.  
Perhaps my calendar requires OAuth.  We could put the URI to the 
authorization server as a property in the WebFinger reply, like this:

>{
>  "rel" : "mail-config",
>  "href" : "https://mail-config.example.com/paulej",
>  "properties" : {
>    "urn:ietf:params:oauth:authserver" : 
>"https://oauth.example.com/paulej"
>  }
>}

That might be insufficient for OAuth, since just having the URI to the 
auth server isn't enough for the Auth server, I think, as it would not 
necessarily understand the "client_id" parameter.  However, I'm not a 
guru in OAuth, so perhaps others can suggest improvements here.   The 
intent is for the client to recognize that it needs to do OAuth 
authentication before attempting to query the resource to get the actual 
configuration.  I assume we could use the same OAuth token for both 
accessing the config resource and with the SMTP and IMAP servers. (Those 
could be different credentials, but I would really hope we do not ask 
users to authenticate multiple times for a single service.)

Paul

------ Original Message ------
From: "Marten Gajda" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 7/13/2016 6:32:01 PM
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via 
WebFinger

>I wanted to clarify a few points before I start to work on the draft. 
>If you have anything to add to these points or if you have any other

---

From: Eric Mill <[email-masked]>
Date: Thu, 14 Jul 2016 11:59:23 -0400

Is any of this relevant? Webfinger seems good and truly dead.

On Thu, Jul 14, 2016 at 2:19 AM, Paul E. Jones <[email-masked]>
wrote:

> While I supported the original work a few years ago, it was killed partly
> because some people stood up and said "we already have several discover
> protocols, why do we need another.  And you were presented with much the
> same on this list when people asked why the DNS mechanism is insufficient.
> You provided some good arguments, of which I think individualized
> configuration is most important.  Let's make sure the new draft is scoped
> to just mail configuration.  (If we want to go further with calendar,
> contacts, etc. then arguably those should be separate URLs.  My mail and
> calendar is not provided by the same provider, for example.)
>
> Caching: HTTP allows one to dictate that how long cached data can live. I
> don't think we need to specify it further.  A client will pull the config
> when the user configures the client.  There's no reason to cache it beyond
> that point.  In the off chance it queries a second time, it's not a big
> deal.  It might get pulled from web cache or perhaps go back to the
> server.  It really does not matter, since this should not be queried over
> and over.  Only in the event that a config change is made, the client might
> need to re-query the config data.  I'm not sure if the client should
> automate that process or prompt the user "would you like me to re-validate
> the configuration settings?" Personally, I like the latter.
>
> will authenticate the certificate. Is this just to catch the very rare case
> where somebody hacks DNS and gets a fake certificate?  That's really a
> broader Internet infrastructure issue that I think we should solve
> generically.  (For example, use of notaries, DNSSEC/DANE, etc. Personally,
> I use DNSSEC/DANE, but somewhere close to zero people make use of that
> data.)
>
> want to use enterprise-issued certificates (i.e., those that are not from a
> public CA).  If that is the case, I would not want my mail client to insert
> those into my trusted certificate store.  So, would those be one-time
> uses?  Not very useful.  I'd say the IT department needs to install
> whatever root certs are needed.  A client should authenticate the
> certificates it sees, but we don't need more words about it other than to
> say the TLS connection must be authenticated.
>
> Document structure:  I think keeping this simple is really best.  I don't
> think we need multiple mail providers. If the email address is [email-masked],
> then I think it's reasonable to assume example.com is the provider.  Yes,
> a user could go enter WebFinger information for some other provider, but
> the average person will not want to do that.  That's having the user
> configure the server so it can configure the client.  Not much gained
> there.  I would have something that's no more complex than something like
> this:
>
> {
>  "incoming" :
>  [
>    {
>      "description" : "IMAP",
>      "protocol" : "imap",
>      "servers" :
>      [
>        {
> the case of SMTP), then the user need not be bothered with selection. There
> are multiple servers, each intended to be an alternative listed in order of
> preference.
>
> through WebFinger (email config, calendar config, contacts config).  And,
> each of these documents would be discovered via a different URI.  So, in
> the JRD returned via the WebFinger query, there might be this a "rel" of
> type "email" with a URI and another of type "contacts", "calendar", etc.
>  (I did not check to see which rel values are used, but the names are not
> important.)
>
> When a user enters his or her email address, the client can discover which
> of those services are available and offer them, allowing the user to use or
> not use each one.  In my case, calendaring is not provided at my domain.
> So, I would go to my email program and say "add an account" and enter a new
> email address.  Since each set of services is individually selectable by
> the user, it's easy to mix and match email, calendaring, contacts, or
> whatever from different places.  It will require entering different account
> credentials, but I think that should be the way it works.
>
> requires it, but I seriously do not see the security concerns with a simple
> mail config file like the above.  But, if people want to secure it, they
> can.  And security should be through whatever mechanisms HTTP presents to
> the user.  I would not want to invent new ones or try to solve how to do
> something hypothetically.  My mail server requires a password and I think
> it's reasonable the HTTP server require the same.  Perhaps my calendar
> requires OAuth.  We could put the URI to the authorization server as a
> property in the WebFinger reply, like this:
>
> {
>  "rel" : "mail-config",
>    "urn:ietf:params:oauth:authserver" : "https://oauth.example.com/paulej"
>  }
> }
>
>
> necessarily understand the "client_id" parameter.  However, I'm not a guru
> in OAuth, so perhaps others can suggest improvements here.   The intent is
> for the client to recognize that it needs to do OAuth authentication before
> attempting to query the resource to get the actual configuration.  I assume
> we could use the same OAuth token for both accessing the config resource
> and with the SMTP and IMAP servers. (Those could be different credentials,
> but I would really hope we do not ask users to authenticate multiple times
> for a single service.)
>
> Paul
>
> you have anything to add to these points or if you have any other concerns,
> please let me know, so we can address them.
> Unless there is some more interest in the certificate stuff, I'm not going
> to add this to the draft. We still can add that later on if it turns out to
> be useful.
>
> Cheers,
>
> Marten
>
>
> To: "[email-masked]" <[email-masked]> <[email-masked]>
> You're welcome to contribute to the discussion, either by creating a new
> issue or by commenting on an existing one.
>
> Thanks,
>
> Marten
>
> 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.
> 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
>
> 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:)
>
> 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
>
> is to put the service configuration for all services of a provider into a
> single document.
>
> <https://example.com/service-configuration>
> }
>
> Webfinger request could return their configuration too (given there is some
> mechanism to add it and the provider actually supports that).
>
> {
> <https://example.com/service-configuration>
> },
> {
> <https://acme-calendar.com/service-configuration>
> }
>
> acme-calendar.com with your login "[email-masked]" <[email-masked]>.
> acme-calendar.com would have to issue some kind of user-identifier like
> [email-masked] for auto-configuration purposes, even though you
> don't use it for authentication (because you use [email-masked] 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
> mailto:[email-masked] <[email-masked]> and hits "next"
>
>    a) Client falls back to "manual setup" or another auto-configuration
> mechanism
>
> 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.
>
>    b) Client asks for password at "example.com" and goes back to step 2
> (this time with authentication)
>
>   -> response 200 Ok
> 3) (optional) Client presents found services to the user to let him select
> the services to set up
>
> 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:[email-masked] <[email-masked]> 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."
>
> 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.
>
>
>
>
> 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"
> 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 [email-masked] 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
> 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 [email-masked]://www.ietf.org/mailman/listinfo/webfinger
>
>
>
> --
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: +49 177 4427167
> email: [email-masked]
>
> _______________________________________________
> webfinger mailing [email-masked]://www.ietf.org/mailman/listinfo/webfinger
>
>
>
> --
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: +49 177 4427167
> email: [email-masked]
>
> _______________________________________________
> webfinger mailing [email-masked]://www.ietf.org/mailman/listinfo/webfinger
>
>
> --
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: +49 177 4427167
> email: [email-masked]
>
> _______________________________________________
> webfinger mailing [email-masked]://www.ietf.org/mailman/listinfo/webfinger
>
>
> --
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: +49 177 4427167
> email: [email-masked]
>

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 14 Jul 2016 12:51:07 -0400

Eric,

Yes, it's relevant. WebFinger isn't widely used, because there are no defined use cases for it. This is one such use case.

Paul

-------- Original Message --------
From: Eric Mill <[email-masked]>
Sent: July 14, 2016 11:59:23 AM EDT
To: "Paul E. Jones" <[email-masked]>
Cc: Marten Gajda <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via	WebFinger

On Thu, Jul 14, 2016 at 2:19 AM, Paul E. Jones <[email-masked]>
wrote:

> webfinger mailing list

------------------------------------------------------------------------

webfinger mailing list

---

From: Mikael Nordfeldth <[email-masked]>
Date: Thu, 14 Jul 2016 23:51:35 +0200

> Is any of this relevant? Webfinger seems good and truly dead.

I beg to differ. WebFinger, RFC7033, is the primary discovery method in
GNU social and we're alive and kicking.

-- 
Mikael Nordfeldth
https://blog.mmn-o.se/
XMPP/mail: [email-masked]
OpenPGP Fingerprint: AE68 9813 0B7C FCE3 B2FA  727B C7CE 635B B52E 9B31

---

From: Marten Gajda <[email-masked]>
Date: Fri, 15 Jul 2016 00:08:53 +0200

Hi Paul,

please see my comments below:

Am 14.07.2016 um 08:19 schrieb Paul E. Jones:
> Let's make sure the new draft is scoped to just mail configuration.
>  (If we want to go further with calendar, contacts, etc. then arguably
> those should be separate URLs.  My mail and calendar is not provided
> by the same provider, for example.)
If we only support mail configuration this will probably fail. I think
one of the strengths of this draft is that everything is in one place.
>
> Caching: HTTP allows one to dictate that how long cached data can
> live. I don't think we need to specify it further.  A client will pull
> the config when the user configures the client.  There's no reason to
> cache it beyond that point.  In the off chance it queries a second
> time, it's not a big deal.  It might get pulled from web cache or
> perhaps go back to the server.  It really does not matter, since this
> should not be queried over and over.  Only in the event that a config
> change is made, the client might need to re-query the config data.
>  I'm not sure if the client should automate that process or prompt the
> user "would you like me to re-validate the configuration settings?"
> Personally, I like the latter.
Sounds reasonable. I'm not sure why the current draft has this ttl
field. I'll think about that, but we probably can ditch that.
>
> Certificate pinning: Why? One fetches the mail config file.  The
> client will authenticate the certificate. Is this just to catch the
> very rare case where somebody hacks DNS and gets a fake certificate?
>  That's really a broader Internet infrastructure issue that I think we
> should solve generically.  (For example, use of notaries, DNSSEC/DANE,
> etc. Personally, I use DNSSEC/DANE, but somewhere close to zero people
> make use of that data.)
Yes, that's to prevent MITM attacks. While I believe that certificate
pinning is a good thing (if done right), I'm not sure if this document
is a good place for this. I guess there are better ways to bootstrap
certificate pinning and we probably should leave this out for now.
> from a public CA).  If that is the case, I would not want my mail
> client to insert those into my trusted certificate store.  So, would
> those be one-time uses?  Not very useful.  I'd say the IT department
> needs to install whatever root certs are needed.  A client should
> authenticate the certificates it sees, but we don't need more words
> about it other than to say the TLS connection must be authenticated.
No, this is about client authentication, i.e. the client has to provide
a client certificate signed by some specific authority. This is not
widely used and probably more for corporate or personal use cases, but
we have a significant number of users of this security feature.
At least in Java it's a real pain to distinguish a client certificate
request from any other SSLException. So it would be helpful to know in
advance if a specific client certificate is required or not.
> [email-masked], <mailto:[email-masked],%20>then I think it's
> reasonable to assume example.com is the provider.  Yes, a user could
> go enter WebFinger information for some other provider, but the
> average person will not want to do that.  That's having the user
> there.  I would have something that's no more complex than something
> like this:
>
I fully agree that we should keep it as simple as possible. However, one
of the keys to success is that we support the services and use cases
that are not covered by the existing mechanisms. That's why I believe
that the document should have a generic structure that works with pretty
much every service out there. It shouldn't be designed around email.
This is one of the reasons for me to ditch the host/port/transport
notation and just use a single URI instead. I'm not aware of any service
that can't be addresses with a URI.

Another goal should be to revert the service discovery process to some
degree. Instead of having the client to probe the provider for each
service that might be supported, the current spec reverts that and
returns a list of everything that's supported. The local "account setup
agent" then can probe the local device software for client modules or
applications that might support a specific service. Ideally this would
be supported on OS level. So you run a generic account configuration on
OS level, the OS pulls the service configuration document and calls the
installed handlers for each supported service. It there is no client for
a specific service the OS could make suggestions like "Your provider
also supports <Some service>. Search the App Store for a suitable client
app now".

That's why I believe that we should put all services into a single
document, instead of using service specific rel-types that need to be
probed by the client.

If, like in your case, calendars and email are not hosted at the same
provider, the webfinger response for your account should just contain
two provider entries, each pointing to a document that lists all the
services provided by this provider.

Cheers,

Marten

>>>> You're welcome to contribute to the discussion, either by creating
>>>> a new issue or by commenting on an existing one.
>>>>
>>>> Thanks,
>>>>
>>>> Marten
>>>>
>>>>> you need to do OAuth2. That involves Webfinger, but there is no
>>>>> need to protect this request, because it doesn't contain personal
>>>>> information.
>>>>> 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
>>>>>
>>>>>> 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
>>>>>> 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
>>>>>>
>>>>>>> is to put the service configuration for all services of a
>>>>>>> provider into a single document.
>>>>>>>
>>>>>>> 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).
>>>>>>>
>>>>>>> {
>>>>>>> acme-calendar.com would have to issue some kind of
>>>>>>> user-identifier like [email-masked] for
>>>>>>> auto-configuration purposes, even though you don't use it for
>>>>>>> authentication (because you use [email-masked] 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.
>>>>>>>
>>>>>>>>> https://exampe.com/.well-known/webfinger?... to see if there
>>>>>>>>> is a configuration document
>>>>>>>>>
>>>>>>>> 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
>>>>>>>>>    b) Client asks for password at "example.com" and goes back
>>>>>>>>> to step 2 (this time with authentication)
>>>>>>>>>
>>>>>>>>>   -> response 200 Ok
>>>>>>>>> 3) (optional) Client presents found services to the user to
>>>>>>>>> let him select the services to set up
>>>>>>>>>
>>>>>>>>> configure calendar sync with "acme-calendar.com" where his
>>>>>>>>> login happens to be mailto:[email-masked] 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).
>>>>>>>>  
>>>>>>>> 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.
>>>>>>>>  
>>>>>>>> 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.
>>>>>>>>  
>>>>>>>>  
>>>>>>>>>
>>>>>>>>> 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?
>>>>>>>>  
>>>>>>>> If we use a "config password" then we could even have the
>>>>>>>> server tell the client the password for services, which would
>>>>>>>> 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"
>>>>>>>> entirely different service that has an entirely different
>>>>>>>> access method.  Maybe the client can ask the user "is
>>>>>>>> [email-masked] 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,
>>>>>>>>> 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
>>>>>>>>  
>>>>>>>>
>>>>>>>>

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 15 Jul 2016 08:36:53 +0000

Marten,

>one of the strengths of this draft is that everything is in one place.

But, everything is in one place in the sense that WebFinger is the one 
place.  The type of information required to configure contacts and 
calendar are quite different than email.  So why produce a JSON document 
that tries to blend all three?

The only thing I'm suggesting is to define the link relations.  In the 
future, there might be another (e.g., tasks).

>advance if a specific client certificate is required or not.

Oh!  I totally had this backward.  The challenge I see with using client 
certificates is that one of the benefits to using WebFinger is that I 
don't have to manually configure my email clients I have on my 6 
different clients.  Even in the enterprise, having a mobile device and 
computer is more common.  So, I would not be opposed to this, but I'm 
not sure it would be used much, particularly since the user is already 
authenticating with other mechanisms.  If the expectation is the user's 
device will also authenticate with the mail server using the same 
certificate, I guess this might be required.

>>[email-masked], then I think it's reasonable to assume example.com 
>>is the provider.  Yes, a user could go enter WebFinger information for 
>>some other provider, but the average person will not want to do that.  
>>That's having the user configure the server so it can configure the 
>>client.  Not much gained there.  I would have something that's no more 
>>complex than something like this:
>>
>I fully agree that we should keep it as simple as possible. However, 
>one of the keys to success is that we support the services and use 
>cases that are not covered by the existing mechanisms. That's why I 
>believe that the document should have a generic structure that works 
>with pretty much every service out there. It shouldn't be designed 
>around email. This is one of the reasons for me to ditch the 
>host/port/transport notation and just use a single URI instead. I'm not 
>aware of any service that can't be addresses with a URI.

Those are just properties of the mail service.  The next thing will have 
its own set of properties.  The JRD sent by WebFinger is a document 
along the lines of what you describe: very generic.  And, that was 
viewed as good.  There is really very little one can convey: a subject, 
some properties, and a set of links with associated properties.

But, it gets really tricky trying to define something complex with a 
JRD, and that's intended.  Folks in the WG did not want it to do more 
than what it does.  And I think the same philosophy should be extended 
to the services like mail, calendar, contacts, tasks, or whatever.  If 
each one is defined for the specific purpose they serve, the documents 
will be clean and clear.

>installed handlers for each supported service. It there is no client 
>for a specific service the OS could make suggestions like "Your 
>provider also supports <Some service>. Search the App Store for a 
>suitable client app now".

That's an interesting idea, but I would still prefer to keep the config 
in different resources.  Everything you describe could be done with 
naming conventions or properties in the JRD.  For example, a link might 
have a "rel" value of "mail-config" and an "href" value.  This might not 
mean much, but there could also be a property that indicates that it is 
an "auto-configuration" link, perhaps the name of the service (e.g,  
"Email"), etc.

>document, instead of using service specific rel-types that need to be 

Another reason not to do it: even within the same organization, 
different departments might manage different services. You run into 
challenges trying to get people to coordinate.

Another reason is that folks in the IETF like to have things broken into 
granular pieces.  That's why WF is more-or-less just a directory of 
links.

>services provided by this provider.

In my case, I would expect [email-masked] to return only the 
email service, since I don't have a calendar service there.  I would 
select the "Add Account" option in my email software and enter another 
user ID to get the calendar.  Yeah, I could have this in a single WF 
reply, but the problem is that the average user isn't going to be adding 
such entries to his or her account.

Of course, we do need to allow for the possibility that the IT 
department will have one group running email and another handling 
contacts / corporate directory services.  So, a company might very well 
have two links in the JRD returned by WF.  And, that goes to my point, 
again, that there's no point trying to define an all-encompasing 
document.

To be clear, though: I'm not opposed to having a generic document that 
tries to be flexible enough to convey just about anything.  I'm OK with 
that.  I just don't think that we should have a single document that 
carries information for more than one service.  I just don't see the 
benefit in doing that vs. having two or three different link relations 
-- one for each service to be configured.  That said, I do not see that 
it's very useful to have a generic document format vs. a specialized 
one.  After all, we still have to define the exactly contents of the 
documents, generic or specialized.

Paul