Subject: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels]

From: Blaine Cook <[email-masked]>
Date: Fri, 14 Dec 2012 11:01:08 +0000

So, all this has me thinking. And I'm going to propose something totally
against much of what I've been saying.

Why not introduce a SECOND scheme, "accts"

If you want a secure lookup, your request (from a client-library
perspective) will look like:

webfinger.lookup('accts://[email-masked]')

or just
webfinger.lookup([email-masked]')

which will default to "accts", since that's the best-most-secure option.

If you want an unsecured lookup, use the "acct" scheme explicitly, so as
follows:

webfinger.lookup('acct://[email-masked]')

For applications where it doesn't matter, and you want to do a lookup and
get EITHER the secure or unsecured profile, it's trivial for library
authors to provide an explicit flag, like so:

webfinger.lookup([email-masked]', { allow_fallback: true })

OR it's easy enough for developers to do the lookup explicitly, like so:

webfinger.lookup('accts://[email-masked]', function (err, result) {
  if (result) {
    // do something with the secure result
    callback(err, result)
  } else {
    // c'mon, I just need a link to their public phonecam shots profile
    webfinger.lookup('acct://[email-masked]', callback)
  }
}

Does this make sense? I think it errs on the side of the HTTPS-only crowd,
which I sympathise with even if I can't lend 100% support to. It also errs
on the side of client simplicity, and mirrors HTTP behaviours (but defaults
to secure instead of insecure, as with HTTP).

Thoughts? Happy to try to write up some copy if this works for people.

b.

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 14 Dec 2012 13:25:19 +0100

+1. That’s fully in line with my proposal of some hours ago, that I realized was not sent over webfinger google group (re-sending separately)

Da: Blaine Cook [mailto:[email-masked]]
Inviato: venerdì 14 dicembre 2012 12.01
A: [email-masked]
Cc: John Panzer; [email-masked]; James M Snell; Goix Laurent Walter; Brad Fitzpatrick
Oggetto: A third (or is it twelfth?) way [was: secure links with https rels]

So, all this has me thinking. And I'm going to propose something totally against much of what I've been saying.

If you want a secure lookup, your request (from a client-library perspective) will look like:

webfinger.lookup('accts://[email-masked]<mailto:[email-masked]>')

or just
webfinger.lookup([email-masked]<mailto:[email-masked]>')

If you want an unsecured lookup, use the "acct" scheme explicitly, so as follows:

webfinger.lookup('acct://[email-masked]<mailto:[email-masked]>')

For applications where it doesn't matter, and you want to do a lookup and get EITHER the secure or unsecured profile, it's trivial for library authors to provide an explicit flag, like so:

webfinger.lookup([email-masked]<mailto:[email-masked]>', { allow_fallback: true })

webfinger.lookup('accts://[email-masked]<mailto:[email-masked]>', function (err, result) {
  if (result) {
    // do something with the secure result
    callback(err, result)
  } else {
    // c'mon, I just need a link to their public phonecam shots profile
    webfinger.lookup('acct://[email-masked]<mailto:[email-masked]>', callback)
  }
}

Does this make sense? I think it errs on the side of the HTTPS-only crowd, which I sympathise with even if I can't lend 100% support to. It also errs on the side of client simplicity, and mirrors HTTP behaviours (but defaults to secure instead of insecure, as with HTTP).

b.
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: Tim Bray <[email-masked]>
Date: Fri, 14 Dec 2012 09:01:46 -0800

That's 3 different mechanisms that've been proposed for explicit client
signaling that https-only is required.  Which is the right goal IMHO. I was
OK with Paul's latest no-fallback language too.
On Dec 14, 2012 3:01 AM, "Blaine Cook" <[email-masked]> wrote:

> _______________________________________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger
>
>

---

From: James M Snell <[email-masked]>
Date: Fri, 14 Dec 2012 09:05:09 -0800

Paul's latest language gives us the most flexibility in the long run
without sacrificing security or trying to be too clever. With the proposed
text, implementers who are strongly HTTPS-only are free to implement things
that way. The market will decide from there.

- James

On Fri, Dec 14, 2012 at 9:01 AM, Tim Bray <[email-masked]> wrote:

>> Does this make sense? I think it errs on the side of the HTTPS-only
>> crowd, which I sympathise with even if I can't lend 100% support to. It
>> also errs on the side of client simplicity, and mirrors HTTP behaviours
>> (but defaults to secure instead of insecure, as with HTTP).
>>

---

From: Melvin Carvalho <[email-masked]>
Date: Fri, 14 Dec 2012 13:59:06 +0100

> Why not introduce a SECOND scheme, "accts"

Is there an issue on whether IANA will approve two separate schemes?

---

From: Barry Leiba <[email-masked]>
Date: Fri, 14 Dec 2012 18:17:01 -0500

> Is there an issue on whether IANA will approve two separate schemes?

IANA doesn't "approve" anything; they administer the registries.

The IESG and the Designated Expert are the ones responsible for the
approvals.  If you'd like to have a discussion of whether separate
schemes make sense, I suggest you loop in Graham Klyne, the Designated
Expert for URI-schemes.

And if y'all want the IESG to approve anything, you'll have to find a
way to get to rough consensus.  That means compromises; that means
understanding that if a bunch of people have strong technical reasons
for going in one direction or another, it might make sense to agree to
head that way, and use the good will you earn to help you in another
fight.  I see a lot of spinning and churning here, with various
attempts to say, "OK, how about *this* compromise" (a GOOD approach),
followed by too much maintenance of the trenches.

Let's find the compromise and move ahead.

Barry, Applications AD

---

From: James M Snell <[email-masked]>
Date: Fri, 14 Dec 2012 20:25:02 -0800

WRT the issue of https-only, a consensus call was already made. The chair
posted afterwards indicating that there was no obvious consensus for
https-only. The only reasonable solution at this point should be clear.

The draft language posted by Paul yesterday that allows http or https but
not https-to-http fallback provides the least restrictive, most flexible
model without introducing significant security concerns or complexity.
Those who are in the https-only camp would be free to implement https-only
webfinger endpoints and clients. Those who want http would have what they
want to. From there, the market will decide which is the preferred choice
and someone can come along later a write up a BCP or update the spec if
implementation experience proves that one particular point of view is
better than the other.

If someone wishes to define a secure link rel concept, that can be done
independent of web finger, and should be done as an update to rfc5988. It
is completely orthogonal to the basic definition of web finger.

If someone wishes to implement some notion of secure-only links within a
web finger document, that too can be done independently of the basic web
finger protocol.

There really should not be anything left to debate on this. There are a few
other remaining issues that should be dealt with then we should call it a
day.

- james

---

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

Blaine,

How does this help us?  Let’s say I visit Bob’s blog and want to log in.  I enter my email address and Bob’s blog server will issue a WF query.  It knows it need to make a secure query, because it knows its own security requirements.  It would be that client code that would have to create the “accts” URI out of what I enter.  So, if it’s going to do that, why not just issue the query to whatever underlying library is un use like:

webfinger.lookup('acct:[email-masked]', 'secure:true');

Or similar.  If a library is used at all, we can signal that only an HTTPS query shall be made.

Perhaps I’m missing something?

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Friday, December 14, 2012 6:01 AM
To: [email-masked]
Cc: John Panzer; [email-masked]; James M Snell; Goix Laurent Walter; Brad Fitzpatrick
Subject: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels]

or just

  if (result) {

    callback(err, result)

  } else {

  }

}

b.

---

From: Goix Laurent Walter <[email-masked]>
Date: Sat, 15 Dec 2012 12:32:21 +0100

I asked myself the same question and ended up with accts: to be independent from the single client library signature. Having the secure flag in the uri itself is the most standard way of requesting tls. Sips: uri scheme was coined for this exact need as well wrt sip: plain scheme.
Otherwise you don't know how many client libraries will pop up and they probably won't share the same signature in their *lookup/discovery* method and may not all expose the secure flag at all, or may only support secure calls, thus fragmenting their usage depending on the use case types. The scheme option is the cleanest in this respect and seems to solve all concerns. But other *not found yet* options are welcome :)

Le 15 déc. 2012 à 08:43, "Paul E. Jones" <[email-masked]<mailto:[email-masked]>> a écrit :

Blaine,

webfinger.lookup('acct:[email-masked]<http://packetizer.com>', 'secure:true');

Paul

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Friday, December 14, 2012 6:01 AM
To: [email-masked]<mailto:[email-masked]>
Cc: John Panzer; [email-masked]<mailto:[email-masked]>; James M Snell; Goix Laurent Walter; Brad Fitzpatrick
Subject: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels]

or just

b.

---

From: Blaine Cook <[email-masked]>
Date: Sat, 15 Dec 2012 12:44:40 +0000

I agree with Laurent's comments here.

What I think we're both saying is that it seems clear that there is a
desire to include language that prefers secure lookups of webfinger data,
but allows lookups of unsecured data. Rather than inventing some way to
signal to client developers, providers, and authors of dependent protocols,
let's just use the existing approach that has been re-used in many places
before.

HTTP made the "wrong" default choice from a security perspective; when we
type in a URL into a browser, the default scheme is "http", not "https".
That's fine, from an historical perspective, but things like HSTS and
default-HTTPS lists embedded in browsers, and indeed all of this discussion
on "securing webfinger" is a reaction to that default.

Look, the only reason I'm advocating for non-SSL requests being allowed is
purely from a deployment perspective. There are loads of programmers (re:
early adopters) who use github pages to host their personal domains (re:
webfinger IDs). I raised this as an issue here, and received zero comments
acknowledging that as a real deployment scenario. There's a whole community
that's not present here ("indyweb") that's advocating for people owning
their own domains as being the only way forward (I disagree with their
absolutism on the question of hosted services, but sympathise). It's fine
if the participants here from Google and Microsoft and the IETF security
community want to claim that they can provide secure services to their
users; the fact is that there are real scenarios today and for the
foreseeable future where having real non-TLS lookups of webfinger data
would be useful.

I want this thing to be deployable. I want this community to make a
commitment to supporting users outside this community.

I *really* dislike the "acct" scheme, as I've made clear a number of times.
There's no "dns" scheme, and there doesn't need to be. I think the same is
true of "acct". However, as Bob Wyman has expressed, there *should have
been* a dns scheme. We have a chance to fix that for webfinger lookups, and
"accts" convinces me of the need for a scheme-based approach. Indeed, if
we're going to have schemes at all, and if we can (please) assume that it's
at least possible to have insecure webfinger lookups, then it demands us to
ask the question why *isn't* there an accts scheme?

Sorry for my sporadic and lengthy participation. I can't devote the time
necessary to be on the list all the time.

b.

On 15 December 2012 07:43, Paul E. Jones <[email-masked]> wrote:

> Blaine,****
>
> ** **
>
> How does this help us?  Let’s say I visit Bob’s blog and want to log in.
> I enter my email address and Bob’s blog server will issue a WF query.  It
> knows it need to make a secure query, because it knows its own security
> requirements.  It would be that client code that would have to create the
> “accts” URI out of what I enter.  So, if it’s going to do that, why not
> just issue the query to whatever underlying library is un use like:****
>
> ** **
>
> webfinger.lookup('acct:[email-masked]', 'secure:true');****
>
> ** **
>
> Or similar.  If a library is used at all, we can signal that only an HTTPS
> query shall be made.****
>
> ** **
>
> Perhaps I’m missing something?****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Blaine Cook
> *Sent:* Friday, December 14, 2012 6:01 AM
> *To:* [email-masked]
>
> *Cc:* John Panzer; [email-masked]; James M Snell; Goix Laurent
> Walter; Brad Fitzpatrick
> *Subject:* [webfinger] A third (or is it twelfth?) way [was: secure links
> with https rels]****
>
> ** **
>
> against much of what I've been saying.****
>
> ** **
>
> Why not introduce a SECOND scheme, "accts"****
>
> ** **
>
> perspective) will look like:****
>
> ** **
>
> webfinger.lookup('accts://[email-masked]')****
>
> ** **
>
> or just****
>
> webfinger.lookup([email-masked]')****
>
> ** **
>
> which will default to "accts", since that's the best-most-secure option.**
> **
>
> ** **
>
> follows:****
> ** **
> webfinger.lookup('acct://[email-masked]')****
>
> ** **
>
> authors to provide an explicit flag, like so:****
>
> ** **
>
> webfinger.lookup([email-masked]', { allow_fallback: true })****
>
> ** **
>
> OR it's easy enough for developers to do the lookup explicitly, like so:**
> **
>
> ** **
>
> webfinger.lookup('accts://[email-masked]', function (err, result) {****
>
>   if (result) {****
>
>     // do something with the secure result****
>
>     callback(err, result)****
>
>   } else {****
>
>     // c'mon, I just need a link to their public phonecam shots profile***
> *
>
>     webfinger.lookup('acct://[email-masked]', callback)****
>
>   }****
>
> }****
>
> ** **
>
> to secure instead of insecure, as with HTTP).****
>
> ** **
>
> Thoughts? Happy to try to write up some copy if this works for people.****
>
> ** **
>
> b.****
>

---

From: <[email-masked]>
Date: Sat, 15 Dec 2012 14:23:06 +0100

Based on a secure-by-default rule we could decide that “acct” translates to an https request.
I think it is good to make it easy to be secure and cumbersome to be insecure.

wf.lookup(“acct:[email-masked]”)    --> https://jensen.org/....
wf.lookup(“acct:[email-masked]”, insecure->true)    --> http://jenson.org/...

Axel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Saturday, December 15, 2012 1:45 PM
To: Paul E. Jones
Cc: John Panzer; [email-masked]; James M Snell; Goix Laurent Walter; Brad Fitzpatrick; [email-masked]
Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels]

What I think we're both saying is that it seems clear that there is a desire to include language that prefers secure lookups of webfinger data, but allows lookups of unsecured data. Rather than inventing some way to signal to client developers, providers, and authors of dependent protocols, let's just use the existing approach that has been re-used in many places before.

HTTP made the "wrong" default choice from a security perspective; when we type in a URL into a browser, the default scheme is "http", not "https". That's fine, from an historical perspective, but things like HSTS and default-HTTPS lists embedded in browsers, and indeed all of this discussion on "securing webfinger" is a reaction to that default.

Look, the only reason I'm advocating for non-SSL requests being allowed is purely from a deployment perspective. There are loads of programmers (re: early adopters) who use github pages to host their personal domains (re: webfinger IDs). I raised this as an issue here, and received zero comments acknowledging that as a real deployment scenario. There's a whole community that's not present here ("indyweb") that's advocating for people owning their own domains as being the only way forward (I disagree with their absolutism on the question of hosted services, but sympathise). It's fine if the participants here from Google and Microsoft and the IETF security community want to claim that they can provide secure services to their users; the fact is that there are real scenarios today and for the foreseeable future where having real non-TLS lookups of webfinger data would be useful.

I want this thing to be deployable. I want this community to make a commitment to supporting users outside this community.

I *really* dislike the "acct" scheme, as I've made clear a number of times. There's no "dns" scheme, and there doesn't need to be. I think the same is true of "acct". However, as Bob Wyman has expressed, there *should have been* a dns scheme. We have a chance to fix that for webfinger lookups, and "accts" convinces me of the need for a scheme-based approach. Indeed, if we're going to have schemes at all, and if we can (please) assume that it's at least possible to have insecure webfinger lookups, then it demands us to ask the question why *isn't* there an accts scheme?

Sorry for my sporadic and lengthy participation. I can't devote the time necessary to be on the list all the time.

b.

On 15 December 2012 07:43, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
Blaine,

webfinger.lookup('acct:[email-masked]<mailto:[email-masked]>', 'secure:true');

Paul

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Blaine Cook
Sent: Friday, December 14, 2012 6:01 AM
To: [email-masked]<mailto:[email-masked]>

or just

b.

---

From: Blaine Cook <[email-masked]>
Date: Sat, 15 Dec 2012 13:26:38 +0000

On 15 December 2012 13:23, <[email-masked]> wrote:

> Based on a secure-by-default rule we could decide that “acct” translates
> to an https request.****
>
> I think it is good to make it easy to be secure and cumbersome to be
> insecure.****
>
> ** **
>
> wf.lookup(“acct:[email-masked]”)    à https://jensen.org/....****
>
> wf.lookup(“acct:[email-masked]”, insecure->true)    à http://jenson.org/
> ...
>

I don't see how that's any different than just saying "webfinger is always
secure (except when it's not, but the standards committee doesn't want to
think about how this is used in the real world, so please don't tell us
what you actually do with it)"?

b.

---

From: Nick Jennings <[email-masked]>
Date: Sat, 15 Dec 2012 14:31:48 +0100

On Sat, Dec 15, 2012 at 1:44 PM, Blaine Cook <[email-masked]> wrote:
> absolutism on the question of hosted services, but sympathise).

On the contrary, I consider myself a part of this community and I
think there are a few others wandering about. :)

