From nobody Mon Jul 11 14:31:56 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B2812D0C3 for ; Mon, 11 Jul 2016 14:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Fhs2PrAuBjg for ; Mon, 11 Jul 2016 14:31:53 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4472312D0B7 for ; Mon, 11 Jul 2016 14:31:53 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u6BLVled030567 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Jul 2016 17:31:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1468272708; bh=5c0vPvlhliQpy9Mo8UkDKJpGCFe2kyALXNBQ+UaG2ko=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=SXnVNpWQjUXLUwUMpvbanZxnzmJrzqPnlr5JXoIgW83f+i2lYOicCHjFlnrM9Lfmg cq7CjDX8Vro2l+rZLIX3Abs29C8YxRkuPUGdeOYviFWuPfYzyCt7YO7o/F9yAMNfhy c0yxbq1/jZ+cxEJoxPwul3KrwS1D9+xldViBlmqk= From: "Paul E. Jones" To: "Marten Gajda" , "webfinger@ietf.org" Date: Mon, 11 Jul 2016 21:31:52 +0000 Message-Id: In-Reply-To: <57587369.20405@dmfs.org> References: <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org> <57587369.20405@dmfs.org> User-Agent: eM_Client/7.0.26482.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBA22A7604-4F2C-4CD5-9240-2B950ECCDE72" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Mon, 11 Jul 2016 17:31:48 -0400 (EDT) Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 21:31:56 -0000 --------=_MBA22A7604-4F2C-4CD5-9240-2B950ECCDE72 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=20 requirements for the draft you would like to see? Paul ------ Original Message ------ From: "Marten Gajda" To: "webfinger@ietf.org" Sent: 6/8/2016 3:35:05 PM Subject: Re: [webfinger] [apps-discuss] Mail client configuration via=20 WebFinger >All, > >I've created a GitHub repository to track open issues with the current=20 >draft, see https://github.com/CalConnect/AUTODISCOVERY/issues >You're welcome to contribute to the discussion, either by creating a=20 >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=20 >>need to do OAuth2. That involves Webfinger, but there is no need to=20 >>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=20 >>to grant access. Once to authorize the client to access the=20 >>configuration document and another time to authorize the client to=20 >>access the individual services. The second step is necessary, because=20 >>the scope tokens of these services are not known when the first=20 >>authorization request is presented to the user. The problem with that=20 >>is, there doesn't seem to be a mechanism to broaden scope, without=20 >>allowing the user to switch to a different account. To get access to=20 >>the individual services, the client needs to start another=20 >>authorization code grant. But the user is always free to log out and=20 >>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=20 >>>systems are trying to remove the need for passwords, it seems like=20 >>>the final solution needs to support 2FA and biometric mechanisms for=20 >>>"HTTP authentication". I definitely would not want the webfinger=20 >>>instance releasing my config data without my "authentication". I=20 >>>suppose OAuth2 could be used to protect the webfinger APIs though=20 >>>there is a bit of a chicken-and-egg here:) >>> >>>I kind of like the suggestion around returning a 401 with data in the= =20 >>>WWW-Authenticate header on where to get a token to use with the API.=20 >>>This would allow the client to start and OAuth2 flow with the=20 >>>Authorization Server specified and that would give the user a clear=20 >>>indication of what password/credentials are being requested. Once the= =20 >>>client gets the token, it uses it with the webfinger call and now the= =20 >>>service-configuration data is returned because the token is the=20 >>>authorization for the specified id. >>> >>>Thanks, >>>George >>> >>>On 6/3/16 10:44 AM, Marten Gajda wrote: >>>>Note that the idea behind=20 >>>>https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03= =20 >>>>is to put the service configuration for all services of a provider=20 >>>>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=20 >>>>Webfinger request could return their configuration too (given there=20 >>>>is some mechanism to add it and the provider actually supports=20 >>>>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=20 >>>>acme-calendar.com with your login "user@example.com".=20 >>>>acme-calendar.com would have to issue some kind of user-identifier=20 >>>>like user@acme-calendar.com for auto-configuration purposes, even=20 >>>>though you don't use it for authentication (because you use=20 >>>>user@exampe.com for authentication). I think that's the idea behind=20 >>>>the `acct:` URI scheme, but I don't think that you can explain to=20 >>>>users why they need another user identifier and when to use one or=20 >>>>the other. >>>>But that also raises the privacy concerns I mentioned earlier. If=20 >>>>the request is not authenticated, everyone could see that you have=20 >>>>an account at acme-calendar.com. >>>> >>>>Regarding SSO: There is an RFC that extends SASL based=20 >>>>authentication to support the token authentication mechanisms as=20 >>>>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= =20 >>>>>>mailto:user@example.com and hits "next" >>>>>> >>>>>>2) Client sends a Webfinger request to=20 >>>>>>https://exampe.com/.well-known/webfinger?... to see if there is a=20 >>>>>>configuration document >>>>>> >>>>>> -> response 404 Not Found >>>>>> a) Client falls back to "manual setup" or another=20 >>>>>>auto-configuration mechanism >>>>>> >>>>>> -> response 401 Unauthorized >>>>> >>>>>One should not get 401 querying the WebFinger information for the=20 >>>>>user. What should happen is that the server should return a JSON=20 >>>>>object that contains a link relation that might look like this: >>>>>{ >>>>> "rel " : "mail-config", >>>>> "href " :=20 >>>>>"https://mailserver.example.com/config?user=3Dpaulej%40packetizer.com" >>>>>} >>>>> >>>>>Or something like that. The mail client should query that URI it=20 >>>>>is that one that should result in a potential 401. The JSON format= =20 >>>>>that would come back here would need to be something we define. It= =20 >>>>>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=20 >>>>>>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=20 >>>>>>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=20 >>>>>>authenticating at example.com in step 2b? If the user tries to=20 >>>>>>configure calendar sync with "acme-calendar.com" where his login=20 >>>>>>happens to be mailto:user@example.com he might not be prepared to=20 >>>>>>being asked for his example.com password. Maybe I'm just paranoid=20 >>>>>>or overcautious, but I think that it might easily happen that the=20 >>>>>>users sends his acme-calendar.com password to example.com in that=20 >>>>>>case (since Basic authentication is still the most common=20 >>>>>>mechanism, the client basically sends the password in plain text). >>>>> >>>>>Yeah, that's a valid concern. The only thing I can suggest is that= =20 >>>>>the Subject CN from the certificate is presented to the user. =20 >>>>>Alternatively, there could be two passwords: one that is the=20 >>>>>"configuration password" and one that is the email password. =20 >>>>>However, I don't think two passwords will help us. If I want to=20 >>>>>hack somebody and can gain access to their WF config, I can=20 >>>>>auto-config their email client to point to my own IMAP server and=20 >>>>>just retrieve the password that way. >>>>> >>>>>So, I think we have to rely on the certificate presented to the=20 >>>>>mail client and the user will have to know to trust it. The mail=20 >>>>>provider can tell the user "when configuring email, ensure that the= =20 >>>>>configuration server is mailconfig.example.com and do not provide a= =20 >>>>>password if that is not the name of the configuration server=20 >>>>>indicated." >>>>> >>>>>If the mail config information is not protected with a password, we= =20 >>>>>probably would want the customer to verify that the SMTP server=20 >>>>>information is correct before the password is provided. These=20 >>>>>would be the steps users would take if performing manual=20 >>>>>configuration, but the software presents that information to the=20 >>>>>user without the user having to enter it. >>>>> >>>>> >>>>>> >>>>>>2) How does the client know which credentials to use to set up the= =20 >>>>>>individual services in step 4? Should the client ask the user for=20 >>>>>>the credentials for each service or can it assume that some of=20 >>>>>>them share the same credentials? Is that something an=20 >>>>>>auto-configuration document can help with? >>>>> >>>>>It would be nice if there is a config indicator that says "SMTP=20 >>>>>server and IMAP server passwords are the same", so the client does=20 >>>>>not have to ask. >>>>> >>>>>If we use a "config password" then we could even have the server=20 >>>>>tell the client the password for services, which would=20 >>>>>transparently allow those to be different. Alternatively, the=20 >>>>>client will have to ask each about each one. >>>>> >>>>>For calendaring services, then yes: the client would have to ask=20 >>>>>the user. It could ask if it's the same or different than the=20 >>>>>email password or the config password. For some services, the=20 >>>>>authentication mechanisms will be entirely different (like Google=20 >>>>>Calendar). The mail client will just have to know how to access=20 >>>>>the service. For that reason, I'm a little hesitant to suggest=20 >>>>>including calendaring service config along with the email config=20 >>>>>data. We could have each of those services listed in the users'=20 >>>>>WebFinger document. For example, I might have this entry in my WF=20 >>>>>document: >>>>>{ >>>>> "rel" : "calendar" >>>>> "href" : "urn:whatever:google" >>>>>} >>>>> >>>>>Note I did not provide a URL. The reason is that this is an=20 >>>>>entirely different service that has an entirely different access=20 >>>>>method. Maybe the client can ask the user "is=20 >>>>>paulej@packetizer.com our user ID for your Google calendar?" In my= =20 >>>>>case, I don't think it is. Certainly, it's not my gmail ID. And,=20 >>>>>I would not want to advertise that to the world, necessarily. =20 >>>>>Anyway, I think we should limit the scope of what we try to do to=20 >>>>>things that are standard OR we define a generic URN that a client=20 >>>>>will just have to know how to deal with. >>>>> >>>>> >>>>>>Ideally the server supports some kind of SSO mechanism like OpenID= =20 >>>>>>Connect, so you don't need to enter your password multiple times.=20 >>>>>>But a working auto-configuration is really the precondition for=20 >>>>>>this, because an OpenID Connect implementations needs a way to=20 >>>>>>discover the OAuth2 scope tokens to request from the server and=20 >>>>>>auto-configuration is really the way to do that, IMO. For this it=20 >>>>>>would be helpful to have some mechanism to request a broader scope= =20 >>>>>>from the user (without allowing him to switch to a different=20 >>>>>>account), but that's a different topic I guess. >>>>> >>>>>I definitely like the idea of SSO. But, I struggle to see how we=20 >>>>>would use this in practice with mail autoconfig since SMTP, IMAP,=20 >>>>>and POP servers require a password, anyway. If we use that as a=20 >>>>>means to have those passwords provided behind the scenes (as I=20 >>>>>indicated above), that might be a good argument for using OpenID=20 >>>>>Connect. In that way, the ISP can also ensure that passwords are=20 >>>>>REALLY complex and unknown even to the user. Not a bad practice,=20 >>>>>in that we can view those passwords as complex tokens. >>>>> >>>>>Would that kind of use of OpenID Connect to retrieve the password=20 >>>>>be workable? (I'll admit I don't have so much experience with=20 >>>>>OpenID Connect. I implemented OpenID 2.0, but that's not ideal for= =20 >>>>>what we'd want to accomplish here. I don't have a good feel for=20 >>>>>how Connect might make this better.) >>>>> >>>>>Paul >>>>> >>>>> >>>>> >>>>>_______________________________________________ webfinger mailing=20 >>>>>list=20 >>>>>webfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger >>>> >>>> >>>>-- Marten Gajda CEO dmfs GmbH Schandauer Stra=C3=9Fe 34 01309 Dresden= =20 >>>>GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing=20 >>>>Director: Marten Gajda Registered address: Dresden Registered No.:=20 >>>>AG Dresden HRB 34881 VAT Reg. No.: DE303248743 >>>> >>>>_______________________________________________ webfinger mailing=20 >>>>list=20 >>>>webfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger >>> >> >>-- Marten Gajda CEO dmfs GmbH Schandauer Stra=C3=9Fe 34 01309 Dresden=20 >>GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing=20 >>Director: Marten Gajda Registered address: Dresden Registered No.: AG=20 >>Dresden HRB 34881 VAT Reg. No.: DE303248743 >> >>_______________________________________________ webfinger mailing list= =20 >>webfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger > >-- Marten Gajda CEO dmfs GmbH Schandauer Stra=C3=9Fe 34 01309 Dresden=20 >GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing=20 >Director: Marten Gajda Registered address: Dresden Registered No.: AG=20 >Dresden HRB 34881 VAT Reg. No.: DE303248743 --------=_MBA22A7604-4F2C-4CD5-9240-2B950ECCDE72 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =20
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" <marten@dmf= s.org>
To: "webfinger@ietf.org" <web= finger@ietf.org>
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<= /a>
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:
=20 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:
=20 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:
=20
Note that the idea behind https://tools.iet= f.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-configurat= ion",
}

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-configurat= ion",
},
{
    "rel " :  "service-configur= ation",
}

