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

["Paul E. Jones" <[e-mail]>]

Marten,


>So how would the UI work?
>
>1) User enters user identifier, most likely an email address, like 
>mailto:[e-mail] 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:[e-mail] 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 [e-mail] 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