> It's fine if
> the participants here from Google and Microsoft and the IETF security
> foreseeable future where having real non-TLS lookups of webfinger data would
> be useful.

+1

---

From: Dick Hardt <[email-masked]>
Date: Sat, 15 Dec 2012 08:30:50 -0800

> think there are a few others wandering about. :)

I would guess that almost everyone on this list has their own personal domain. I have several.

>> commitment to supporting users outside this community.

On the other hand, if all the "indyweb" people want WF and HTTPS is required, the hosting services may innovate on easily providing HTTPS. I think this would be a Good Thing to happen.

As noted previously, the cost of certs is pretty much zero, so HTTPS as part of a standard hosting package is really a product management decision followed by a deployment task (i.e., it is not a major financial decision by hosting companies. Do we want to be brave and say HTTPS only and help drive a safer, more secure web?

-- Dick

---

From: Nick Jennings <[email-masked]>
Date: Sat, 15 Dec 2012 17:53:51 +0100

> As noted previously, the cost of certs is pretty much zero, so HTTPS as part of a standard hosting package is really a product management decision followed by a deployment task (i.e., it is not a m…

There are several reasons to allow HTTP, it's not *just* a cert issue.

1. Adoption. Make it easy for <insert wordpress blog here> to add a
WebFinger service to query things like avatar, name, some social media
links.

2. Maintenance. Your WebFinger service does not break when you fail to
go through the process of cert renewal every year. (it's not like you
just make a payment, you have to have a new cert issued and update
your server, this is not ideal for a lot of people).

3. High Latency Mobile Networks and Optimization. This isn't the
"HTTPS is slow" argument. This is not a 1st world issue, per-say,
however there are places with sub-optimal connectivity and HTTPS does
not help. In these cases, it's completely unnecessary when all you
want is a little bit of 'gravatar-like' functionality on your web
application or website. In these cases I'm referring to client-side WF
access (not servers making WF requests).

4. Cost. I know there is a free service, not everyone will know about
this free service. A lot of people will think they will need to pay
$50-100 per. year just to play the game. Those *same* people will
likely be people that are NOT going to be serving ANY sensitive
information and these factors will be taken into account when they
decide if they really want to adopt WF or not.

In these cases, HTTPS-only is a deterrent and detracts from #1
(Adoption), which IMO is the most important.

That said, I like the idea of HTTPS only, it's nice and simple. I just
don't think there's enough out there to make it easy for everyone to
adopt with little effort, not just up-front, but ongoing.

-Nick

---

From: Dick Hardt <[email-masked]>
Date: Sat, 15 Dec 2012 09:05:37 -0800

> adopt with little effort, not just up-front, but ongoing.

Thanks for the reiterating your points.

I think that *if* HTTPS is incorporated as part of the hosting service, points 1,2 & 4 are non-issues. 

I do agree that WF adoption by the indy web may be critical to WF success, and HTTPS is a barrier to indy web adoption of WF.

As for 3, HTTPS is required in secure transactions, even if they are mobile. Just because one use case does not need it does not mean it is not a good thing to be HTTPS only so that things that require HTTPS  'for sure' run over HTTPS.

Remember that payments drove the deployment of HTTPS to all ecommerce sights.  Intercepted credentials drove HTTPS to web mail and Twitter etc. Perhaps WF will drive HTTPS further?

Having said that, I'm ok (a +0.5)  with Paul's last revision as it allows HTTPS to be dictated by clients

-- Dick

---

From: Nick Jennings <[email-masked]>
Date: Sat, 15 Dec 2012 18:39:32 +0100

> I think that *if* HTTPS is incorporated as part of the hosting service, points 1,2 & 4 are non-issues.

The hosting service would provide TLS certs for 'yourdomain.com' ?
That would help, but a lot of people don't see the point in paying
yearly for a TLS cert if they're not doing e-commerce. (in this case
it would most definitely be a paid-addon)

> As for 3, HTTPS is required in secure transactions, even if they are mobile. Just because one use case does not need it does not mean it is not a good thing to be HTTPS only so that things that req…

Of course it's required for secure transactions. Every point I'm
making is for the "damn I just want a picture and some social network
links" situation. Again, this gives the power to the developer to
decide how they will use WF. IMO the servers should provide all
options (HTTPS and HTTP) when they can, and leave the use up to the
client. In addition, I'd like to see any secure information filtered
by both the server and client libraries, just to cover all our bases
for possible misuse. In that case, a developer not understanding what
he's doing, would not get a result for querying openid connect info
via an HTTP request.

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Sat, 15 Dec 2012 21:18:01 +0000

Excerpts from Dick Hardt's message of 2012-12-15 16:30:50 +0000:
[snip]
> As noted previously, the cost of certs is pretty much zero, so HTTPS as part of a standard hosting package is really a product management decision followed by a deployment task (i.e., it is not a m…
Besides possible complexity of getting and installing a cert I would also take a look on possible issues with Server Name Indication [1] which may lead that besides domain name and cert one may also need a dedicated IP as well :(

[1] Server Name Indication

---

From: Nick Jennings <[email-masked]>
Date: Sat, 15 Dec 2012 22:29:48 +0100

> Besides possible complexity of getting and installing a cert I would also take a look on possible issues with Server Name Indication [1] which may lead that besides domain name and cert one may als…

Good point, could be considered a 5th reason for allowing HTTP.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 01:43:12 -0500

Dick,

> As noted previously, the cost of certs is pretty much zero, so HTTPS as
> part of a standard hosting package is really a product management
> decision followed by a deployment task (i.e., it is not a major
> financial decision by hosting companies. Do we want to be brave and say
> HTTPS only and help drive a safer, more secure web?

But they're not.  Few (maybe only StartCom) provides free certificates and
those (last I checked) were limited to a single domain for a single year.

So, users are stuck with these options:
1) Buying a certificate that costs more than the domain itself
2) Getting a free one that has to be updated annually
3) Paying for a wildcard certificate, but those are fairly expensive and
only cover *.example.com, not *.foo.example.com.  To cover the sub-domain,
one needs another certificate or wildcard certificate

And then there is administrative effort.  Personally, I hate dealing with
certificates.  For that reason, I would LOVE to be able to completely
automate use of certificates by generating them myself and putting them in
DNS using procedures defined in DANE.  I wish the world would go forward
with DNSSEC!

As it is, they're expensive in one way or another, a headache, etc.  They're
vital for business, but far less vital to most people who might be running a
blog or whatever.

All that said, I'm still OK with mandating TLS.  Would casual bloggers even
use an identifier like [email-masked]?  Or would they use a gmail
identifier or other identifier from a domain that likely supports WF
securely?  But, I assume serious bloggers would not be turned off by a
certificate.  I have no idea.

Paul

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Sun, 16 Dec 2012 11:13:43 +0000

> certificate.  I have no idea.
if someone runs a blog on personal domain and authenticates to it with username/password pair, this person already better use HTTPS! just in such case even self-signed can keep us safe...

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 Dec 2012 08:52:55 -0800

> those (last I checked) were limited to a single domain for a single year.

I'm talking about a future where having TLS is just another part of what is automagically deployed at a hosting service.

No, it does not exist today. If there was more demand, it *could* exist in the future.

-- Dick

---

From: Kingsley Idehen <[email-masked]>
Date: Sat, 15 Dec 2012 17:01:39 -0500

> Remember that payments drove the deployment of HTTPS to all ecommerce sights.  Intercepted credentials drove HTTPS to web mail and Twitter etc. Perhaps WF will drive HTTPS further?
Yes, and none of that happened as a result of an HTTPS-only spec., which 
is the most important point here.

As per usual, folks found out for themselves the hard way -- because we 
humans don't like prevention, we are wired for cures :-)

We need to make a spec that's going to make Webfinger widely adopted. 
Once adopted, folks will end up in the right place. What you shouldn't 
do is issue a mandate disguised as a spec, it never works re., broad 
adoption.

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen