Subject: Re: [webfinger] WebFinger 8 Input...

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 4 Dec 2012 20:51:39 -0500

Tim,

Perhaps we’re discussing different issues.  With respect to whether TLS is used to query the “webfinger” resource or not, I understand there are people arguing both sides.  I’m personally neutral on that.

Where the discussion was going here was related to “where do link relations in the webfinger response point?”  There is an argument that we must also require that TLS be used for all link relations.  I disagree with that as a requirement since we’re now talking about where a user stores his data (e.g., an avatar).  If he chooses to store that in Flickr or any $1/mo hosting provider should not matter.  Further, any client processing the WF response could see that it is an “http:” URI and decide on a case-by-case basis how to treat each link relation seen.

Paul

From: Tim Bray [mailto:[email-masked]] 
Sent: Tuesday, December 04, 2012 2:27 AM
To: Paul E. Jones
Cc: James M Snell; [email-masked]; Mike Jones; Peter Saint-Andre
Subject: Re: WebFinger 8 Input...

Paul, you can say this all you want, but there are coherent voices on our mailing list saying that they really need something written into the spec to give them assurance that they can use WF and it’ll either go through TLS or it won’t happen.  There are three coherent come-backs to this:

- Always HTTPS

- Some sort of normative parameterized behavior

- Those people shouldn’t use WebFinger.

At some point, someone’s going to have to make a consensus call on where the community stands. -T

On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones <[email-masked]> wrote:

James,

Keep in mind that WF is to allow users to share all kinds of information about themselves.  Services that need to be secure will use HTTPS.  Those that do not, won’t.

If I tell my WF service that my avatar is located at some http:// location, then that’s the information the WF server should return in responses.

If information needs better security, then the URL would be HTTPS.  Any IdP would utilize an https:// address.

In any case, the href value in WF can be any valid URI.  Use or non-use of TLS for these other resources to which WF refers is really outside the scope of WF.

Paul

From: James M Snell [mailto:[email-masked]] 
Sent: Tuesday, December 04, 2012 12:44 AM
To: Paul E. Jones
Cc: [email-masked]; Tim Bray; Mike Jones; Peter Saint-Andre
Subject: Re: WebFinger 8 Input...

On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones <[email-masked]> wrote:

James,

What a WF resource points to should have nothing to do with whether WF uses HTTPS or not.  If I put my vcard out on the Internet accessible only via http (which is presently the case), then that’s the way it’s accessed.  (Actually, the HTTPS version works on my domain, but will redirect the client to the non-HTTPS version.)

Well... for a typical non-authenticated request to a WebFinger resource, you're correct. There is an obvious risk, however, of introducing a session hijacking vulnerability when using authenticated WebFinger requests with an improperly secured server if the JRD provides non-https links to the same domain. It would be dangerous for us to assume that all relevant cookies provided on a given domain have been secured properly. As a best practice, links provided to resources located on the same domain should simply be required to use https as a way of erring on the side of caution. 

During a redirect, the redirection does not need to use the same scheme if the group agrees to allowing HTTP.  That said, I fully agree the example in section 8 should show use of HTTPS just as a means of encouragement.

Issuing a https secured request to a WF endpoint that redirects to an insecure third party location rather defeats the purpose of requiring https for the first request, doesn't it?

- James

Paul

From: James M Snell [mailto:[email-masked]] 
Sent: Monday, December 03, 2012 10:01 PM
To: Paul E. Jones
Cc: [email-masked]; Tim Bray; Mike Jones; Peter Saint-Andre
Subject: Re: WebFinger 8 Input...

Yep, as expected really. Take the various edits for what they are worth. It was either this or try to go through all the multitude of threads and provide input on each individual subject... this was by far the more efficient option for me. I'll come up with a summary of the changes a bit later on this evening. Most are purely editorial in nature, but there are a few important technical items... 

For instance, when serving up a JRD over an HTTPS connection, and that JRD contains link relations to resources hosted at the same domain as the WebFinger service, there is a risk of a TLS-downgrade attack if those link relations are not https urls... e.g. in the examples we see things like "href": "http://example.com/foo" ... when it really ought to be "href": "https://example.com/foo" ...

