Subject: [webfinger] the conflicting goals

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 11:35:08 -0800

Here are the conflicting forces at work in the WebFinger spec, as I see it:

1) security (the HTTPS-only camp, and people who want to use WebFinger for
the base of e.g. OpenID Connect).  It should be possible to get a key/value
pair ("link") only over HTTPS.

2) HTTP-permitted (status.net, Blaine, Paul, et al ... also those who just
want to use WebFinger for casual things... names & avatars, or doing their
own crypto/signing out of band, and/or don't like the Root CA system)

3) client simplicity.

I believe that we can only have 2 of those 3.  We've heard proposals for
different sets of those two:

1+2: secure rel proposal (clients filtering out secure rels from HTTP
responses).  requires some complexity in clients to filter out insecure
rels.
1+3: HTTPS-only.
2: contact either HTTP or HTTPS.  servers SHOULD run on both?  latest
proposal, which I feel will be error-prone.
2+~3: contact both HTTP & HTTPS in parallel or with fallback, use whatever
you can connect to. No security.

Originally I voted for HTTPS-only (which is 1+3), but enough people on this
list want 2), so I think we need to give up 3) and go with 1+2.

I remain fine with HTTPS-only, but I don't think it has enough support.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 15:33:42 -0500

Brad,

To be clear, I’m in neither camp (1) or (2).  I’ve abstained from taking sides on this.

What I would expect is that if a client feels that security is paramount for its application (e.g., logging into a web site), then it would use HTTPS.  If not, use HTTP.

What I consider the simplest solution is:

1)      Let the client use HTTP or HTTPS depending on its preference, guided by its security requirements

2)      Servers that serve content only on HTTPS would redirect HTTP requests to HTTPS

3)      Clients that issue HTTPS requests and where the server happens to not be listening on HTTPS fail

I believe #3 is the pain point.  With the exception of #3, clients are simple and are were simple.  But #3 introduces a breakage where users ask, “Why can you find any information about me?”

The choice then becomes one of replying with “because your WF provider is insecure” or you change the client code to do the “fall back” to HTTP.  The latter is undesirable from a security perspective, but the choice really is that of the client.  If they would have been OK with HTTP in the first place, then they could re-query using HTTP.  The spec does not have to mandate or even recommend that behavior.  If security is important, then the client just does not query using HTTP and the firm answer is “the remote server is insecure”.

In short, let this be a client decision as to whether it needs security or not.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad Fitzpatrick
Sent: Thursday, December 13, 2012 2:35 PM
To: [email-masked]
Subject: [webfinger] the conflicting goals

1) security (the HTTPS-only camp, and people who want to use WebFinger for the base of e.g. OpenID Connect).  It should be possible to get a key/value pair ("link") only over HTTPS.

2) HTTP-permitted (status.net, Blaine, Paul, et al ... also those who just want to use WebFinger for casual things... names & avatars, or doing their own crypto/signing out of band, and/or don't like the Root CA system)

3) client simplicity.

I believe that we can only have 2 of those 3.  We've heard proposals for different sets of those two:

1+2: secure rel proposal (clients filtering out secure rels from HTTP responses).  requires some complexity in clients to filter out insecure rels.

1+3: HTTPS-only.

2: contact either HTTP or HTTPS.  servers SHOULD run on both?  latest proposal, which I feel will be error-prone.

2+~3: contact both HTTP & HTTPS in parallel or with fallback, use whatever you can connect to. No security.

Originally I voted for HTTPS-only (which is 1+3), but enough people on this list want 2), so I think we need to give up 3) and go with 1+2.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 12:50:54 -0800

On Thu, Dec 13, 2012 at 12:33 PM, Paul E. Jones <[email-masked]>wrote:

> Brad,****
>
> ** **
>
> To be clear, I’m in neither camp (1) or (2).  I’ve abstained from taking
> sides on this.****
>
> ** **
>
> What I would expect is that if a client feels that security is paramount
> for its application (e.g., logging into a web site), then it would use
> HTTPS.  If not, use HTTP.****
>
> ** **
>
> What I consider the simplest solution is:****
>
> **1)      **Let the client use HTTP or HTTPS depending on its preference,
> guided by its security requirements****
>
> **2)      **Servers that serve content only on HTTPS would redirect HTTP
> requests to HTTPS****
>
> **3)      **Clients that issue HTTPS requests and where the server
> happens to not be listening on HTTPS fail****
>
> ** **
>
> I believe #3 is the pain point.  With the exception of #3, clients are
> simple and are were simple.  But #3 introduces a breakage where users ask,
> “Why can you find any information about me?”****
>
> ** **
>
> The choice then becomes one of replying with “because your WF provider is
> insecure” or you change the client code to do the “fall back” to HTTP.  The
> latter is undesirable from a security perspective, but the choice really is
> that of the client.  If they would have been OK with HTTP in the first
> place, then they could re-query using HTTP.  The spec does not have to
> mandate or even recommend that behavior.  If security is important, then
> the client just does not query using HTTP and the firm answer is “the
> remote server is insecure”.****
>
> ** **
>

I don't like this.  Concerns:

* flakiness.  sometimes it just fails, because everybody had choices and
the spec doesn't mandate either party behaving any particular way.

* if clients do HTTPS-to-HTTP fallback to combat flakiness, we're back at
square one with the security camp being unhappy.  This is where we started.

* if I just want to query all link relations for [email-masked], how do I
do it?  Do I as an application have to explicitly pick HTTPS-only when I do
that query, and then pick HTTP-only if it fails?  So now instead of
trusting just webfinger client library authors, we're trusting each and
every application.

I want to make it simple and secure for a spec (like OpenID Connect) to
specify their WebFinger rel and then have WebFinger clients say:

- give me all links (one of which might be for the OpenID Connect rel)
- give me a certain link (e.g. the OpenID Connect rel)

... and know that if they get the OpenID Connect one, it arrived over
HTTPS, per the OpenID Connect spec's wishes.

I don't want applications to have to keep track of which transport links
arrived over.

You may think this is all overly complicated and we can just say "Clients:
do whatever! security is your job!", but that is fundamentally what the
HTTPS-only camp is against.

If you want to make the security group happy, you either need ~this or
HTTPS-only.
If you want to make the HTTP-okay group happy, you either need this or you
need to lose the support of the security group.

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 13:42:38 -0800

On Thu, Dec 13, 2012 at 12:33 PM, Paul E. Jones <[email-masked]>wrote:

> [snip]
> In short, let this be a client decision as to whether it needs security or
> not.****
>
> **
>

+1 ... this is the only sensible position.

- James

> **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Brad Fitzpatrick
> *Sent:* Thursday, December 13, 2012 2:35 PM
> *To:* [email-masked]
> *Subject:* [webfinger] the conflicting goals****
>
> ** **
>
> ****
> pair ("link") only over HTTPS.****
>
> ** **
>
> 2) HTTP-permitted (status.net, Blaine, Paul, et al ... also those who
> just want to use WebFinger for casual things... names & avatars, or doing
> their own crypto/signing out of band, and/or don't like the Root CA system)
> ****
>
> ** **
>
> 3) client simplicity.****
>
> ** **
>
> different sets of those two:****
>
> ** **
>
> rels.****
> 1+3: HTTPS-only.****
> proposal, which I feel will be error-prone.****
>
> you can connect to. No security.****
>
> ** **
>
> Originally I voted for HTTPS-only (which is 1+3), but enough people on
> this list want 2), so I think we need to give up 3) and go with 1+2.****
>
> ** **
>
> I remain fine with HTTPS-only, but I don't think it has enough support.***
> *
>
> ** **
>
> _______________________________________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger
>
>

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 13 Dec 2012 16:49:01 -0500

Brad,

Can I suggest another possibility?

 1. The Webfinger spec mandates HTTPS-only.
 2. Those of us who want to support HTTP fall back to RFC 6415 (going
    through HostMeta and LRDD).
 3. If there's a pressing need for an HTTP-accessible
    /.well-known/webfinger endpoint, we do another teeny-tiny spec for
    that. ("Do Webfinger, but on HTTP. QED.")

It's going to take a while for /.well-known/webfinger endpoints to get 
deployed, and falling back to /.well-known/host-meta will probably be 
part of our world for a while, so it's not really that big a loss.

I can definitely live with this; MMN?

-Evan

On 12-12-13 02:35 PM, Brad Fitzpatrick wrote:
> 1) security (the HTTPS-only camp, and people who want to use WebFinger 
> for the base of e.g. OpenID Connect).  It should be possible to get a 
> key/value pair ("link") only over HTTPS.
>
> 2) HTTP-permitted (status.net <http://status.net>, Blaine, Paul, et al 
> ... also those who just want to use WebFinger for casual things... 
> names & avatars, or doing their own crypto/signing out of band, and/or 
> don't like the Root CA system)
>
> 3) client simplicity.
>
> responses).  requires some complexity in clients to filter out 
> insecure rels.
> 1+3: HTTPS-only.
> 2+~3: contact both HTTP & HTTPS in parallel or with fallback, use 
> whatever you can connect to. No security.
>
> this list want 2), so I think we need to give up 3) and go with 1+2.
>

-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: [email-masked] P: +1-514-554-3826

---

From: Tim Bray <[email-masked]>
Date: Thu, 13 Dec 2012 13:53:59 -0800

+1

On Thu, Dec 13, 2012 at 1:49 PM, Evan Prodromou <[email-masked]> wrote:

>    /.well-known/webfinger endpoint, we do another teeny-tiny spec for that.
>    ("Do Webfinger, but on HTTP. QED.")
>
> deployed, and falling back to /.well-known/host-meta will probably be part
> of our world for a while, so it's not really that big a loss.
>
> webfinger mailing [email-masked]://www.ietf.org/mailman/listinfo/webfinger
>
>
>
> --

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 17:12:13 -0500

Brad,

I agree there is a little flakiness.  Specifically, if a WF server decides to provide WF services only on HTTP, then there will be some clients that fail.

Don’t conflate that issue with getting particular link relations, though.  Any OpenID-related WF client could ALWAYS issue requests via HTTPS (even though I assert that still is not a bullet-proof solution since a rogue web site can still do dirty things by directing a user to a phishing site).

The way I see it, we either have to accept that some clients might fail to get a reply (since the user’s WF server only supports HTTP) or we have to mandate use of HTTPS.

Paul

From: Brad Fitzpatrick [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 3:51 PM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [webfinger] the conflicting goals

On Thu, Dec 13, 2012 at 12:33 PM, Paul E. Jones <[email-masked]> wrote:

Brad,

* flakiness.  sometimes it just fails, because everybody had choices and the spec doesn't mandate either party behaving any particular way.

* if clients do HTTPS-to-HTTP fallback to combat flakiness, we're back at square one with the security camp being unhappy.  This is where we started.

* if I just want to query all link relations for [email-masked], how do I do it?  Do I as an application have to explicitly pick HTTPS-only when I do that query, and then pick HTTP-only if it fails?  So now instead of trusting just webfinger client library authors, we're trusting each and every application.

I want to make it simple and secure for a spec (like OpenID Connect) to specify their WebFinger rel and then have WebFinger clients say:

... and know that if they get the OpenID Connect one, it arrived over HTTPS, per the OpenID Connect spec's wishes.

I don't want applications to have to keep track of which transport links arrived over.

You may think this is all overly complicated and we can just say "Clients: do whatever! security is your job!", but that is fundamentally what the HTTPS-only camp is against.

If you want to make the security group happy, you either need ~this or HTTPS-only.

If you want to make the HTTP-okay group happy, you either need this or you need to lose the support of the security group.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 14:19:36 -0800

On Thu, Dec 13, 2012 at 2:12 PM, Paul E. Jones <[email-masked]>wrote:

> Brad,****
>
> ** **
>
> I agree there is a little flakiness.  Specifically, if a WF server decides
> to provide WF services only on HTTP, then there will be some clients that
> fail.****
>
> ** **
>
> Don’t conflate that issue with getting particular link relations, though.
> Any OpenID-related WF client could ALWAYS issue requests via HTTPS (even
> though I assert that still is not a bullet-proof solution since a rogue web
> site can still do dirty things by directing a user to a phishing site).***
> *
>
> ** **
>
> The way I see it, we either have to accept that some clients might fail to
> get a reply
>

unacceptable, IMO.

> (since the user’s WF server only supports HTTP) or we have to mandate use
> of HTTPS.
>

Yes, I support either HTTPS-only, in either of two forms:

a) HTTPS-only for everything
b) HTTPS-only-for-"secure-rels"

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 14:23:16 -0800