Without that it would be more difficult to setup your account at acme-calendar.com with your login "user@example.com". acme-calendar.com would have to issue some kind of user-identifier like user@acme-cal= endar.com for auto-configuration purposes, even though you don't use it for authentication (because you use u= ser@exampe.com 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:
=20
Marten,
 
 
So how would the UI work?
1) User enters user identifier, most likely an email address, like mailto:user@example.com 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",
}
 
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:user@example.com 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.&nbs= p; 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 paulej@packetize= r.com our user ID for your Google calendar?"  In my = case, I don't think it is.  Certainly, it's not my gmail ID.&n= bsp; And, I would not want to advertise that to the world, necessarily.  Anyway, I think we should limit the scop= e 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
webfinger@ietf.org
https://www.ietf.org/mailman/list=
info/webfinger



--=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/list=
info/webfinger



--=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
we=
bfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------=_MBA22A7604-4F2C-4CD5-9240-2B950ECCDE72-- From nobody Wed Jul 13 15:32:20 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5C812D957 for ; Wed, 13 Jul 2016 15:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFAVa4DopL_j for ; Wed, 13 Jul 2016 15:32:16 -0700 (PDT) Received: from mailrelay2.public.one.com (mailrelay2.public.one.com [91.198.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAEA812D977 for ; Wed, 13 Jul 2016 15:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=3sNHznnj2NhVSxcXFtcpj4F0YwgLzNo2BtRbu/GygqY=; b=VyUX2m55Smewe+84CPnPmxlu8kt6xtrAS+mGeTlor+vKIz3825lyVHfQ3KaEy5YP0nlAy2A33/lGb JDhD0rW/ZyHzVvJ3ssYh9xc8qP+IFBg7HO3p5XPDUlde4h7KWvVQFkO1Wdofj6QFJ8b6ZiR87pJUjz 6Td5zZi3ET2ZK9cQ= X-HalOne-Cookie: 6265ab37e843b29b03856a092fe3830178153535 X-HalOne-ID: 9ef5255a-4949-11e6-b723-b82a72d03b9b Received: from smtp.dmfs.org (unknown [79.240.254.46]) by smtpfilter2.public.one.com (Halon Mail Gateway) with ESMTPSA for ; Wed, 13 Jul 2016 22:32:02 +0000 (UTC) Received: from localhost.localdomain (212095007177.public.telering.at [212.95.7.177]) by smtp.dmfs.org (Postfix) with ESMTPSA id D54B64F for ; Thu, 14 Jul 2016 00:32:01 +0200 (CEST) Message-ID: <5786C161.7070806@dmfs.org> Date: Thu, 14 Jul 2016 00:32:01 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org> <57587369.20405@dmfs.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080804070500080309020903" Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 22:32:19 -0000 This is a multi-part message in MIME format. --------------080804070500080309020903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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" > > To: "webfinger@ietf.org" > > 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 "user@example.com". >>>>> acme-calendar.com would have to issue some kind of user-identifier >>>>> like user@acme-calendar.com for auto-configuration purposes, even >>>>> though you don't use it for authentication (because you use >>>>> user@exampe.com 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:user@example.com 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:user@example.com 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 >>>>>> paulej@packetizer.com 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 >>>>>> webfinger@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/webfinger >>>>> >>>>> >>>>> -- >>>>> Marten Gajda >>>>> CEO >>>>> >>>>> dmfs GmbH >>>>> Schandauer Straße 34 >>>>> 01309 Dresden >>>>> GERMANY >>>>> >>>>> phone: +49 177 4427167 >>>>> email: marten@dmfs.org >>>>> >>>>> Managing Director: Marten Gajda >>>>> Registered address: Dresden >>>>> Registered No.: AG Dresden HRB 34881 >>>>> VAT Reg. No.: DE303248743 >>>>> >>>>> >>>>> _______________________________________________ >>>>> webfinger mailing list >>>>> webfinger@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/webfinger >>>> >>> >>> -- >>> Marten Gajda >>> CEO >>> >>> dmfs GmbH >>> Schandauer Straße 34 >>> 01309 Dresden >>> GERMANY >>> >>> phone: +49 177 4427167 >>> email: marten@dmfs.org >>> >>> Managing Director: Marten Gajda >>> Registered address: Dresden >>> Registered No.: AG Dresden HRB 34881 >>> VAT Reg. No.: DE303248743 >>> >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >> >> -- >> Marten Gajda >> CEO >> >> dmfs GmbH >> Schandauer Straße 34 >> 01309 Dresden >> GERMANY >> >> phone: +49 177 4427167 >> email: marten@dmfs.org >> >> Managing Director: Marten Gajda >> Registered address: Dresden >> Registered No.: AG Dresden HRB 34881 >> VAT Reg. No.: DE303248743 > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------080804070500080309020903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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" <marten@dmfs.org>
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",
}

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",
},
{
    "rel " :  "service-configuration",
}

Without that it would be more difficult to setup your account at acme-calendar.com with your login "user@example.com". acme-calendar.com would have to issue some kind of user-identifier like user@acme-calendar.com for auto-configuration purposes, even though you don't use it for authentication (because you use user@exampe.com 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:user@example.com 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",
}
 
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:user@example.com 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 paulej@packetizer.com 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
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------080804070500080309020903-- From nobody Wed Jul 13 23:19:35 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF9E12D7FF for ; Wed, 13 Jul 2016 23:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8_drJrrqnRz for ; Wed, 13 Jul 2016 23:19:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F8912D5BC for ; Wed, 13 Jul 2016 23:19:31 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u6E6JP1T001584 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Jul 2016 02:19:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1468477166; bh=pevinrryxYV0h5ffk0kGIBMihm4DKCIoE4gZyZFugPU=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=PqyTxt8q9dSgDcfRG1he6v93bilhXhRh4KjcOZgUVbxUolezeOx7rNpuCx2sdBXNw c7OYXXbW0HypMSQrkYUw3AJTU3rzzVRZdYsGPtGft6sFkKo/CI0JpuR5t5PdhdoN9T 41NaiwcH8Q+VtImJhxVJ4/yTuFko3WZrxHb7269c= From: "Paul E. Jones" To: "Marten Gajda" , "webfinger@ietf.org" Date: Thu, 14 Jul 2016 06:19:34 +0000 Message-Id: In-Reply-To: <5786C161.7070806@dmfs.org> References: <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org> <57587369.20405@dmfs.org> <5786C161.7070806@dmfs.org> User-Agent: eM_Client/7.0.26482.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB8792D5BC-CE9C-4F6F-802F-75130A039B4B" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Thu, 14 Jul 2016 02:19:26 -0400 (EDT) Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 06:19:35 -0000 --------=_MB8792D5BC-CE9C-4F6F-802F-75130A039B4B Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Marten, I'll comment on each point: General: While I supported the original work a few years ago, it was killed=20 partly because some people stood up and said "we already have several=20 discover protocols, why do we need another. And you were presented with= =20 much the same on this list when people asked why the DNS mechanism is=20 insufficient. You provided some good arguments, of which I think=20 individualized configuration is most important. Let's make sure the new= =20 draft is scoped to just mail configuration. (If we want to go further=20 with calendar, contacts, etc. then arguably those should be separate=20 URLs. My mail and calendar is not provided by the same provider, for=20 example.) Caching: HTTP allows one to dictate that how long cached data can live.=20 I don't think we need to specify it further. A client will pull the=20 config when the user configures the client. There's no reason to cache=20 it beyond that point. In the off chance it queries a second time, it's=20 not a big deal. It might get pulled from web cache or perhaps go back=20 to the server. It really does not matter, since this should not be=20 queried over and over. Only in the event that a config change is made,=20 the client might need to re-query the config data. I'm not sure if the=20 client should automate that process or prompt the user "would you like=20 me to re-validate the configuration settings?" Personally, I like the=20 latter. Certificate pinning: Why? One fetches the mail config file. The client=20 will authenticate the certificate. Is this just to catch the very rare=20 case where somebody hacks DNS and gets a fake certificate? That's=20 really a broader Internet infrastructure issue that I think we should=20 solve generically. (For example, use of notaries, DNSSEC/DANE, etc.=20 Personally, I use DNSSEC/DANE, but somewhere close to zero people make=20 use of that data.) Certificate Auth: I'm not sure what the problem is here, unless people=20 want to use enterprise-issued certificates (i.e., those that are not=20 from a public CA). If that is the case, I would not want my mail client= =20 to insert those into my trusted certificate store. So, would those be=20 one-time uses? Not very useful. I'd say the IT department needs to=20 install whatever root certs are needed. A client should authenticate=20 the certificates it sees, but we don't need more words about it other=20 than to say the TLS connection must be authenticated. Document structure: I think keeping this simple is really best. I=20 don't think we need multiple mail providers. If the email address is=20 user@example.com, then I think it's reasonable to assume example.com is=20 the provider. Yes, a user could go enter WebFinger information for some= =20 other provider, but the average person will not want to do that. That's= =20 having the user configure the server so it can configure the client. =20 Not much gained there. I would have something that's no more complex=20 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=20 descriptions to let the user choose. If there is only one choice (as in= =20 the case of SMTP), then the user need not be bothered with selection.=20 There are multiple servers, each intended to be an alternative listed in= =20 order of preference. I would define a document for each service that might be made available=20 through WebFinger (email config, calendar config, contacts config). =20 And, each of these documents would be discovered via a different URI. =20 So, in the JRD returned via the WebFinger query, there might be this a=20 "rel" of type "email" with a URI and another of type "contacts",=20 "calendar", etc. (I did not check to see which rel values are used, but= =20 the names are not important.) When a user enters his or her email address, the client can discover=20 which of those services are available and offer them, allowing the user=20 to use or not use each one. In my case, calendaring is not provided at=20 my domain. So, I would go to my email program and say "add an account"=20 and enter a new email address. Since each set of services is=20 individually selectable by the user, it's easy to mix and match email,=20 calendaring, contacts, or whatever from different places. It will=20 require entering different account credentials, but I think that should=20 be the way it works. TLS ought to be required, but it could be left to the admin. WebFinger=20 requires it, but I seriously do not see the security concerns with a=20 simple mail config file like the above. But, if people want to secure=20 it, they can. And security should be through whatever mechanisms HTTP=20 presents to the user. I would not want to invent new ones or try to=20 solve how to do something hypothetically. My mail server requires a=20 password and I think it's reasonable the HTTP server require the same. =20 Perhaps my calendar requires OAuth. We could put the URI to the=20 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" :=20 >"https://oauth.example.com/paulej" > } >} That might be insufficient for OAuth, since just having the URI to the=20 auth server isn't enough for the Auth server, I think, as it would not=20 necessarily understand the "client_id" parameter. However, I'm not a=20 guru in OAuth, so perhaps others can suggest improvements here. The=20 intent is for the client to recognize that it needs to do OAuth=20 authentication before attempting to query the resource to get the actual= =20 configuration. I assume we could use the same OAuth token for both=20 accessing the config resource and with the SMTP and IMAP servers. (Those= =20 could be different credentials, but I would really hope we do not ask=20 users to authenticate multiple times for a single service.) Paul ------ Original Message ------ From: "Marten Gajda" To: "webfinger@ietf.org" Sent: 7/13/2016 6:32:01 PM Subject: Re: [webfinger] [apps-discuss] Mail client configuration via=20 WebFinger >Hi Paul, > >the "current draft" is still the one at=20 >https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03= =20 >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.=20 >If you have anything to add to these points or if you have any other=20 >concerns, please let me know, so we can address them. >Unless there is some more interest in the certificate stuff, I'm not=20 >going to add this to the draft. We still can add that later on if it=20 >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=20 >>requirements for the draft you would like to see? >> >>Paul >> >>------ Original Message ------ >>From: "Marten Gajda" >>To: "webfinger@ietf.org" >>Sent: 6/8/2016 3:35:05 PM >>Subject: Re: [webfinger] [apps-discuss] Mail client configuration via=20 >>WebFinger >> >>>All, >>> >>>I've created a GitHub repository to track open issues with the=20 >>>current draft, see https://github.com/CalConnect/AUTODISCOVERY/issues >>>You're welcome to contribute to the discussion, either by creating a=20 >>>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=20 >>>>you need to do OAuth2. That involves Webfinger, but there is no need= =20 >>>>to protect this request, because it doesn't contain personal=20 >>>>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=20 >>>>twice to grant access. Once to authorize the client to access the=20 >>>>configuration document and another time to authorize the client to=20 >>>>access the individual services. The second step is necessary,=20 >>>>because the scope tokens of these services are not known when the=20 >>>>first authorization request is presented to the user. The problem=20 >>>>with that is, there doesn't seem to be a mechanism to broaden scope,= =20 >>>>without allowing the user to switch to a different account. To get=20 >>>>access to the individual services, the client needs to start another= =20 >>>>authorization code grant. But the user is always free to log out and= =20 >>>>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=20 >>>>>systems are trying to remove the need for passwords, it seems like=20 >>>>>the final solution needs to support 2FA and biometric mechanisms=20 >>>>>for "HTTP authentication". I definitely would not want the=20 >>>>>webfinger instance releasing my config data without my=20 >>>>>"authentication". I suppose OAuth2 could be used to protect the=20 >>>>>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=20 >>>>>the WWW-Authenticate header on where to get a token to use with the= =20 >>>>>API. This would allow the client to start and OAuth2 flow with the=20 >>>>>Authorization Server specified and that would give the user a clear= =20 >>>>>indication of what password/credentials are being requested. Once=20 >>>>>the client gets the token, it uses it with the webfinger call and=20 >>>>>now the service-configuration data is returned because the token is= =20 >>>>>the authorization for the specified id. >>>>> >>>>>Thanks, >>>>>George >>>>> >>>>>On 6/3/16 10:44 AM, Marten Gajda wrote: >>>>>>Note that the idea behind=20 >>>>>>https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-= 03=20 >>>>>>is to put the service configuration for all services of a provider= =20 >>>>>>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= =20 >>>>>>Webfinger request could return their configuration too (given=20 >>>>>>there is some mechanism to add it and the provider actually=20 >>>>>>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=20 >>>>>>acme-calendar.com with your login "user@example.com".=20 >>>>>>acme-calendar.com would have to issue some kind of user-identifier= =20 >>>>>>like user@acme-calendar.com for auto-configuration purposes, even=20 >>>>>>though you don't use it for authentication (because you use=20 >>>>>>user@exampe.com for authentication). I think that's the idea=20 >>>>>>behind the `acct:` URI scheme, but I don't think that you can=20 >>>>>>explain to users why they need another user identifier and when to= =20 >>>>>>use one or the other. >>>>>>But that also raises the privacy concerns I mentioned earlier. If=20 >>>>>>the request is not authenticated, everyone could see that you have= =20 >>>>>>an account at acme-calendar.com. >>>>>> >>>>>>Regarding SSO: There is an RFC that extends SASL based=20 >>>>>>authentication to support the token authentication mechanisms as=20 >>>>>>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,=20 >>>>>>>>like mailto:user@example.com and hits "next" >>>>>>>> >>>>>>>>2) Client sends a Webfinger request to=20 >>>>>>>>https://exampe.com/.well-known/webfinger?... to see if there is=20 >>>>>>>>a configuration document >>>>>>>> >>>>>>>> -> response 404 Not Found >>>>>>>> a) Client falls back to "manual setup" or another=20 >>>>>>>>auto-configuration mechanism >>>>>>>> >>>>>>>> -> response 401 Unauthorized >>>>>>> >>>>>>>One should not get 401 querying the WebFinger information for the= =20 >>>>>>>user. What should happen is that the server should return a JSON= =20 >>>>>>>object that contains a link relation that might look like this: >>>>>>>{ >>>>>>> "rel " : "mail-config", >>>>>>> "href " :=20 >>>>>>>"https://mailserver.example.com/config?user=3Dpaulej%40packetizer.co= m" >>>>>>>} >>>>>>> >>>>>>>Or something like that. The mail client should query that URI it= =20 >>>>>>>is that one that should result in a potential 401. The JSON=20 >>>>>>>format that would come back here would need to be something we=20 >>>>>>>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= =20 >>>>>>>>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=20 >>>>>>>>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=20 >>>>>>>>authenticating at example.com in step 2b? If the user tries to=20 >>>>>>>>configure calendar sync with "acme-calendar.com" where his login= =20 >>>>>>>>happens to be mailto:user@example.com he might not be prepared=20 >>>>>>>>to being asked for his example.com password. Maybe I'm just=20 >>>>>>>>paranoid or overcautious, but I think that it might easily=20 >>>>>>>>happen that the users sends his acme-calendar.com password to=20 >>>>>>>>example.com in that case (since Basic authentication is still=20 >>>>>>>>the most common mechanism, the client basically sends the=20 >>>>>>>>password in plain text). >>>>>>> >>>>>>>Yeah, that's a valid concern. The only thing I can suggest is=20 >>>>>>>that the Subject CN from the certificate is presented to the=20 >>>>>>>user. Alternatively, there could be two passwords: one that is=20 >>>>>>>the "configuration password" and one that is the email password. = =20 >>>>>>>However, I don't think two passwords will help us. If I want to=20 >>>>>>>hack somebody and can gain access to their WF config, I can=20 >>>>>>>auto-config their email client to point to my own IMAP server and= =20 >>>>>>>just retrieve the password that way. >>>>>>> >>>>>>>So, I think we have to rely on the certificate presented to the=20 >>>>>>>mail client and the user will have to know to trust it. The mail= =20 >>>>>>>provider can tell the user "when configuring email, ensure that=20 >>>>>>>the configuration server is mailconfig.example.com and do not=20 >>>>>>>provide a password if that is not the name of the configuration=20 >>>>>>>server indicated." >>>>>>> >>>>>>>If the mail config information is not protected with a password,=20 >>>>>>>we probably would want the customer to verify that the SMTP=20 >>>>>>>server information is correct before the password is provided. =20 >>>>>>>These would be the steps users would take if performing manual=20 >>>>>>>configuration, but the software presents that information to the=20 >>>>>>>user without the user having to enter it. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>2) How does the client know which credentials to use to set up=20 >>>>>>>>the individual services in step 4? Should the client ask the=20 >>>>>>>>user for the credentials for each service or can it assume that=20 >>>>>>>>some of them share the same credentials? Is that something an=20 >>>>>>>>auto-configuration document can help with? >>>>>>> >>>>>>>It would be nice if there is a config indicator that says "SMTP=20 >>>>>>>server and IMAP server passwords are the same", so the client=20 >>>>>>>does not have to ask. >>>>>>> >>>>>>>If we use a "config password" then we could even have the server=20 >>>>>>>tell the client the password for services, which would=20 >>>>>>>transparently allow those to be different. Alternatively, the=20 >>>>>>>client will have to ask each about each one. >>>>>>> >>>>>>>For calendaring services, then yes: the client would have to ask=20 >>>>>>>the user. It could ask if it's the same or different than the=20 >>>>>>>email password or the config password. For some services, the=20 >>>>>>>authentication mechanisms will be entirely different (like Google= =20 >>>>>>>Calendar). The mail client will just have to know how to access=20 >>>>>>>the service. For that reason, I'm a little hesitant to suggest=20 >>>>>>>including calendaring service config along with the email config=20 >>>>>>>data. We could have each of those services listed in the users'=20 >>>>>>>WebFinger document. For example, I might have this entry in my=20 >>>>>>>WF document: >>>>>>>{ >>>>>>> "rel" : "calendar" >>>>>>> "href" : "urn:whatever:google" >>>>>>>} >>>>>>> >>>>>>>Note I did not provide a URL. The reason is that this is an=20 >>>>>>>entirely different service that has an entirely different access=20 >>>>>>>method. Maybe the client can ask the user "is=20 >>>>>>>paulej@packetizer.com our user ID for your Google calendar?" In=20 >>>>>>>my case, I don't think it is. Certainly, it's not my gmail ID. =20 >>>>>>>And, I would not want to advertise that to the world,=20 >>>>>>>necessarily. Anyway, I think we should limit the scope of what=20 >>>>>>>we try to do to things that are standard OR we define a generic=20 >>>>>>>URN that a client will just have to know how to deal with. >>>>>>> >>>>>>> >>>>>>>>Ideally the server supports some kind of SSO mechanism like=20 >>>>>>>>OpenID Connect, so you don't need to enter your password=20 >>>>>>>>multiple times. But a working auto-configuration is really the=20 >>>>>>>>precondition for this, because an OpenID Connect implementations= =20 >>>>>>>>needs a way to discover the OAuth2 scope tokens to request from=20 >>>>>>>>the server and auto-configuration is really the way to do that,=20 >>>>>>>>IMO. For this it would be helpful to have some mechanism to=20 >>>>>>>>request a broader scope from the user (without allowing him to=20 >>>>>>>>switch to a different account), but that's a different topic I=20 >>>>>>>>guess. >>>>>>> >>>>>>>I definitely like the idea of SSO. But, I struggle to see how we= =20 >>>>>>>would use this in practice with mail autoconfig since SMTP, IMAP,= =20 >>>>>>>and POP servers require a password, anyway. If we use that as a=20 >>>>>>>means to have those passwords provided behind the scenes (as I=20 >>>>>>>indicated above), that might be a good argument for using OpenID=20 >>>>>>>Connect. In that way, the ISP can also ensure that passwords are= =20 >>>>>>>REALLY complex and unknown even to the user. Not a bad practice,= =20 >>>>>>>in that we can view those passwords as complex tokens. >>>>>>> >>>>>>>Would that kind of use of OpenID Connect to retrieve the password= =20 >>>>>>>be workable? (I'll admit I don't have so much experience with=20 >>>>>>>OpenID Connect. I implemented OpenID 2.0, but that's not ideal=20 >>>>>>>for what we'd want to accomplish here. I don't have a good feel=20 >>>>>>>for how Connect might make this better.) >>>>>>> >>>>>>>Paul >>>>>>> >>>>>>> >>>>>>> >>>>>>>_______________________________________________ webfinger mailing= =20 >>>>>>>list=20 >>>>>>>webfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger >>>>>> >>>>>> >>>>>>-- Marten Gajda CEO dmfs GmbH Schandauer Stra=C3=9Fe 34 01309 Dresden= =20 >>>>>>GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing=20 >>>>>>Director: Marten Gajda Registered address: Dresden Registered No.:= =20 >>>>>>AG Dresden HRB 34881 VAT Reg. No.: DE303248743 >>>>>> >>>>>>_______________________________________________ webfinger mailing=20 >>>>>>list=20 >>>>>>webfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger >>>>> >>>> >>>>-- Marten Gajda CEO dmfs GmbH Schandauer Stra=C3=9Fe 34 01309 Dresden= =20 >>>>GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing=20 >>>>Director: Marten Gajda Registered address: Dresden Registered No.:=20 >>>>AG Dresden HRB 34881 VAT Reg. No.: DE303248743 >>>> >>>>_______________________________________________ webfinger mailing=20 >>>>list=20 >>>>webfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger >>> >>>-- Marten Gajda CEO dmfs GmbH Schandauer Stra=C3=9Fe 34 01309 Dresden= =20 >>>GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing=20 >>>Director: Marten Gajda Registered address: Dresden Registered No.: AG= =20 >>>Dresden HRB 34881 VAT Reg. No.: DE303248743 >> >> >>_______________________________________________ webfinger mailing list= =20 >>webfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger > >-- Marten Gajda CEO dmfs GmbH Schandauer Stra=C3=9Fe 34 01309 Dresden=20 >GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing=20 >Director: Marten Gajda Registered address: Dresden Registered No.: AG=20 >Dresden HRB 34881 VAT Reg. No.: DE303248743 --------=_MB8792D5BC-CE9C-4F6F-802F-75130A039B4B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =20
Marten,