Similarly, if we are going to allow the use of 3xx redirects, then the WebFinger server needs to make sure that the new target URL is using the https scheme; i.e. instead of "Location: http://example.net/webfinger?..." it needs to be "Location: https://example.net/webfinger?..."

There are a few other bits scattered around. Once the kids are bathed and off to bed I'll write up a summary.

Honestly, other than the need to control the flood of discussions happening on the mailing list, I don't see any reason to rush this to completion. Let's get a relatively stable draft out there and just let it sit for a while so implementors can get more experience with it.

- James

On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones <[email-masked]> wrote:

James,

Wow, that’s a lot of changes.  I’d personally like to keep the terminology section the way it is.  The word “link relation” is confusing to people who have not heard it, and having that very brief statement is useful, I think.

Merging the “Introduction” and “Overview” sections might be a good idea, but I recall some time ago there was one section and it was suggested we split it apart.  What we would put in each, I’m not sure.  It’s definitely a bit overlapping at the moment.  I’m OK with merging those sections.

I really, really prefer to keep the examples in the main body.  They’re marked as non-normative, but being able to read those before getting further in the document is very helpful to the reader the first time they read the text.  Heck, even if they’ve read it, it’s nice to see examples right up front.  Otherwise, the reader’s headed is cloudy all the way through the text.

The header for Section 2 (“Terminology”) appears to have been removed accidentally.

In section 8, there are bullet points for the IANA registration template material.  Those should not be there.

Don’t use “URI” before the instant messaging address in the contact area.  Email addresses are also URIs :-)  I wanted IM there.

Beyond that, the changes are so substantial that I’ll need time to see exactly what they are.  I tried to produce a meaningful diff, but since the whole example section was moved, diff programs gets totally confused.

Paul

From: James M Snell [mailto:[email-masked]] 
Sent: Monday, December 03, 2012 8:38 PM
To: [email-masked]; Paul Jones; Tim Bray
Subject: WebFinger 8 Input...

Given that the recent WebFinger discussion has been flooding and overwhelming the IETF appsawg mailing list I have left that mailing list off the cc list until the new WF specific mailing list has been set up. While reading through the latest version of the spec, I started to collect a list of specific edits that I thought needed to be made. The list became rather detailed so it ended up just being easier to draft up a proposed new version.

I have checked it in to my personal github repo here...

  http://goo.gl/IaQnm

The raw xml is here...

  http://goo.gl/QcNCr

As always, feedback is definitely welcome.

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 4 Dec 2012 17:56:23 -0800

To be clear, I am NOT saying that all links in the document would need to
use HTTPS. I'm saying that if requests to the Webfinger resource are
authenticated, links to resources in the same domain as the WebFinger
server need to use HTTPS or else we run the risk of a session hijack.
That's a very different statement than "TLS be used for all link
relations".

In other words, if I send an authenticated request to
https://example.net/.well-known/webfinger?resource=foo, and the JRD
contains a link to an avatar image located on the same server, the link
should be like https://example.net/images/foo-avatar.png.

- James

On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones <[email-masked]> wrote:

> Tim,****
>
> ** **
>
> Perhaps we’re discussing different issues.  With respect to whether TLS is
> used to query the “webfinger” resource or not, I understand there are
> people arguing both sides.  I’m personally neutral on that.****
>
> ** **
>
> Where the discussion was going here was related to “where do link
> relations in the webfinger response point?”  There is an argument that we
> must also require that TLS be used for all link relations.  I disagree with
> that as a requirement since we’re now talking about where a user stores his
> data (e.g., an avatar).  If he chooses to store that in Flickr or any $1/mo
> hosting provider should not matter.  Further, any client processing the WF
> response could see that it is an “http:” URI and decide on a case-by-case
> basis how to treat each link relation seen.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* Tim Bray [mailto:[email-masked]]
> *Sent:* Tuesday, December 04, 2012 2:27 AM
> *To:* Paul E. Jones
> *Cc:* James M Snell; [email-masked]; Mike Jones; Peter
> Saint-Andre
>
> *Subject:* Re: WebFinger 8 Input...****
>
> ** **
>
> Paul, you can say this all you want, but there are coherent voices on our
> mailing list saying that they really need something written into the spec
> to give them assurance that they can use WF and it’ll either go through TLS
> or it won’t happen.  There are three coherent come-backs to this:****
>
> ** **
>
> - Always HTTPS****
>
> - Some sort of normative parameterized behavior****
>
> - Those people shouldn’t use WebFinger.****
>
> ** **
>
> At some point, someone’s going to have to make a consensus call on where
> the community stands. -T****
>
> ** **
>
> On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones <[email-masked]>
> wrote:****
>
> James,****
>
>  ****
>
> Keep in mind that WF is to allow users to share all kinds of information
> about themselves.  Services that need to be secure will use HTTPS.  Those
> that do not, won’t.****
>
>  ****
>
> If I tell my WF service that my avatar is located at some http://location, then that’s the information the WF server should return in
> responses.****
>
>  ****
>
> If information needs better security, then the URL would be HTTPS.  Any
> IdP would utilize an https:// address.****
>
>  ****
>
> In any case, the href value in WF can be any valid URI.  Use or non-use of
> TLS for these other resources to which WF refers is really outside the
> scope of WF.****
>
>  ****
>
> Paul****
>
>  ****
>
> *From:* James M Snell [mailto:[email-masked]]
> *Sent:* Tuesday, December 04, 2012 12:44 AM
> *To:* Paul E. Jones
> *Cc:* [email-masked]; Tim Bray; Mike Jones; Peter Saint-Andre
> *Subject:* Re: WebFinger 8 Input...****
>
>  ****
>
>  ****
>
> On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones <[email-masked]>
> wrote:****
>
> James,****
>
>  ****
>
> What a WF resource points to should have nothing to do with whether WF
> uses HTTPS or not.  If I put my vcard out on the Internet accessible only
> via http (which is presently the case), then that’s the way it’s accessed.
> (Actually, the HTTPS version works on my domain, but will redirect the
> client to the non-HTTPS version.)****
>
>  ****
>
> Well... for a typical non-authenticated request to a WebFinger resource,
> you're correct. There is an obvious risk, however, of introducing a session
> hijacking vulnerability when using authenticated WebFinger requests with an
> improperly secured server if the JRD provides non-https links to the same
> domain. It would be dangerous for us to assume that all relevant cookies
> provided on a given domain have been secured properly. As a best practice,
> links provided to resources located on the same domain should simply be
> required to use https as a way of erring on the side of caution. ****
>
>  ****
>
>  ****
>
> During a redirect, the redirection does not need to use the same scheme if
> the group agrees to allowing HTTP.  That said, I fully agree the example in
> section 8 should show use of HTTPS just as a means of encouragement.****
>
>  ****
>
>  ****
>
> Issuing a https secured request to a WF endpoint that redirects to an
> insecure third party location rather defeats the purpose of requiring https
> for the first request, doesn't it?****
>
>  ****
>
> - James****
>
>  ****
>
>  ****
>
> Paul****
>
>  ****
>
> *From:* James M Snell [mailto:[email-masked]]
> *Sent:* Monday, December 03, 2012 10:01 PM
> *To:* Paul E. Jones
> *Cc:* [email-masked]; Tim Bray; Mike Jones; Peter Saint-Andre
> *Subject:* Re: WebFinger 8 Input...****
>
>  ****
>
> Yep, as expected really. Take the various edits for what they are worth.
> It was either this or try to go through all the multitude of threads and
> provide input on each individual subject... this was by far the more
> efficient option for me. I'll come up with a summary of the changes a bit
> later on this evening. Most are purely editorial in nature, but there are a
> few important technical items... ****
>
>  ****
>
> For instance, when serving up a JRD over an HTTPS connection, and that JRD
> contains link relations to resources hosted at the same domain as the
> WebFinger service, there is a risk of a TLS-downgrade attack if those link
> relations are not https urls... e.g. in the examples we see things like
> "href": "http://example.com/foo" ... when it really ought to be "href": "
> https://example.com/foo" ...****
>
>  ****
>
> Similarly, if we are going to allow the use of 3xx redirects, then the
> WebFinger server needs to make sure that the new target URL is using the
> https scheme; i.e. instead of "Location: http://example.net/webfinger?..."
> it needs to be "Location: https://example.net/webfinger?..."****
>
>  ****
>
> There are a few other bits scattered around. Once the kids are bathed and
> off to bed I'll write up a summary.****
>
>  ****
>
> Honestly, other than the need to control the flood of discussions
> happening on the mailing list, I don't see any reason to rush this to
> completion. Let's get a relatively stable draft out there and just let it
> sit for a while so implementors can get more experience with it.****
>
>  ****
>
> - James****
>
>  ****
>
> On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones <[email-masked]>
> wrote:****
>
> James,****
>
>  ****
>
> Wow, that’s a lot of changes.  I’d personally like to keep the terminology
> section the way it is.  The word “link relation” is confusing to people who
> have not heard it, and having that very brief statement is useful, I think.
> ****
>
>  ****
>
> Merging the “Introduction” and “Overview” sections might be a good idea,
> but I recall some time ago there was one section and it was suggested we
> split it apart.  What we would put in each, I’m not sure.  It’s definitely
> a bit overlapping at the moment.  I’m OK with merging those sections.****
>
>  ****
>
> I really, really prefer to keep the examples in the main body.  They’re
> marked as non-normative, but being able to read those before getting
> further in the document is very helpful to the reader the first time they
> read the text.  Heck, even if they’ve read it, it’s nice to see examples
> right up front.  Otherwise, the reader’s headed is cloudy all the way
> through the text.****
>
>  ****
>
> The header for Section 2 (“Terminology”) appears to have been removed
> accidentally.****
>
>  ****
>
> In section 8, there are bullet points for the IANA registration template
> material.  Those should not be there.****
>
>  ****
>
> Don’t use “URI” before the instant messaging address in the contact area.
> Email addresses are also URIs :-)  I wanted IM there.****
>
>  ****
>
> Beyond that, the changes are so substantial that I’ll need time to see
> exactly what they are.  I tried to produce a meaningful diff, but since the
> whole example section was moved, diff programs gets totally confused.****
>
>  ****
>
> Paul****
>
>  ****
>
> *From:* James M Snell [mailto:[email-masked]]
> *Sent:* Monday, December 03, 2012 8:38 PM
> *To:* [email-masked]; Paul Jones; Tim Bray
> *Subject:* WebFinger 8 Input...****
>
>  ****
>
> Given that the recent WebFinger discussion has been flooding and
> overwhelming the IETF appsawg mailing list I have left that mailing list
> off the cc list until the new WF specific mailing list has been set up.
> While reading through the latest version of the spec, I started to collect
> a list of specific edits that I thought needed to be made. The list became
> rather detailed so it ended up just being easier to draft up a proposed new
> version.****
>
>  ****
>
> I have checked it in to my personal github repo here...****
>
>  ****
>
>   http://goo.gl/IaQnm****
>
>  ****
>
> The raw xml is here...****
>
>  ****
>
>   http://goo.gl/QcNCr****
>
>  ****
>
> As always, feedback is definitely welcome.****
>
>  ****
>
> - James****
>
>  ****
>
>  ****
>
> ** **
>

---

From: James M Snell <[email-masked]>
Date: Tue, 4 Dec 2012 20:28:06 -0800

All good but entirely orthogonal to the issue I raised. This has nothing to
do with what schemes are allowed in general and everything to do with a
possible session hijack vulnerability.
On Dec 4, 2012 8:25 PM, "John Panzer" <[email-masked]> wrote:

> +1.  Well, gopher is beyond the pale of course.
>
> data: would be particularly useful.
> On Dec 4, 2012 8:05 PM, "Brad Fitzpatrick" <[email-masked]> wrote:
>
>> I agree that the webfinger response's links should be allowed to be any
>> protocol, be it https://, http://, or gopher://.
>>
>> On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones <[email-masked]>wrote:
>>
>>> Tim,****
>>>
>>> ** **
>>>
>>> Perhaps we’re discussing different issues.  With respect to whether TLS
>>> is used to query the “webfinger” resource or not, I understand there are
>>> Paul, you can say this all you want, but there are coherent voices on
>>> our mailing list saying that they really need something written into the
>>> spec to give them assurance that they can use WF and it’ll either go
>>> through TLS or it won’t happen.  There are three coherent come-backs to
>>> this:****
>>>
>>> ** **
>>>
>>> - Always HTTPS****
>>>
>>> In any case, the href value in WF can be any valid URI.  Use or non-use
>>> of TLS for these other resources to which WF refers is really outside the
>>> scope of WF.****
>>>
>>>  ****
>>>
>>> Paul****
>>>
>>>  ****
>>>
>>> During a redirect, the redirection does not need to use the same scheme
>>> if the group agrees to allowing HTTP.  That said, I fully agree the example
>>> in section 8 should show use of HTTPS just as a means of encouragement.*
>>> ***
>>>
>>>  ****
>>>
>>>  ****
>>>
>>> For instance, when serving up a JRD over an HTTPS connection, and that
>>> JRD contains link relations to resources hosted at the same domain as the
>>> "href": "http://example.com/foo" ... when it really ought to be "href":
>>> "https://example.com/foo" ...****
>>>
>>>  ****
>>>
>>> There are a few other bits scattered around. Once the kids are bathed
>>> and off to bed I'll write up a summary.****
>>>
>>>  ****
>>>
>>> Wow, that’s a lot of changes.  I’d personally like to keep the
>>> terminology section the way it is.  The word “link relation” is confusing
>>> to people who have not heard it, and having that very brief statement is
>>> useful, I think.****
>>>
>>>  ****
>>>
>>> Don’t use “URI” before the instant messaging address in the contact
>>> area.  Email addresses are also URIs :-)  I wanted IM there.****
>>>
>>>  ****
>>>

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 5 Dec 2012 09:03:05 +0100