> I can definitely live with this; MMN?

How much of that would you want to put in the WebFinger spec?

If just (1), great: that's just HTTPS-only-for-everything, which already
has a lot of support, but I thought you were one of the main opponents.

If also (2), that's starting to get pretty ugly, adding that dependency and
reference.

As I told Paul, I'm down for either HTTPS-only for everything or
HTTPS-only-for-"secure-rels".

---

From: Nick Jennings <[email-masked]>
Date: Thu, 13 Dec 2012 23:23:49 +0100

For what it's worth. I'll chime in here and say what I think makes the
most sense to me.

1. Servers MUST answer over both HTTPS and HTTP (no upgrading or downgrading).

2. Servers MUST filter 'secure' links from any HTTP request.

3. Client libraries SHOULD default to using HTTPS and MAY offer
configuration options to use HTTP.

4. Client libraries MUST filter any 'secure' links from any HTTP
request (just in case)

On Thu, Dec 13, 2012 at 11:12 PM, Paul E. Jones <[email-masked]> wrote:
> fail.
> site can still do dirty things by directing a user to a phishing site).
>
>
>
> get a reply (since the user’s WF server only supports HTTP) or we have to
> mandate use of HTTPS.
>
>
>
> Paul
>
>
>
> sides on this.
> What I would expect is that if a client feels that security is paramount for
> its application (e.g., logging into a web site), then it would use HTTPS.
> If not, use HTTP.
>
>
>
> “Why can you find any information about me?”
>
>
>
> mandate or even recommend that behavior.  If security is important, then the
> client just does not query using HTTP and the firm answer is “the remote
> server is insecure”.
>
>
>
> not.
> * flakiness.  sometimes it just fails, because everybody had choices and the
> spec doesn't mandate either party behaving any particular way.
>
>
>
> that query, and then pick HTTP-only if it fails?  So now instead of trusting
> just webfinger client library authors, we're trusting each and every
> application.
>
>
>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 14:32:23 -0800

> 4. Client libraries MUST filter any 'secure' links from any HTTP

Of the 3 goals I mentioned earlier (secure, HTTP, and simple client), this
seems to be just secure.  Any proposal should be able to get 2 of the 3,
not just 1.

In particular, your item (1) alienates the camp who doesn't want to buy SSL
certs.

And your item (3) introduces an configuration option, which also worries
the security camp (giving less security-aware applications options to mess
up) and also makes the client-simplicity story worse.  And then (4) makes
the client-simplicity story worse yet.

---

From: Nick Jennings <[email-masked]>
Date: Thu, 13 Dec 2012 23:46:06 +0100

On Thu, Dec 13, 2012 at 11:32 PM, Brad Fitzpatrick <[email-masked]> wrote:
> seems to be just secure.  Any proposal should be able to get 2 of the 3, not
> just 1.
>

(maybe I should have given my points letters so I could reference your
points and mine without confusion).

It addresses all of the concerns related to (your point #2) EXCEPT for
the SSL cert issue (which would not be solved for HTTPS-only anyway).

> And your item (3) introduces an configuration option, which also worries the
> security camp (giving less security-aware applications options to mess up)
> and also makes the client-simplicity story worse.

The whole point of (your point #2) (from my perspective) is so that a
web developer can make the decision to keep things as simple and
use-able for anyone using their site/app (ie. mobile devices). They
should be able to say "give me names and avatars using HTTP"... that's
a pretty basic configuration option, and any security-focused link,
like OpenID, wouldn't come back because of my points (2) and (4)

No matter what, there will be configuration options and client
complexity unless we go with HTTPS only.

> And then (4) makes the
> client-simplicity story worse yet.
>

I suggested the server-filtering only, but you brought up the point
that an HTTP request could be intercepted and 'secure' links could be
sent back.
The client should ignore 'secure' links no matter what, if HTTPS was
not used. So, the complexity would be there unless we used HTTPS only.

---

From: Nick Jennings <[email-masked]>
Date: Thu, 13 Dec 2012 23:47:33 +0100

In short, I think my suggestion addresses points (1) and (3) - the
client simplicity is cut down because there's not 'fallback' which was
the main sore-spot. And half or more of (2)

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 14:51:44 -0800

> the main sore-spot. And half or more of (2)

But your proposal says servers MUST do both HTTP and HTTPS.  Once you're
saying that HTTPS is required, what's the advantage of allowing clients to
do HTTP?  Why not just say HTTPS-only on both sides?

The opponents to HTTPS aren't concerned about client-HTTPS, just
server-HTTPS.

(I still think HTTPS-only is the simplest proposal.)

---

From: Nick Jennings <[email-masked]>
Date: Thu, 13 Dec 2012 23:58:31 +0100

> (I still think HTTPS-only is the simplest proposal.)

So, instead of HTTPS and HTTP... We REQUIRE HTTP and require HTTPS for
sending any secure information?

No fallback, no downgrading/upgrading. If you want to serve any
secure-data, that data will be queried against HTTPS, so if you don't
want to play with certs, then you don't get to provide secure-data for
your users.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 15:10:58 -0800

> sending any secure information?

requiring HTTP seems fine.  HTTPS was already de-facto required for secure
info, so no objections on this.

> want to play with certs, then you don't get to provide secure-data for

With no fallback, clients now need to be configured, right?  I believe the
concern is that this is pushing security too far out.

Also, what do you propose clients filter?

---

From: Nick Jennings <[email-masked]>
Date: Fri, 14 Dec 2012 00:15:39 +0100

> concern is that this is pushing security too far out.

var links = webFinger.getAllLinks([email-masked]', {secure:true});

Something like that would be a real easy way to say "give me all
links, including secure stuff". That would obviously default to HTTPS.

var avatar = webFinger.getAvatar([email-masked]');

That would default to HTTP.

> Also, what do you propose clients filter?

I don't know off-hand, the same way they'd have to do the filtering in
your initial proposal?

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 18:27:20 -0500

Nick,

> var links = webFinger.getAllLinks([email-masked]', {secure:true});

This is equal to using HTTPS and stopping there.
 
> var avatar = webFinger.getAvatar([email-masked]');

That's equal to either:
1) Doing HTTPS and falling back to HTTP
2) Doing HTTP only

This is possible with the proposal on the table.  Just to remind folks, here is the current proposal (as modified during discussions):

    Clients MAY issue a query to the WebFinger server using either
    HTTPS or HTTP, but MUST NOT attempt to use both, either serially
    or in parallel.  The choice of transport protocols depends on the
    client's security requirements, though use of HTTPS is
    RECOMMENDED in most situations.

    If a query is issued using HTTPS and the server has an invalid
    certificate, the client MUST accept that the WebFinger query has
    failed.

    WebFinger servers operating on HTTP MAY redirect a client using
    an _appropriate_ HTTP status code to another HTTP or an HTTPS URI.
    Likewise, WebFinger servers operating on HTTPS MAY redirect a
    client to another HTTPS URI, but MUST NOT redirect a client to an
    HTTP URI.  Further, clients MUST NOT follow a redirection from an
    HTTPS URI to an HTTP URI, but SHOULD automatically follow all
    other server redirects.

(I'd like to replace "appropriate" above with "3xx".)

Paul

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 15:37:52 -0800

+1 to this... with one exception.. see below...

On Thu, Dec 13, 2012 at 3:27 PM, Paul E. Jones <[email-masked]>wrote:

> [snip]
>
> This is possible with the proposal on the table.  Just to remind folks,
> here is the current proposal (as modified during discussions):
>

Change to: If a query is issued using HTTPS and either: a) the server
returns an invalid certificate, b) the server returns a 4xx or 5xx status
or c) the HTTPS connection cannot be established for any reason, the client
MUST accept that the WebFinger query has failed and MUST NOT attempt to
reissue the WebFinger request using HTTP.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 18:48:27 -0500

That’s closer to what was in the -6 or -07 drafts.  Removing the (a), (b), … stuff.  How is this:

If a query is issued using HTTPS and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP.

If we want to allow for fall back in the case that the client really does not care whether the response is secure or not, then we’d need to soften that language.  Right now, it’s either all or nothing.

Paul

From: James M Snell [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 6:38 PM
To: Paul E. Jones
Cc: Nick Jennings; Brad Fitzpatrick; [email-masked]
Subject: Re: [webfinger] the conflicting goals

On Thu, Dec 13, 2012 at 3:27 PM, Paul E. Jones <[email-masked]> wrote:

[snip]

Change to: If a query is issued using HTTPS and either: a) the server returns an invalid certificate, b) the server returns a 4xx or 5xx status or c) the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP. 

Paul

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 15:51:53 -0800

That's fine. If the client really does not care whether the response is
secure or not, the client can issue the initial request over HTTP. If the
request is sent over HTTPS the assumption should be that's what the client
intended.

On Thu, Dec 13, 2012 at 3:48 PM, Paul E. Jones <[email-masked]>wrote:

> That’s closer to what was in the -6 or -07 drafts.  Removing the (a), (b),
> … stuff.  How is this:****
>
> ** **
>
> certificate, the server returns a 4xx or 5xx status code, or the HTTPS
> connection cannot be established for any reason, the client MUST accept
> that the WebFinger query has failed and MUST NOT attempt to reissue the
> WebFinger request using HTTP.****
>
> ** **
>
> If we want to allow for fall back in the case that the client really does
> not care whether the response is secure or not, then we’d need to soften
> that language.  Right now, it’s either all or nothing.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* James M Snell [mailto:[email-masked]]
> *Sent:* Thursday, December 13, 2012 6:38 PM
> *To:* Paul E. Jones
> *Cc:* Nick Jennings; Brad Fitzpatrick; [email-masked]
>
> *Subject:* Re: [webfinger] the conflicting goals****
>
> ** **
>
> +1 to this... with one exception.. see below...****
>
> ** **
>
> On Thu, Dec 13, 2012 at 3:27 PM, Paul E. Jones <[email-masked]>
> wrote:****
>
> [snip]
>
>     failed.****
> reissue the WebFinger request using HTTP. ****
>
>  ****
>
>
> https://www.ietf.org/mailman/listinfo/webfinger****
>
> ** **
>

---

From: Mikael Nordfeldth <[email-masked]>
Date: Fri, 14 Dec 2012 09:43:30 +0100

>    that. ("Do Webfinger, but on HTTP. QED.")

Talk about client complexity! However, since noone would likely write a 
_new_ client with a RFC6415 fallback functionality I see it more as a 
way things would be nonetheless if verified-HTTPS-only becomes the 
Webfinger spec. (unimplemented HTTP Webfinger causes continued use of 
legacy RFCs)

Regarding #3 though I think that specification will rise from a harsh 
reality rather than a desired specification. I imagine people defying 
the specification and:
* running HTTP-doubling webfinger servers (which serve 
less-verified/secure data)
* clients doing lookups to unverified HTTPS/HTTP servers, simply 
reporting back whether the connection was signed with a trusted SSL 
certificate or not.

> I can definitely live with this; MMN?