I'll comment= on each point:

General:
While I support= ed 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.  Yo= u provided some good arguments, of which I think individualized configurati= on is most important.  Let's make sure the new draft is scoped to just= mail configuration.  (If we want to go further with calendar, contact= s, etc. then arguably those should be separate URLs.  My mail and cale= ndar 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 reaso= n to cache it beyond that point.  In the off chance it queries a secon= d 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 certi= ficate. Is this just to catch the very rare case where somebody hacks DNS= and gets a fake certificate?  That's really a broader Internet infras= tructure 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.
<= br>
Document structure:  I think keeping this simple is real= ly best.  I don't think we need multiple mail providers. If the email= address is user@example.com, the= n 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" :
 [<= /font>
   {
     "description" : "IMA= P",
     "protocol" : "imap",
   =  "servers" :
     [
   =    {
         "host" : "imap-01= .example.com",
         "port" : 143,
         "transport" : "starttls"
=
&nbs= p;      },
       {
=          "host" : "imap-02.example.com",
=          "port" : 143,
   =      "transport" : "starttls"
     = ;  }
     ]
   },=
   {
     "description" : "POP",
     "protocol" : "pop3",
     = ;"servers" :
     [
     = ;  {
         "host" : "imap-01.exa= mple.com",
         "port" : 110,<= /div>
=          "transport" : "starttls"
 =      },
       {
=          "host" : "imap-02.example.com",
=          "port" : 110,
   =      "transport" : "starttls"
     = ;  }
     ]
   }<= /div>
=  ],
 "outgoing" :
 [
   = ;{
     "description" : "SMTP",
   = ;  "protocol" : "smtp",
     "servers" :
     [
       {=
         "host" : "smtp-01.example.com",<= /div>
=          "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,
<= font face=3D"Courier New" size=3D"2" style=3D"font-size: 10pt;">   =        "transport" : "tls"
     = ;  }
     ]
   }<= /div>
=  ]
}

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, calen= dar config, contacts config).  And, each of these documents would be= discovered via a different URI.  So, in the JRD returned via the WebF= inger 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 matc= h email, calendaring, contacts, or whatever from different places.  It= will require entering different account credentials, but I think that shou= ld be the way it works.

TLS ought to be required,= but it could be left to the admin.  WebFinger requires it, but I seri= ously 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 someth= ing hypothetically.  My mail server requires a password and I think= it's reasonable the HTTP server require the same.  Perhaps my calenda= r 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:p= arams:oauth:authserver" : "htt= ps://oauth.example.com/paulej"
 }
}

That might be insuffi= cient 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" <marten@dmf= s.org>
To: "webfinger@ietf.org" <web= finger@ietf.org>
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" <marten@dmfs.org>
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 h= ttps://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-conf= iguration",
}

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-conf= iguration",
},
{
    "rel " :  "service-co= nfiguration",
}

Without that it would be more difficult to setup your account at acme-calendar.com with your login "user@example.com". acme-calendar.com would have to issue some kind of user-identifier like user@a= cme-calendar.com for auto-configuration purposes, even though you don't use it for authentication (because you use user@exampe.com 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:use= r@example.com 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-confi= g",
}
 
Or something like that.  The mail client shou= ld 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 "exampl= e.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:user@example.com 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 clien= t 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 clie= nt will just have to know how to access the service.&nbs= p; 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"<= /div>
}
 
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 paulej@packetizer.com 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
webfinger@ietf.org
https://www.ietf.org/mailman/list=
info/webfinger



--=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


____________________________________________=
___
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/list=
info/webfinger



--=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/list=
info/webfinger


--=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
we=
bfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------=_MB8792D5BC-CE9C-4F6F-802F-75130A039B4B-- From nobody Thu Jul 14 09:00:21 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0794312D808 for ; Thu, 14 Jul 2016 09:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19Q81eJfd3u5 for ; Thu, 14 Jul 2016 09:00:12 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9602F12D795 for ; Thu, 14 Jul 2016 09:00:12 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 0A1032A0EA for ; Thu, 14 Jul 2016 12:00:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=nIhNxjY4mQ/dWeZn7P/+tsi1edI=; b=IsU2zr 4X034QsIw25P9L4Rv04jtAODJQ8a2PCnDVLN3cSrYiBCrBtCW+Hkd6t7DJlKYoRf rSqC3WDf2izXYCeNy52KkYZEBjKtOAPjYJY7YOUiZs5qfEFkkaGxFGXJ0nkau3Ut xIqlSBKmFDMCZjI6p5qFHpI12pkeeQp0fDEZ4= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 002212A0E9 for ; Thu, 14 Jul 2016 12:00:05 -0400 (EDT) Received: from mail-qt0-f172.google.com (unknown [209.85.216.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 2C5C22A0E3 for ; Thu, 14 Jul 2016 12:00:05 -0400 (EDT) Received: by mail-qt0-f172.google.com with SMTP id w38so44804378qtb.0 for ; Thu, 14 Jul 2016 09:00:05 -0700 (PDT) X-Gm-Message-State: ALyK8tKS/oUW8H3d89TAv8118Rd4auX4wJXbk6UDNeLowUK3y4C+oSEOAQu7JoSS/DLspV7XOqSa1R29yjNSeQ== X-Received: by 10.200.42.161 with SMTP id b30mr21564713qta.94.1468512003419; Thu, 14 Jul 2016 09:00:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.39.187 with HTTP; Thu, 14 Jul 2016 08:59:23 -0700 (PDT) In-Reply-To: References: <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org> <57587369.20405@dmfs.org> <5786C161.7070806@dmfs.org> From: Eric Mill Date: Thu, 14 Jul 2016 11:59:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a114084684ffd9905379a98d3 X-Pobox-Relay-ID: 07AF2FB6-49DC-11E6-B018-EE617A1B28F4-82875391!pb-smtp2.pobox.com Archived-At: Cc: Marten Gajda , "webfinger@ietf.org" Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 16:00:19 -0000 --001a114084684ffd9905379a98d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is any of this relevant? Webfinger seems good and truly dead. On Thu, Jul 14, 2016 at 2:19 AM, Paul E. Jones 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 beyon= d > 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 mig= ht > 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-validat= e > 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 ca= se > 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 inse= rt > 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 user@examp= le.com, > 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. The= re > 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 whic= h > 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 n= ew > 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 accou= nt > 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 simp= le > 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 gur= u > in OAuth, so perhaps others can suggest improvements here. The intent i= s > for the client to recognize that it needs to do OAuth authentication befo= re > attempting to query the resource to get the actual configuration. I assu= me > 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 time= s > for a single service.) > > Paul > > ------ Original Message ------ > From: "Marten Gajda" > To: "webfinger@ietf.org" > 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 concern= s, > please let me know, so we can address them. > Unless there is some more interest in the certificate stuff, I'm not goin= g > 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" > To: "webfinger@ietf.org" > 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 nee= d > to do OAuth2. That involves Webfinger, but there is no need to protect th= is > 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 individua= l > 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 anoth= er > 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 so= me > 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 "user@example.com" . > acme-calendar.com would have to issue some kind of user-identifier like > user@acme-calendar.com for auto-configuration purposes, even though you > don't use it for authentication (because you use user@exampe.com for > authentication). I think that's the idea behind the `acct:` URI scheme, b= ut > 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:user@example.com 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=3Dpaulej%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 co= me > 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 selec= t > 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:user@example.com 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 send= s > 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" an= d > one that is the email password. However, I don't think two passwords wil= l > 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 serv= er > 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 serv= er > 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 informati= on > is correct before the password is provided. These would be the steps use= rs > 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 he= lp > with? > > > It would be nice if there is a config indicator that says "SMTP server an= d > 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 t= o > 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 litt= le > 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 th= e > client can ask the user "is paulej@packetizer.com 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 a= n > OpenID Connect implementations needs a way to discover the OAuth2 scope > tokens to request from the server and auto-configuration is really the wa= y > 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 serve= rs > 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 b= e > 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. N= ot > 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 wa= nt > to accomplish here. I don't have a good feel for how Connect might make > this better.) > > Paul > > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/list= info/webfinger > > > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Stra=C3=9Fe 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email: marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/list= info/webfinger > > > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Stra=C3=9Fe 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email: marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/list= info/webfinger > > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Stra=C3=9Fe 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email: marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/list= info/webfinger > > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Stra=C3=9Fe 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email: marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --=20 konklone.com | @konklone --001a114084684ffd9905379a98d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is any of this relevant? Webfinger seems good and truly de= ad.

On Thu, = Jul 14, 2016 at 2:19 AM, Paul E. Jones <paulej@packetizer.com><= /span> wrote:
=20 =20
Marten,

I'll comment on each point= :

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

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

Certificate pinning: Why? On= e fetches the mail config file.=C2=A0 The client will authenticate the cert= ificate. Is this just to catch the very rare case where somebody hacks DNS = and gets a fake certificate?=C2=A0 That's really a broader Internet inf= rastructure issue that I think we should solve generically. =C2=A0(For exam= ple, 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 pe= ople want to use enterprise-issued certificates (i.e., those that are not f= rom a public CA).=C2=A0 If that is the case, I would not want my mail clien= t to insert those into my trusted certificate store.=C2=A0 So, would those = be one-time uses?=C2=A0 Not very useful.=C2=A0 I'd say the IT departmen= t needs to install whatever root certs are needed.=C2=A0 A client should au= thenticate the certificates it sees, but we don't need more words about= it other than to say the TLS connection must be authenticated.
<= br>
Document structure: =C2=A0I think keeping this simple is real= ly best.=C2=A0 I don't think we need multiple mail providers. If the em= ail address is user@= example.com, then I think it's reasonable to assume example.com is the provider.=C2=A0 Ye= s, a user could go enter WebFinger information for some other provider, but= the average person will not want to do that.=C2=A0 That's having the u= ser configure the server so it can configure the client.=C2=A0 Not much gai= ned there.=C2=A0 I would have something that's no more complex than som= ething like this:

{
=C2=A0"incoming" :
<= font face=3D"Courier New" size=3D"2" style=3D"font-size:10pt"> =C2=A0[
=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0"description" : "= IMAP",
=C2=A0 =C2=A0 =C2=A0"protocol" : "imap&quo= t;,
=C2=A0 =C2=A0 =C2=A0"servers" :
=C2=A0 =C2=A0 =C2= =A0[
=C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"host" : "imap-01.example.com",
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0"port" : 143,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&= quot;transport" : "starttls"
=C2=A0 =C2=A0 =C2=A0 =C2= =A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"host" : "imap-02.example.com",
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0"port" : 143,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&= quot;transport" : "starttls"
=C2=A0 =C2=A0 =C2=A0 =C2= =A0}
=C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0},
=C2=A0 =C2=A0{=
=C2=A0 =C2=A0 =C2=A0"description" : "POP",
= =C2=A0 =C2=A0 =C2=A0"protocol" : "pop3",
<= div> =C2=A0 = =C2=A0 =C2=A0"servers" :
=C2=A0 =C2=A0 =C2=A0[
=
=C2=A0= =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"host&q= uot; : "imap-= 01.example.com",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"po= rt" : 110,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"transport&quo= t; : "starttls"
=C2=A0 =C2=A0 =C2=A0 =C2=A0},
=
=C2=A0= =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"host&q= uot; : "imap-= 02.example.com",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"po= rt" : 110,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"transport&quo= t; : "starttls"
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
<= div> =C2=A0 = =C2=A0 =C2=A0]
=C2=A0 =C2=A0}
=C2=A0],
=C2=A0"outgoi= ng" :
=C2=A0[
=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0&= quot;description" : "SMTP",
=C2=A0 =C2=A0 =C2=A0"= protocol" : "smtp",
=C2=A0 =C2=A0 =C2=A0"servers&= quot; :
=C2=A0 =C2=A0 =C2=A0[
=C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"host" : "smtp-01.example.com",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"port" : 587,
=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0"transport" : "starttls"
=C2=A0 =C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0{=
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"host" : "smtp-02.example.com",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"port" : 587,
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0"transport" : "starttls"
=C2=A0 =C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0{<= /div>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"host" : "smtp-01.example.com",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"port" : 465,
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0"transport" : "tls"
= =C2=A0 =C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"host" : "smtp-02.example.com",=
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"port" : 465,
= =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0"transport" : "tls"
=C2= =A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0}=
=C2=A0]
}

I use a = arrays to offer different protocols (POP3 and IMAP) with descriptions to le= t the user choose.=C2=A0 If there is only one choice (as in the case of SMT= P), then the user need not be bothered with selection. There are multiple s= ervers, each intended to be an alternative listed in order of preference.

I would define a document for each service that mig= ht be made available through WebFinger (email config, calendar config, cont= acts config).=C2=A0 And, each of these documents would be discovered via a = different URI.=C2=A0 So, in the JRD returned via the WebFinger query, there= might be this a "rel" of type "email" with a URI and a= nother of type "contacts", "calendar", etc. =C2=A0(I di= d not check to see which rel values are used, but the names are not importa= nt.)

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

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

{
=C2=A0"rel" : "mail-config",<= /div>
=C2=A0"properties" : {
=
=C2=A0 =C2=A0"urn:ietf:par= ams:oauth:authserver" : "https://oauth.example.com/paulej"
=C2=A0}
}

That might be insufficient for OAuth, since just having the URI to t= he auth server isn't enough for the Auth server, I think, as it would n= ot necessarily understand the "client_id" parameter.=C2=A0 Howeve= r, I'm not a guru in OAuth, so perhaps others can suggest improvements = here. =C2=A0 The intent is for the client to recognize that it needs to do = OAuth authentication before attempting to query the resource to get the act= ual configuration.=C2=A0 I assume we could use the same OAuth token for bot= h 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" <marten@dmfs.org>
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-aggr= egated-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 no= t 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:
=20
Marten,

Sorry to just be coming back to this after a whole month passed.

What current draft?=C2=A0 Did you write one that I missed?=C2=A0= Or are these requirements for the draft you would like to see?

Paul

------ Original Message ------
From: "Marten Gajda" <marten@dmfs.org>
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 th= e current draft, see https://github.com/CalConnect/AUTODISCOV= ERY/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 h= ttps://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:

{
=C2=A0=C2=A0=C2=A0 "rel "=C2=A0: =C2=A0&qu= ot;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).

{
=C2=A0=C2=A0=C2=A0 "rel "=C2=A0: =C2=A0&qu= ot;service-configuration",
},
{
=C2=A0=C2=A0=C2=A0 "rel "=C2=A0: =C2=A0&= quot;service-configuration",
}

Without that it would be more difficult to setup your account at acme-calendar.com with your login "user@example.com". = acme-calendar.com would have to issue some kind of user-identifier like user@acme-calendar.com for auto-configuration purposes, even though you don't use it for authentication (because you use user@exampe.com 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:
=20
Marten,
=C2=A0
=C2=A0
So how would the UI work?

1) User enters user identifier, most likely an email address, like mailto:user@example.com and hits "next"

2) Client sends a Webfinger request to https://exampe.c= om/.well-known/webfinger?... to see if there is a configuration document

=C2=A0 -> response 404 Not Found
=C2=A0=C2=A0 a) Client falls back to "manual s= etup" or another auto-configuration mechanism

=C2=A0 -> response 401 Unauthorized
=C2=A0
One should not get 401 querying the WebFinger information for the user.=C2=A0 What should happen is that the server should return a JSON object that contains a link relation that might look like this:
{
=C2=A0=C2=A0=C2=A0 "rel "=C2=A0: =C2=A0&= quot;mail-config",
}
=C2=A0
Or something like that.=C2=A0 The mail client shou= ld query that URI it is that one that should result in a potential 401.=C2=A0 The JSON format that would come back here would need to be something we define.=C2=A0 It could be based on JRD, but would not have to be.
=C2=A0
Otherwise, I think the flow looks right.
=C2=A0
=C2=A0

=C2=A0=C2=A0 b) Client asks for password at "<= a href=3D"http://example.com" target=3D"_blank">example.com" and goes back to step 2 (this time with authentication)

=C2=A0 -> response 200 Ok
=C2=A0=C2=A0 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:user@example.com he might not be prepared to being asked for his ex= ample.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).
=C2=A0
Yeah, that's a valid concern.=C2=A0 The only t= hing I can suggest is that the Subject CN from the certificate is presented to the user.=C2=A0 Alternatively, there could be two passwords: one that is the "configuration password" and on= e that is the email password.=C2=A0 However, I don't thi= nk two passwords will help us.=C2=A0 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.
=C2=A0
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.=C2=A0 The mail provider can tell the user "when configuring email, ensure th= at the configuration server is mailconfig.example.com and do not provide a password if that is not the name of the configuration server indicated."
=C2=A0
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.=C2=A0 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.
=C2=A0
=C2=A0

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?
=C2=A0
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 as= k.
=C2=A0
If we use a "config password" then we co= uld even have the server tell the client the password for services, which would transparently allow those to be different.=C2=A0 Alternatively, the clien= t will have to ask each about each one.
=C2=A0
For calendaring services, then yes: the client would have to ask the user.=C2=A0 It could ask if it&= #39;s the same or different than the email password or the config password.=C2=A0 For some services, the authentication mechanisms will be entirely different (like Google Calendar).=C2=A0 The mail clie= nt will just have to know how to access the service.=C2= =A0 For that reason, I'm a little hesitant to suggest including calendaring service config along with the email config data.=C2=A0 We could have each of those services listed in the users' WebFinger document.=C2=A0 For example, I might have this entry = in my WF document:
{
=C2=A0=C2=A0=C2=A0 "rel" : "calenda= r"
=C2=A0=C2=A0=C2=A0 "href" : "urn:wh= atever:google"
}
=C2=A0
Note I did not provide a URL.=C2=A0 The reason is that this is an entirely different service that has an entirely different access method.=C2=A0 Maybe the client can ask the user "is paulej@packetizer.com our user ID for=C2=A0your Google calendar?"=C2= =A0 In my case, I don't think it is.=C2=A0 Certainly, it= 9;s not my gmail ID.=C2=A0 And, I would not want to advertise th= at to the world, necessarily.=C2=A0 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.
=C2=A0
=C2=A0
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 topi= c I guess.
=C2=A0
I definitely like the idea of SSO.=C2=A0 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.=C2=A0 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.=C2=A0 In that way, the ISP can also ensure that passwords are REALLY complex and unknown even to the user.=C2=A0 Not a bad practice, in that we can view those passwords as complex tokens.
=C2=A0
Would that kind of use of OpenID Connect to retrieve the password be workable?=C2=A0 (I'll ad= mit I don't have so much experience with OpenID Connect.=C2=A0 I implemented OpenID 2.0, but that'= ;s not ideal for what we'd want to accomplish here.=C2= =A0 I don't have a good feel for how Connect might make this better.)
=C2=A0
Paul
=C2=A0


_______________________________________________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger



--=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org=


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


_______________________________________________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger



--=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org=


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


_______________________________________________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger


--=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org=


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


_______________________________________________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger


--=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org=


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

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



--
--001a114084684ffd9905379a98d3-- From nobody Thu Jul 14 09:51:20 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274AC12B040 for ; Thu, 14 Jul 2016 09:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo1dA1T2ALIZ for ; Thu, 14 Jul 2016 09:51:14 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655EF12B04D for ; Thu, 14 Jul 2016 09:51:14 -0700 (PDT) Received: from [IPv6:2607:fb90:525c:d16c:0:44:eb14:d501] ([172.58.158.152]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u6EGp8Y4009985 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2016 12:51:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1468515070; bh=uyz0iYCHGqHeSX/9GnnfwcOQXKOzMvRuEcFS/0zKU8M=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=m5OBUJYTehZLHlrVNw7pYADkoI7gjtV2KyvplhDyToe5zxxvcJFzy06A4FtoDV/QN PBkMdvQy0ejJ2xCDaF+RqFXJAX0iJULj3+Hy5FeFoOY7Y+hYhnHZ8H5GViY4Eh6jbU tnA7Kswt72nux/Jl20eydIaAy9SLV3Fg4CfNfQHM= User-Agent: K-9 Mail for Android In-Reply-To: References: <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org> <57587369.20405@dmfs.org> <5786C161.7070806@dmfs.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----4I82A019RMWI0J0NP25MATPBHCT36T" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Thu, 14 Jul 2016 12:51:07 -0400 To: Eric Mill Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Thu, 14 Jul 2016 12:51:10 -0400 (EDT) Archived-At: Cc: Marten Gajda , "webfinger@ietf.org" Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 16:51:18 -0000 ------4I82A019RMWI0J0NP25MATPBHCT36T Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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 Sent: July 14, 2016 11:59:23 AM EDT To: "Paul E. Jones" Cc: Marten Gajda , "webfinger@ietf.org" 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 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 user@example.com, > 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" > To: "webfinger@ietf.org" > 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" > To: "webfinger@ietf.org" > 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 "user@example.com" . > acme-calendar.com would have to issue some kind of user-identifier like > user@acme-calendar.com for auto-configuration purposes, even though you > don't use it for authentication (because you use user@exampe.com 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:user@example.com 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:user@example.com 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 paulej@packetizer.com 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 listwebfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger > > > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Straße 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email: marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger > > > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Straße 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email: marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger > > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Straße 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email: marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger > > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Straße 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email: marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > -- konklone.com | @konklone ------------------------------------------------------------------------ _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------4I82A019RMWI0J0NP25MATPBHCT36T Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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

From: Eric Mill <eric@konklone.com>
Sent: July 14, 2016 11:59:23 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: Marten Gajda <marten@dmfs.org>, "webfinger@ietf.org" <webfinger@ietf.org>
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 <paulej@packetizer.com> 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 cl! ient.  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 clo! se 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 user@example.com, 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" : &quo! t;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" :
 [
   {
     "descriptio! n" : "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 mechanis! ms 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",
 "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" <marten@dmfs.org>
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" <marten@dmfs.org>
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",
}

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",
},
{
    "rel " :  "service-configuration",
}

Without that it would be more difficult to setup your account at acme-calendar.com with your login "user@example.com". acme-calendar.com would have to issue some kind of user-identifier like user@acme-calendar.com for auto-configuration purposes, even though you don't use it for authentication (because you use user@exampe.com 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:user@example.com 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",
}
 
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:user@example.com 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 paulej@packetizer.com 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
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger




-- 


webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger
------4I82A019RMWI0J0NP25MATPBHCT36T-- From nobody Thu Jul 14 14:52:48 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32A812D8B4 for ; Thu, 14 Jul 2016 14:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJ_eCytf7Vs5 for ; Thu, 14 Jul 2016 14:52:44 -0700 (PDT) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE00E12D8A9 for ; Thu, 14 Jul 2016 14:52:43 -0700 (PDT) To: Eric Mill References: <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org> <57587369.20405@dmfs.org> <5786C161.7070806@dmfs.org> From: Mikael Nordfeldth Message-ID: Date: Thu, 14 Jul 2016 23:51:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j6lN7X15Pab1qorFOtot3nBfgHpXUJXuW" Archived-At: Cc: "webfinger@ietf.org" Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 21:52:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j6lN7X15Pab1qorFOtot3nBfgHpXUJXuW Content-Type: multipart/mixed; boundary="ASGXbVnKHWMeqQVrE3iDUO2SQiMhpbSqX" From: Mikael Nordfeldth To: Eric Mill Cc: "webfinger@ietf.org" Message-ID: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger References: <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org> <57587369.20405@dmfs.org> <5786C161.7070806@dmfs.org> In-Reply-To: --ASGXbVnKHWMeqQVrE3iDUO2SQiMhpbSqX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-07-14 17:59, Eric Mill wrote: > 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. --=20 Mikael Nordfeldth https://blog.mmn-o.se/ XMPP/mail: mmn@hethane.se OpenPGP Fingerprint: AE68 9813 0B7C FCE3 B2FA 727B C7CE 635B B52E 9B31 --ASGXbVnKHWMeqQVrE3iDUO2SQiMhpbSqX-- --j6lN7X15Pab1qorFOtot3nBfgHpXUJXuW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXiAloAAoJEOlbeo6AYkMcU6wQAMK0N5/Q4JVyMPfkGYi2hjqT MU7gIR/O912eVTWU+uJD5aASgd6AeDtP0Hxx7z0inkNk06k0+BzEl47DXO6M7lEP WcY9AJA1FDP/pvdUq/PyfIrrkZme5uSJNvtClFS1W4Mxg+1rRvxNPMDfmMB1S+Hq nYacYEfiAn4AgI//eTqudsR+mqXGf2ngOntcSXhnZf2/zGfoHU+f6EZltvO+JDnd PwhrJhsHdWnsCO0RifRVHBXou3DJfuuhQJ7WWhTIdmxRrPMriuxjUyp//Sh6hGl9 6udl/MTaXeS96u4QX5rEhmMwXUn4fl7tYFab82DYPUse7mAE04LzOJs2tXLnK2P9 0D6LVjisY8yZCgrJP58BmS5fAS2Hk6H7gm8lL862iVTJZVp90F/+kzbYyr7psriL mHGv2ihYyDAlEmsIhsgGpPyhYsIpLjhN9Km5CtaCCbGxfMeRgPtX8a03b0B5lnWv Lbiy+vcAF9Iw2hjZpF7iec5Ss/P0uiLebeN80Vjf2i85sFEDW9R0fJWR5zSWYgiW ZECvP09tjdRYX7yMouU0UnC2OAmBulvaOHtzjndSyM1bDPxlB7VYOTPoIIiMDflp OSAQ21FItSwud3HrLa03B3r0JtOIAeSowOYBj9dq92GoBKhXX8ox62V8IeTnWVy4 ELWlsmoUCCbvQrqpbQTx =R0lQ -----END PGP SIGNATURE----- --j6lN7X15Pab1qorFOtot3nBfgHpXUJXuW-- From nobody Thu Jul 14 15:09:06 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8252312D67E for ; Thu, 14 Jul 2016 15:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=0.77] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVFQxySw1yDD for ; Thu, 14 Jul 2016 15:09:02 -0700 (PDT) Received: from mailrelay6.public.one.com (mailrelay6.public.one.com [91.198.169.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAF212D663 for ; Thu, 14 Jul 2016 15:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=Cf6fKxpHj2iNxtrPMFV/jsbSJVw7q4S97jQA78oIkDI=; b=nDvg2uBNyPbI9ZE1Q0eysK0oDOg3QObtd5a6Bf3imnoP3Q7fjwVXSiaesPS00PA7tgv1C5MeYNzOA n1bK4WtDbh7CIH3l+90CqFJNO1Go5kMQKvwuG96pwX+mKDmR1qLCOVEGwR+fLn+NOVXSzrcZYCBca4 LbcKhvz6z8D1CflY= X-HalOne-Cookie: 3b9d49238db273a36ab8a0f9a0879f255b0f2dcb X-HalOne-ID: 8e711e2b-4a0f-11e6-9f37-b82a72d06996 Received: from smtp.dmfs.org (unknown [79.240.231.119]) by smtpfilter3.public.one.com (Halon Mail Gateway) with ESMTPSA; Thu, 14 Jul 2016 22:08:55 +0000 (UTC) Received: from localhost.localdomain (213162068184.public.t-mobile.at [213.162.68.184]) by smtp.dmfs.org (Postfix) with ESMTPSA id 500B06A; Fri, 15 Jul 2016 00:08:54 +0200 (CEST) Message-ID: <57880D75.5090109@dmfs.org> Date: Fri, 15 Jul 2016 00:08:53 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul E. Jones , webfinger@ietf.org References: <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org> <57587369.20405@dmfs.org> <5786C161.7070806@dmfs.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000509010708080409060603" Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 22:09:05 -0000 This is a multi-part message in MIME format. --------------000509010708080409060603 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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. > > 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. 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. > > Document structure: I think keeping this simple is really best. I > don't think we need multiple mail providers. If the email address is > user@example.com, 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. 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 . 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 > > Paul > > ------ Original Message ------ > From: "Marten Gajda" > > To: "webfinger@ietf.org" > > 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" > >>> To: "webfinger@ietf.org" >> > >>> 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 "user@example.com". >>>>>>> acme-calendar.com would have to issue some kind of >>>>>>> user-identifier like user@acme-calendar.com for >>>>>>> auto-configuration purposes, even though you don't use it for >>>>>>> authentication (because you use user@exampe.com 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:user@example.com 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:user@example.com 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 >>>>>>>> paulej@packetizer.com 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 >>>>>>>> webfinger@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/webfinger >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Marten Gajda >>>>>>> CEO >>>>>>> >>>>>>> dmfs GmbH >>>>>>> Schandauer Straße 34 >>>>>>> 01309 Dresden >>>>>>> GERMANY >>>>>>> >>>>>>> phone: +49 177 4427167 >>>>>>> email: marten@dmfs.org >>>>>>> >>>>>>> Managing Director: Marten Gajda >>>>>>> Registered address: Dresden >>>>>>> Registered No.: AG Dresden HRB 34881 >>>>>>> VAT Reg. No.: DE303248743 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> webfinger mailing list >>>>>>> webfinger@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/webfinger >>>>>> >>>>> >>>>> -- >>>>> Marten Gajda >>>>> CEO >>>>> >>>>> dmfs GmbH >>>>> Schandauer Straße 34 >>>>> 01309 Dresden >>>>> GERMANY >>>>> >>>>> phone: +49 177 4427167 >>>>> email: marten@dmfs.org >>>>> >>>>> Managing Director: Marten Gajda >>>>> Registered address: Dresden >>>>> Registered No.: AG Dresden HRB 34881 >>>>> VAT Reg. No.: DE303248743 >>>>> >>>>> >>>>> _______________________________________________ >>>>> webfinger mailing list >>>>> webfinger@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/webfinger >>>> >>>> -- >>>> Marten Gajda >>>> CEO >>>> >>>> dmfs GmbH >>>> Schandauer Straße 34 >>>> 01309 Dresden >>>> GERMANY >>>> >>>> phone: +49 177 4427167 >>>> email: marten@dmfs.org >>>> >>>> Managing Director: Marten Gajda >>>> Registered address: Dresden >>>> Registered No.: AG Dresden HRB 34881 >>>> VAT Reg. No.: DE303248743 >>> >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >> >> -- >> Marten Gajda >> CEO >> >> dmfs GmbH >> Schandauer Straße 34 >> 01309 Dresden >> GERMANY >> >> phone: +49 177 4427167 >> email: marten@dmfs.org >> >> Managing Director: Marten Gajda >> Registered address: Dresden >> Registered No.: AG Dresden HRB 34881 >> VAT Reg. No.: DE303248743 -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------000509010708080409060603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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.

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.
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.

Document structure:  I think keeping this simple is really best.  I don't think we need multiple mail providers. If the email address is user@example.com, 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.

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




Paul

------ Original Message ------
From: "Marten Gajda" <marten@dmfs.org>
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" <marten@dmfs.org>
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",
}

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",
},
{
    "rel " :  "service-configuration",
}

Without that it would be more difficult to setup your account at acme-calendar.com with your login "user@example.com". acme-calendar.com would have to issue some kind of user-identifier like user@acme-calendar.com for auto-configuration purposes, even though you don't use it for authentication (because you use user@exampe.com 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:user@example.com 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",
}
 
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:user@example.com 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 paulej@packetizer.com 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
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

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

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------000509010708080409060603-- From nobody Fri Jul 15 01:36:53 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C9212D985 for ; Fri, 15 Jul 2016 01:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH4Qzeaf7Mab for ; Fri, 15 Jul 2016 01:36:47 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1598712D97E for ; Fri, 15 Jul 2016 01:36:47 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u6F8agpN009032 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Jul 2016 04:36:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1468571802; bh=MdN/naf0wRJCVrJVSLGe129qRxAAMybNkvPPVgwCoPo=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=c0rjp+XgAsxeyUclTCP4Qpo+fN6iNxyEwRQQFtmbut3rxxJkoN7Bi74xYeuWVvoIj 0Vk9IoF5n2JIddUzqgPHifw/9CzCcb+KRhAepFBouwWo+Cw/lZHV0jpByDF9elIQrD liV4bNkrCTm+nVQOGEvTseYZGESzTSHwM3YBTs2o= From: "Paul E. Jones" To: "Marten Gajda" , "webfinger@ietf.org" Date: Fri, 15 Jul 2016 08:36:53 +0000 Message-Id: In-Reply-To: <57880D75.5090109@dmfs.org> References: <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org> <57587369.20405@dmfs.org> <5786C161.7070806@dmfs.org> <57880D75.5090109@dmfs.org> User-Agent: eM_Client/7.0.26482.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB5B3A482C-CB43-4512-9213-0B135A18CEBC" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Fri, 15 Jul 2016 04:36:42 -0400 (EDT) Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 08:36:52 -0000 --------=_MB5B3A482C-CB43-4512-9213-0B135A18CEBC Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Marten, > >Am 14.07.2016 um 08:19 schrieb Paul E. Jones: >>Let's make sure the new draft is scoped to just mail configuration. =20 >>(If we want to go further with calendar, contacts, etc. then arguably=20 >>those should be separate URLs. My mail and calendar is not provided=20 >>by the same provider, for example.) >If we only support mail configuration this will probably fail. I think=20 >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=20 place. The type of information required to configure contacts and=20 calendar are quite different than email. So why produce a JSON document= =20 that tries to blend all three? The only thing I'm suggesting is to define the link relations. In the=20 future, there might be another (e.g., tasks). >>Certificate Auth: I'm not sure what the problem is here, unless people= =20 >>want to use enterprise-issued certificates (i.e., those that are not=20 >>from a public CA). If that is the case, I would not want my mail=20 >>client to insert those into my trusted certificate store. So, would=20 >>those be one-time uses? Not very useful. I'd say the IT department=20 >>needs to install whatever root certs are needed. A client should=20 >>authenticate the certificates it sees, but we don't need more words=20 >>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= =20 >a client certificate signed by some specific authority. This is not=20 >widely used and probably more for corporate or personal use cases, but=20 >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=20 >request from any other SSLException. So it would be helpful to know in=20 >advance if a specific client certificate is required or not. Oh! I totally had this backward. The challenge I see with using client= =20 certificates is that one of the benefits to using WebFinger is that I=20 don't have to manually configure my email clients I have on my 6=20 different clients. Even in the enterprise, having a mobile device and=20 computer is more common. So, I would not be opposed to this, but I'm=20 not sure it would be used much, particularly since the user is already=20 authenticating with other mechanisms. If the expectation is the user's=20 device will also authenticate with the mail server using the same=20 certificate, I guess this might be required. >>Document structure: I think keeping this simple is really best. I=20 >>don't think we need multiple mail providers. If the email address is=20 >>user@example.com, then I think it's reasonable to assume example.com=20 >>is the provider. Yes, a user could go enter WebFinger information for= =20 >>some other provider, but the average person will not want to do that. = =20 >>That's having the user configure the server so it can configure the=20 >>client. Not much gained there. I would have something that's no more= =20 >>complex than something like this: >> >I fully agree that we should keep it as simple as possible. However,=20 >one of the keys to success is that we support the services and use=20 >cases that are not covered by the existing mechanisms. That's why I=20 >believe that the document should have a generic structure that works=20 >with pretty much every service out there. It shouldn't be designed=20 >around email. This is one of the reasons for me to ditch the=20 >host/port/transport notation and just use a single URI instead. I'm not= =20 >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= =20 its own set of properties. The JRD sent by WebFinger is a document=20 along the lines of what you describe: very generic. And, that was=20 viewed as good. There is really very little one can convey: a subject,=20 some properties, and a set of links with associated properties. But, it gets really tricky trying to define something complex with a=20 JRD, and that's intended. Folks in the WG did not want it to do more=20 than what it does. And I think the same philosophy should be extended=20 to the services like mail, calendar, contacts, tasks, or whatever. If=20 each one is defined for the specific purpose they serve, the documents=20 will be clean and clear. >Another goal should be to revert the service discovery process to some=20 >degree. Instead of having the client to probe the provider for each=20 >service that might be supported, the current spec reverts that and=20 >returns a list of everything that's supported. The local "account setup= =20 >agent" then can probe the local device software for client modules or=20 >applications that might support a specific service. Ideally this would=20 >be supported on OS level. So you run a generic account configuration on= =20 >OS level, the OS pulls the service configuration document and calls the= =20 >installed handlers for each supported service. It there is no client=20 >for a specific service the OS could make suggestions like "Your=20 >provider also supports . Search the App Store for a=20 >suitable client app now". That's an interesting idea, but I would still prefer to keep the config=20 in different resources. Everything you describe could be done with=20 naming conventions or properties in the JRD. For example, a link might=20 have a "rel" value of "mail-config" and an "href" value. This might not= =20 mean much, but there could also be a property that indicates that it is=20 an "auto-configuration" link, perhaps the name of the service (e.g, =20 "Email"), etc. >That's why I believe that we should put all services into a single=20 >document, instead of using service specific rel-types that need to be=20 >probed by the client. Another reason not to do it: even within the same organization,=20 different departments might manage different services. You run into=20 challenges trying to get people to coordinate. Another reason is that folks in the IETF like to have things broken into= =20 granular pieces. That's why WF is more-or-less just a directory of=20 links. >If, like in your case, calendars and email are not hosted at the same=20 >provider, the webfinger response for your account should just contain=20 >two provider entries, each pointing to a document that lists all the=20 >services provided by this provider. In my case, I would expect paulej@packetizer.com to return only the=20 email service, since I don't have a calendar service there. I would=20 select the "Add Account" option in my email software and enter another=20 user ID to get the calendar. Yeah, I could have this in a single WF=20 reply, but the problem is that the average user isn't going to be adding= =20 such entries to his or her account. Of course, we do need to allow for the possibility that the IT=20 department will have one group running email and another handling=20 contacts / corporate directory services. So, a company might very well=20 have two links in the JRD returned by WF. And, that goes to my point,=20 again, that there's no point trying to define an all-encompasing=20 document. To be clear, though: I'm not opposed to having a generic document that=20 tries to be flexible enough to convey just about anything. I'm OK with=20 that. I just don't think that we should have a single document that=20 carries information for more than one service. I just don't see the=20 benefit in doing that vs. having two or three different link relations=20 -- one for each service to be configured. That said, I do not see that=20 it's very useful to have a generic document format vs. a specialized=20 one. After all, we still have to define the exactly contents of the=20 documents, generic or specialized. Paul --------=_MB5B3A482C-CB43-4512-9213-0B135A18CEBC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =20
Marten,


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. 

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 relat= ions.  In the future, there might be another (e.g., tasks).
 
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?  No= t 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.

Oh!  I totally had this backward.  The challenge I see= with using client certificates is that one of the benefits to using WebFin= ger 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 devi= ce 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. 

Document structure:  I think keeping this simple is = really best.  I don't think we need multiple mail providers. If the email address is user@example.com, 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 configu= re the client.  Not much gained there.  I would have somethi= ng 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 propert= ies.  The JRD sent by WebFinger is a document along the lines of what= you describe: very generic.  And, that was viewed as good.  Ther= e 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.


Another goal should be to revert the serv= ice 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 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-configur= ation" link, perhaps the name of the service (e.g,  "Email"), etc.


Th= at'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.

Another reason not to do it: even within the same organization,= different departments might manage different services. You run into challe= nges 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.

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.

In my case, I would expect paulej@packetizer.com 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 contac= ts / 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.<= /div>

To be clear, though: = I'm not opposed to having a generic document that tries to be flexible enou= gh 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.
<= br>
Paul
<= div id=3D"xdfae95614ddc4b3" style=3D" color: #000000">
--------=_MB5B3A482C-CB43-4512-9213-0B135A18CEBC--