Agreed that https-only link rels (even on https wf) is too restrictive. I may have many public info out there that do not require https (my avatar at first). Plus there are many arguments for any Uris: data: is a good example for my avatar and auto configuration scenarios may involve other schemes maybe related to the scheme requested in the resource param, but not only.

Re https vs http as I mentioned earlier in many cases in mobile networks the user identity can be identified by the network only over http. This doesn't prevent https requests but typically require an initial plain http request, to create some session/cookie on the server side and then reissue the same over https. Sometimes sensible info is not passed in the first query/answer. Ultimately the goal is https in these cases as well but the spec shouldn't say that https must be first.

Le 5 déc. 2012 à 05:33, "John Panzer" <[email-masked]<mailto:[email-masked]>> a écrit :

Not orthogonal, as data: uris can't introduce a hijacking vulnerability and they are useful for that reason (plus latency).  So web finger would be over restrictive if it were to specify https only for example.

On Dec 4, 2012 8:28 PM, "James M Snell" <[email-masked]<mailto:[email-masked]>> wrote:

All good but entirely orthogonal to the issue I raised. This has nothing to do with what schemes are allowed in general and everything to do with a possible session hijack vulnerability.

On Dec 4, 2012 8:25 PM, "John Panzer" <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 4, 2012 8:05 PM, "Brad Fitzpatrick" <[email-masked]<mailto:[email-masked]>> wrote:
I agree that the webfinger response's links should be allowed to be any protocol, be it https://, http://, or gopher://.

On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
Tim,

Paul