Honestly, I have a hard time seeing what would in practice become two 
specifications, "webfinger-ssl" and "webfinger", when the differences 
and caveats of the added "S" are already well-known from HTTPS/HTTP. Too 
redundant, I think.

Though as mentioned previously, my main personal issues are difficult 
deployment of HTTPS and also a false sense of security that arises with 
blind faith in HTTPS.

-- 
Mikael Nordfeldth
http://blog.mmn-o.se/
[email-masked]
+46705657637

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 14 Dec 2012 10:29:50 +0100

I would also avoid this as this is ok for a transitional period only but supposes that eventually once the community has migrated, only https is supported.

Da: [email-masked] [mailto:[email-masked]] Per conto di Evan Prodromou
Inviato: giovedì 13 dicembre 2012 22.49
A: [email-masked]
Cc: Mikael Nordfeldth
Oggetto: Re: [webfinger] the conflicting goals

Brad,

 1.  The Webfinger spec mandates HTTPS-only.
 2.  Those of us who want to support HTTP fall back to RFC 6415 (going through HostMeta and LRDD).
 3.  If there's a pressing need for an HTTP-accessible /.well-known/webfinger endpoint, we do another teeny-tiny spec for that. ("Do Webfinger, but on HTTP. QED.")
It's going to take a while for /.well-known/webfinger endpoints to get deployed, and falling back to /.well-known/host-meta will probably be part of our world for a while, so it's not really that big a loss.

-Evan

2) HTTP-permitted (status.net<http://status.net>, Blaine, Paul, et al ... also those who just want to use WebFinger for casual things... names & avatars, or doing their own crypto/signing out of band, and/or don't like the Root CA system)

3) client simplicity.

webfinger mailing list

[email-masked]<mailto:[email-masked]>

--

E: [email-masked]<mailto:[email-masked]> P: +1-514-554-3826

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: ☮ elf Pavlik ☮ <[email-masked]>
Date: Fri, 14 Dec 2012 18:31:27 +0000

Excerpts from Paul E. Jones's message of 2012-12-13 23:27:20 +0000:
<snip />
>     HTTPS URI to an HTTP URI, but SHOULD automatically follow all
i see in many places this topic of HTTP request redirected to HTTPS and must say that i don't understand for which scenario we need it?

---

From: Nick Jennings <[email-masked]>
Date: Fri, 14 Dec 2012 19:36:29 +0100

> i see in many places this topic of HTTP request redirected to HTTPS and must say that i don't understand for which scenario we need it?

I agree, I would prefer this not to happen. HTTP and HTTPS shouldn't
fallback (from the server perspective). I added it in my suggestion
because it seemed like others (most notably Paul) wanted it.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 15 Dec 2012 02:34:38 -0500

It's just there to make it clear that redirecting to HTTPS it OK, but not the other way around.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ? elf Pavlik ?
> Sent: Friday, December 14, 2012 1:31 PM
> To: Paul E. Jones
> Cc: webfinger
> i see in many places this topic of HTTP request redirected to HTTPS and
> must say that i don't understand for which scenario we need it?

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 15 Dec 2012 02:37:27 -0500

I think we need to say something here, but I'm open on the wording.

Many sites (including my own) tend to redirect, say, packetizer.com to www.packetizer.com.  The same thing might happen with particular resources like "webfinger".  That's OK, but we don't want https:// to get redirected to "http://".  Absolutely nothing wrong with the other way around.

With all of the debate over HTTPS, I cannot imagine letting this spec go out with language about when it is and is not valid to redirect a client.

Paul

> From: Nick Jennings [mailto:[email-masked]]
> Sent: Friday, December 14, 2012 1:36 PM
> To: ☮ elf Pavlik ☮
> Cc: Paul E. Jones; webfinger
> On Fri, Dec 14, 2012 at 7:31 PM, ☮ elf Pavlik ☮ <perpetual-
> [email-masked]> wrote:
> > i see in many places this topic of HTTP request redirected to HTTPS
> and must say that i don't understand for which scenario we need it?
>