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

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

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 <[e-mail]>
Sent: July 14, 2016 11:59:23 AM EDT
To: "Paul E. Jones" <[e-mail]>
Cc: Marten Gajda <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via	WebFinger

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

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

> 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 [e-mail],
> 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" <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> Sent: 7/13/2016 6:32:01 PM
> Subject: Re: [webfinger] [apps-discuss] Mail client configuration via
> WebFinger
>
> 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:
>
> 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" <[e-mail]>
> To: "[e-mail]" <[e-mail]> <[e-mail]>
> 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"
> <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"
> <https://example.com/service-configuration>
> },
> {
>     "rel " :  "service-configuration",
>     "href " : "https://acme-calendar.com/service-configuration"
> <https://acme-calendar.com/service-configuration>
> }
>
> Without that it would be more difficult to setup your account at
> acme-calendar.com with your login "[e-mail]" <[e-mail]>.
> acme-calendar.com would have to issue some kind of user-identifier like
> [e-mail] for auto-configuration purposes, even though you
> don't use it for authentication (because you use [e-mail] 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:[e-mail] <[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"
> <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] <[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
>
>
>
> _______________________________________________
> webfinger mailing [e-mail]://www.ietf.org/mailman/listinfo/webfinger
>
>
>
> --
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: [phone]
> email: [e-mail]
>
> Managing Director: Marten Gajda
> Registered address: Dresden
> Registered No.: AG Dresden HRB 34881
> VAT Reg. No.: DE303248743
>
>
>
> _______________________________________________
> webfinger mailing [e-mail]://www.ietf.org/mailman/listinfo/webfinger
>
>
>
> --
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: [phone]
> email: [e-mail]
>
> Managing Director: Marten Gajda
> Registered address: Dresden
> Registered No.: AG Dresden HRB 34881
> VAT Reg. No.: DE303248743
>
>
>
> _______________________________________________
> webfinger mailing [e-mail]://www.ietf.org/mailman/listinfo/webfinger
>
>
> --
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: [phone]
> email: [e-mail]
>
> Managing Director: Marten Gajda
> Registered address: Dresden
> Registered No.: AG Dresden HRB 34881
> VAT Reg. No.: DE303248743
>
>
>
> _______________________________________________
> webfinger mailing [e-mail]://www.ietf.org/mailman/listinfo/webfinger
>
>
> --
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: [phone]
> email: [e-mail]
>
> Managing Director: Marten Gajda
> Registered address: Dresden
> Registered No.: AG Dresden HRB 34881
> VAT Reg. No.: DE303248743
>
>
> _______________________________________________
> webfinger mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webfinger
>
>


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


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

_______________________________________________
webfinger mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/webfinger