From: Tim Bray [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 04, 2012 2:27 AM
To: Paul E. Jones
Cc: James M Snell; [email-masked]<mailto:[email-masked]>; Mike Jones; Peter Saint-Andre

- Always HTTPS

On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
James,

Paul

From: James M Snell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 04, 2012 12:44 AM
To: Paul E. Jones
Cc: [email-masked]<mailto:[email-masked]>; Tim Bray; Mike Jones; Peter Saint-Andre
Subject: Re: WebFinger 8 Input...

On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
James,

- James

Paul

From: James M Snell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, December 03, 2012 10:01 PM
To: Paul E. Jones
Cc: [email-masked]<mailto:[email-masked]>; Tim Bray; Mike Jones; Peter Saint-Andre
Subject: Re: WebFinger 8 Input...

- James

On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
James,

Paul

From: James M Snell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, December 03, 2012 8:38 PM
To: [email-masked]<mailto:[email-masked]>; Paul Jones; Tim Bray
Subject: WebFinger 8 Input...

  http://goo.gl/IaQnm

The raw xml is here...

  http://goo.gl/QcNCr

- James

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Evan Prodromou <[email-masked]>
Date: Wed, 05 Dec 2012 04:59:23 -0500

This puts a pretty big burden on the server. For many applications, 
there will be no "session" to get hijacked, and for others, the risk is 
tolerable.

Can we add this to "Security Considerations" as a potential threat, and 
say that clients SHOULD consider session hijacking when using links 
returned via Webfinger?

-Evan

On 12-12-04 08:56 PM, James M Snell wrote:
> To be clear, I am NOT saying that all links in the document would need 
> to use HTTPS. I'm saying that if requests to the Webfinger resource 
> are authenticated, links to resources in the same domain as the 
> WebFinger server need to use HTTPS or else we run the risk of a 
> session hijack. That's a very different statement than "TLS be used 
> for all link relations".
>
> contains a link to an avatar image located on the same server, the 
> link should be like https://example.net/images/foo-avatar.png.
>
> - James
>
>
>     Perhaps we're discussing different issues.  With respect to
>     whether TLS is used to query the "webfinger" resource or not, I
>     understand there are people arguing both sides.  I'm personally
>     neutral on that.
>
>     Where the discussion was going here was related to "where do link
>     relations in the webfinger response point?"  There is an argument
>     that we must also require that TLS be used for all link relations.
>     I disagree with that as a requirement since we're now talking
>     about where a user stores his data (e.g., an avatar).  If he
>     chooses to store that in Flickr or any $1/mo hosting provider
>     should not matter.  Further, any client processing the WF response
>     could see that it is an "http:" URI and decide on a case-by-case
>     basis how to treat each link relation seen.
>
>     Paul
>
>     *From:*Tim Bray [mailto:[email-masked] <mailto:[email-masked]>]
>     *Cc:* James M Snell; [email-masked]
>     <mailto:[email-masked]>; Mike Jones; Peter Saint-Andre
>
>
>     *Subject:* Re: WebFinger 8 Input...
>
>     Paul, you can say this all you want, but there are coherent voices
>     on our mailing list saying that they really need something written
>     into the spec to give them assurance that they can use WF and
>     it'll either go through TLS or it won't happen.  There are three
>     coherent come-backs to this:
>
>     - Always HTTPS
>
>     - Those people shouldn't use WebFinger.
>
>     At some point, someone's going to have to make a consensus call on
>     where the community stands. -T
>
>     On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     James,
>
>     Keep in mind that WF is to allow users to share all kinds of
>     information about themselves. Services that need to be secure will
>     use HTTPS.  Those that do not, won't.
>
>     If I tell my WF service that my avatar is located at some http://
>     location, then that's the information the WF server should return
>     in responses.
>
>     If information needs better security, then the URL would be
>     HTTPS.  Any IdP would utilize an https:// address.
>
>     In any case, the href value in WF can be any valid URI.  Use or
>     non-use of TLS for these other resources to which WF refers is
>     really outside the scope of WF.
>
>     Paul
>
>     *From:*James M Snell [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* [email-masked]
>     <mailto:[email-masked]>; Tim Bray; Mike Jones; Peter
>     Saint-Andre
>     *Subject:* Re: WebFinger 8 Input...
>
>     On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     James,
>
>     What a WF resource points to should have nothing to do with
>     whether WF uses HTTPS or not.  If I put my vcard out on the
>     Internet accessible only via http (which is presently the case),
>     then that's the way it's accessed. (Actually, the HTTPS version
>     works on my domain, but will redirect the client to the non-HTTPS
>     version.)
>
>     Well... for a typical non-authenticated request to a WebFinger
>     resource, you're correct. There is an obvious risk, however, of
>     introducing a session hijacking vulnerability when using
>     authenticated WebFinger requests with an improperly secured server
>     if the JRD provides non-https links to the same domain. It would
>     be dangerous for us to assume that all relevant cookies provided
>     on a given domain have been secured properly. As a best practice,
>     links provided to resources located on the same domain should
>     simply be required to use https as a way of erring on the side of
>     caution.
>
>         During a redirect, the redirection does not need to use the
>         same scheme if the group agrees to allowing HTTP.  That said,
>         I fully agree the example in section 8 should show use of
>         HTTPS just as a means of encouragement.
>
>     Issuing a https secured request to a WF endpoint that redirects to
>     an insecure third party location rather defeats the purpose of
>     requiring https for the first request, doesn't it?
>
>     - James
>
>         Paul
>
>         *From:*James M Snell [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *Cc:* [email-masked]
>         <mailto:[email-masked]>; Tim Bray; Mike Jones;
>         Peter Saint-Andre
>         *Subject:* Re: WebFinger 8 Input...
>
>         Yep, as expected really. Take the various edits for what they
>         are worth. It was either this or try to go through all the
>         multitude of threads and provide input on each individual
>         subject... this was by far the more efficient option for me.
>         I'll come up with a summary of the changes a bit later on this
>         evening. Most are purely editorial in nature, but there are a
>         few important technical items...
>
>         For instance, when serving up a JRD over an HTTPS connection,
>         and that JRD contains link relations to resources hosted at
>         the same domain as the WebFinger service, there is a risk of a
>         TLS-downgrade attack if those link relations are not https
>         urls... e.g. in the examples we see things like "href":
>         "http://example.com/foo" ... when it really ought to be
>         "href": "https://example.com/foo" ...
>
>         Similarly, if we are going to allow the use of 3xx redirects,
>         then the WebFinger server needs to make sure that the new
>         target URL is using the https scheme; i.e. instead of
>         "Location: http://example.net/webfinger?..." it needs to be
>         "Location: https://example.net/webfinger?..."
>
>         There are a few other bits scattered around. Once the kids are
>         bathed and off to bed I'll write up a summary.
>
>         Honestly, other than the need to control the flood of
>         discussions happening on the mailing list, I don't see any
>         reason to rush this to completion. Let's get a relatively
>         stable draft out there and just let it sit for a while so
>         implementors can get more experience with it.
>
>         - James
>
>         On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>         James,
>
>         Wow, that's a lot of changes. I'd personally like to keep the
>         terminology section the way it is. The word "link relation" is
>         confusing to people who have not heard it, and having that
>         very brief statement is useful, I think.
>
>         Merging the "Introduction" and "Overview" sections might be a
>         good idea, but I recall some time ago there was one section
>         and it was suggested we split it apart.  What we would put in
>         each, I'm not sure. It's definitely a bit overlapping at the
>         moment. I'm OK with merging those sections.
>
>         I really, really prefer to keep the examples in the main body.
>          They're marked as non-normative, but being able to read those
>         before getting further in the document is very helpful to the
>         reader the first time they read the text.  Heck, even if
>         they've read it, it's nice to see examples right up front.
>         Otherwise, the reader's headed is cloudy all the way through
>         the text.
>
>         The header for Section 2 ("Terminology") appears to have been
>         removed accidentally.
>
>         In section 8, there are bullet points for the IANA
>         registration template material. Those should not be there.
>
>         Don't use "URI" before the instant messaging address in the
>         contact area. Email addresses are also URIs :-) I wanted IM there.
>
>         Beyond that, the changes are so substantial that I'll need
>         time to see exactly what they are.  I tried to produce a
>         meaningful diff, but since the whole example section was
>         moved, diff programs gets totally confused.
>
>         Paul
>
>         *From:*James M Snell [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *To:* [email-masked]
>         <mailto:[email-masked]>; Paul Jones; Tim Bray
>         *Subject:* WebFinger 8 Input...
>
>         Given that the recent WebFinger discussion has been flooding
>         and overwhelming the IETF appsawg mailing list I have left
>         that mailing list off the cc list until the new WF specific
>         mailing list has been set up. While reading through the latest
>         version of the spec, I started to collect a list of specific
>         edits that I thought needed to be made. The list became rather
>         detailed so it ended up just being easier to draft up a
>         proposed new version.
>
> _______________________________________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger

---

From: Brad Fitzpatrick <[email-masked]>
Date: Tue, 4 Dec 2012 20:05:48 -0800

---

From: John Panzer <[email-masked]>
Date: Tue, 4 Dec 2012 20:25:33 -0800

data: would be particularly useful.
On Dec 4, 2012 8:05 PM, "Brad Fitzpatrick" <[email-masked]> wrote:

>> in section 8 should show use of HTTPS just as a means of encouragement.**
>> **
>>
>>  ****
>>
>>  ****
>>

---

From: John Panzer <[email-masked]>
Date: Tue, 4 Dec 2012 20:33:42 -0800

Not orthogonal, as data: uris can't introduce a hijacking vulnerability and
they are useful for that reason (plus latency).  So web finger would be
over restrictive if it were to specify https only for example.
On Dec 4, 2012 8:28 PM, "James M Snell" <[email-masked]> wrote:

> All good but entirely orthogonal to the issue I raised. This has nothing
> to do with what schemes are allowed in general and everything to do with a
>>>> At some point, someone’s going to have to make a consensus call on
>>>> where the community stands. -T****
>>>>
>>>> ** **
>>>>
>>>> information about themselves.  Services that need to be secure will use
>>>> HTTPS.  Those that do not, won’t.****
>>>>
>>>>  ****
>>>>
>>>> resource, you're correct. There is an obvious risk, however, of introducing
>>>> a session hijacking vulnerability when using authenticated WebFinger
>>>> requests with an improperly secured server if the JRD provides non-https
>>>> links to the same domain. It would be dangerous for us to assume that all
>>>> relevant cookies provided on a given domain have been secured properly. As
>>>> a best practice, links provided to resources located on the same domain
>>>> should simply be required to use https as a way of erring on the side of
>>>> caution. ****
>>>>
>>>>  ****
>>>>
>>>>  ****
>>>>
>>>> in section 8 should show use of HTTPS just as a means of encouragement.
>>>> ****
>>>>
>>>>  ****
>>>>
>>>>  ****
>>>>
>>>> Yep, as expected really. Take the various edits for what they are
>>>> worth. It was either this or try to go through all the multitude of threads
>>>> and provide input on each individual subject... this was by far the more
>>>> "href": "http://example.com/foo" ... when it really ought to be
>>>> "href": "https://example.com/foo" ...****
>>>>
>>>>  ****
>>>>
>>>> https scheme; i.e. instead of "Location:
>>>> http://example.net/webfinger?..." it needs to be "Location:
>>>> https://example.net/webfinger?..."****
>>>>
>>>>  ****
>>>>
>>>> Merging the “Introduction” and “Overview” sections might be a good
>>>> idea, but I recall some time ago there was one section and it was suggested
>>>> we split it apart.  What we would put in each, I’m not sure.  It’s
>>>> definitely a bit overlapping at the moment.  I’m OK with merging those
>>>> sections.****
>>>>
>>>>  ****
>>>>
>>>> In section 8, there are bullet points for the IANA registration
>>>> template material.  Those should not be there.****
>>>>
>>>>  ****
>>>>

---

From: Evan Prodromou <[email-masked]>
Date: Wed, 05 Dec 2012 04:58:50 -0500

-Evan

---

From: William Mills <[email-masked]>
Date: Wed, 5 Dec 2012 21:40:05 -0800 (PST)

+1

>________________________________
> From: John Panzer <[email-masked]>
>To: [email-masked] 
>Cc: [email-masked]; Mike Jones <[email-masked]>; James M Snell <[email-masked]>; Tim Bray <[email-masked]>; Peter Saint-Andre <[email-masked]> 
>Sent: Tuesday, December 4, 2012 8:25 PM
>Subject: Re: [webfinger] WebFinger 8 Input...
> 
>
>>>From:Tim Bray [mailto:[email-masked]] 
>>>From:James M Snell [mailto:[email-masked]] 
>>>>From:James M Snell [mailto:[email-masked]] 
>>>>From:James M Snell [mailto:[email-masked]]