Subject: Re: [apps-discuss] Webfinger goals doc

From: John Bradley <[email-masked]>
Date: Tue, 27 Nov 2012 23:41:48 -0300

That is a good summery, thanks for putting that together with Blane.

On the https: issue.  The use of webfinger by authentication protocols leads to it being a tempting target for compromise.

If an attacker can fake your webfinger document by compromising a RP's DNS then they can send you to a fake IdP to collect your login credentials.
I expect that a number of things advertised in WenFinger may have similar security concerns.

I expect that openID Connect would need to profile WF to be https: only.

So my personal preference would be go https: only for everything.  I know that is probably not the answer that many others would give, but WF servers having TLS certificates is not unreasonable, and fallback to http will compromise those things that need security or just cause mysterious interoperability issues.

I would add that JRD could use some simplification.   I was one of the XRD authors with Eran back in the day. 
I think many of the XRD elements are related to some of the XRI concepts and can just be dropped.

Our format needs links and perhaps a subject.  Everything else is probably counter productive at this point.

Regards
John B.

On 2012-11-27, at 11:17 PM, Brad Fitzpatrick <[email-masked]> wrote:

> I just had a chat with Blaine after his recent "I'm out!" email.  I don't think he's actually out--- he's been working on WebFinger for as long as I have and cares a lot about it.  I think he was just grumpy about the process, speed, and confused about goals and decisions.
> 
> Anyway, we had a very productive conversation on chat and wrote a doc together to clarify thought processes and decisions:
> 
> https://docs.google.com/document/d/1Yr00Tr5d71-E6x7VDtmEaC48SendGWQe7XcY99pjQWs/edit#
> 
> The doc is open for comments.  I'll try to keep the doc edited and neutral.  It outlines requirements (aka goals for webfinger), assumptions, and decisions with pros & cons for each and what decision was ultimately made and why.
> 
> The decisions are I'm sure subject to change, but hopefully not too much.
> 
> Let me know what I missed.
> 
> My apologies if you don't like the document's medium or fluidity, but it's the tool I have to work with, and better than nothing.  If you object to the fluidity and want something concrete to reply to in email, I've snapshotted the document to http://goo.gl/fTMC1 but I won't accept comments or make changes there.  Use whatever mechanism you prefer.
> 
> - Brad
> 
> 
> Copy of doc for posterity:
> 
> WebFinger Goals, Assumptions, and Decisions (SNAPSHOT1)
> 
> aka background reading on understanding the WebFinger spec
> 
> Requirements
> 
> 
> given just a string that looks like “[email-masked]”, find a machine-readable metadata document.
> background: since the death of the “finger” protocol (from which webfinger gets its name), email-looking identifiers like “[email-masked]” have been write-only: you can email it (maybe, if it speaks SMTP), but you can’t do any read/discovery operations on it.  You can’t find its supported or preferred protocols, its name, its avatar, its public key, its identity/social/blog server, etc.
> the format of the identifier matters because people (“regular users”) effortlessly identify with their email addresses, and already use them for sharing outside (and inside) of social networks
> corollary: WebFinger is not about doing discovery on URLs or URIs or IRIs or XRIs or any other “dorky” identifier.  Webfinger is about doing a discovery (read) operation on something a non-technical user would write on a napkin or give you on a business card.
> clients can be implemented in browsers in JavaScript
> corollary: CORS shout-out in spec
> corollary: no DNS component
> delegation to webfinger-as-a-service by larger providers from self-hosted or organisational domains is possible (cf. DNS NS records)
> latency of updates must be low (unlike DNS)
> no service provider (no company) is special-cased.
> Assumptions
> 
> 
> the string “[email-masked]” is NOT necessarily an email address, even though most people today associate it with an email address.
> corollary: the “acct:” URI scheme and draft-ietf-appsawg-acct-uri-01 etc
> complexity in specs leads to few and/or poor implementations and ultimately hinders adoption
> corollary: value simplicity wherever possible, even if it means some things are harder or not possible for some parties.
> i.e. we’d rather have a 3 page spec that makes 90% of people happy rather than a 30 page spec that makes 95% of people happy, especially if such a smaller spec means a much improved chance of adoption.
> obvious, but: optional parts in specs need to be optional for only one party (client or server) and required for the other.
> i.e. there needs to always be an intersection of features in the spec that both parties support.  e.g. can’t have both clients and servers decide to only speak
> there will be more clients than servers
> corollary: it should be easier to write/run a client than a server
> few users own their own domain name and will run their own identity server
> … and those that do own their own domain name will mostly want to delegate management of their webfinger profiles or will know what they’re doing and therefore don’t need to be catered to.
> further assumption: most will be running Wordpress or some such software already.
> corollary: we don’t have to cater to this small audience much.. they’ll know what they’re doing, or their hosting software will.  
> should be easy to do both client and server. Ideal solution balances both (delegation for simpler servers)?
> standards MUST be programmer-friendly
> Decisions
> 
> 
> HTTP vs DNS
> DNS (SRV, TXT, etc) precludes JavaScript clients (as of 2006-2012), so rejected. HTTP instead.
> JSON vs XML
> Per assumption above, we needed to pick at least one as required.  We chose JSON.  If both parties advertise (via HTTP headers) that they prefer XML, that’s fine.  JSON is easier for JavaScript clients, as one advantage.  It’s also simpler to read on the page (per the complexity argument).  But both are small arguments and not worth arguing about.  At the end of the day a decision had to be made, and it was.
> HTTP-ish (Accept / Link headers, etc) vs well-known path
> 
> HTTP-ish is more proper, but viewed as too hard for servers to route (routing on headers, rather than request paths) and more importantly too hard for clients to send (setting headers).
> well-known URLs (like /favicon.ico) are gross, though.
> Decision: use a well-known URL.
> We defined RFC 5785 first instead, to make using a well-known path less offensive.
> One HTTP request vs two.
> Two requests: clients first fetch /.well-known/host-meta (to find where to do a webfinger query), then fetch that.
> PRO: the host-meta document can be a static file, which makes delegation to other webfinger service providers easier for custom domains.
> CON: twice the latency, especially for mobile
> CON: extra client complexity
> One request: clients just do a query immediately to /.well-known/webfinger, without consulting host-meta.
> PRO: half the latency
> PRO: less client complexity
> CON: service providers may need to reverse-proxy the query to the right backend.
> CON: harder for small domain names with static webservers to delegate.
> Decision: Just one HTTP requests, because we care more about client simplicity than server simplicity.
> HTTPS-only vs HTTPS-recommended
> HTTPS-only:
> PRO: secure
> PRO: simpler for clients (one round-trip)
> CON: hard for some servers to setup (config, certs, etc)
> HTTPS-recommended:
> CON: added client complexity.  But at least good clients can opportunistically fetch both in parallel and only use HTTP if they’re feeling trusting, once they see the HTTPS one fails. If HTTPS succeeds, no added latency.
> PRO: easier 
> Decision: HTTPS-recommended.  Clients may choose to only do HTTPS, as can servers, which means in practice almost all servers will probably only be HTTPS.
> Debate: this seems inconsistent with our policy of caring about clients and simplicity more than servers.  And it seems like a failure to decide, since we say both are optional for either party, counter to the assumption above that specs need requirements for either client or server.
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Nov 2012 22:32:23 -0500

I’m confused.  Haven’t we reached a decision on every point?  At this point, it seems like it’s largely an exercise of editorial refinement.

Blaine, you definitely were not ignored.  I’m not playing dictator, either ;-)  Your input has been invaluable, though I understand some things you wanted (most notably the ability to have an absolutely static site with flat files and no Apache re-writing) are not in the current spec.  However, it’s definitely far simpler than before.  The only sore point was the “subdomain” and it appears this is to be removed by consensus. (I’m still trying to understand if that’s the case.)

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad Fitzpatrick
Sent: Tuesday, November 27, 2012 9:18 PM
To: [email-masked]; [email-masked]
Subject: Webfinger goals doc

https://docs.google.com/document/d/1Yr00Tr5d71-E6x7VDtmEaC48SendGWQe7XcY99pjQWs/edit# <https://docs.google.com/document/d/1Yr00Tr5d71-E6x7VDtmEaC48SendGWQe7XcY99pjQWs/edit> 

- Brad

Requirements

*	given just a string that looks like “ <mailto:[email-masked]> [email-masked]”, find a machine-readable metadata document.

*	background: since the death of the “finger” protocol (from which webfinger gets its name), email-looking identifiers like “ <mailto:[email-masked]> [email-masked]” have been write-only: you can email it (maybe, if it speaks SMTP), but you can’t do any read/discovery operations on it.  You can’t find its supported or preferred protocols, its name, its avatar, its public key, its identity/social/blog server, etc.
*	the format of the identifier matters because people (“regular users”) effortlessly identify with their email addresses, and already use them for sharing outside (and inside) of social networks

*	corollary: WebFinger is not about doing discovery on URLs or URIs or IRIs or XRIs or any other “dorky” identifier.  Webfinger is about doing a discovery (read) operation on something a non-technical user would write on a napkin or give you on a business card.

*	clients can be implemented in browsers in JavaScript

*	corollary: CORS shout-out in spec
*	corollary: no DNS component

*	delegation to webfinger-as-a-service by larger providers from self-hosted or organisational domains is possible (cf. DNS NS records)
*	latency of updates must be low (unlike DNS)
*	no service provider (no company) is special-cased.

Assumptions

*	the string “ <mailto:[email-masked]> [email-masked]” is NOT necessarily an email address, even though most people today associate it with an email address.

*	corollary: the “acct:” URI scheme and draft-ietf-appsawg-acct-uri-01 etc

*	complexity in specs leads to few and/or poor implementations and ultimately hinders adoption

*	corollary: value simplicity wherever possible, even if it means some things are harder or not possible for some parties.
*	i.e. we’d rather have a 3 page spec that makes 90% of people happy rather than a 30 page spec that makes 95% of people happy, especially if such a smaller spec means a much improved chance of adoption.

*	obvious, but: optional parts in specs need to be optional for only one party (client or server) and required for the other.

*	i.e. there needs to always be an intersection of features in the spec that both parties support.  e.g. can’t have both clients and servers decide to only speak

*	there will be more clients than servers

*	corollary: it should be easier to write/run a client than a server

*	few users own their own domain name and will run their own identity server

*	… and those that do own their own domain name will mostly want to delegate management of their webfinger profiles or will know what they’re doing and therefore don’t need to be catered to.
*	further assumption: most will be running Wordpress or some such software already.
*	corollary: we don’t have to cater to this small audience much.. they’ll know what they’re doing, or their hosting software will.  

*	should be easy to do both client and server. Ideal solution balances both (delegation for simpler servers)?
*	standards MUST be programmer-friendly

Decisions

*	HTTP vs DNS

*	DNS (SRV, TXT, etc) precludes JavaScript clients (as of 2006-2012), so rejected. HTTP instead.

*	JSON vs XML

*	Per assumption above, we needed to pick at least one as required.  We chose JSON.  If both parties advertise (via HTTP headers) that they prefer XML, that’s fine.  JSON is easier for JavaScript clients, as one advantage.  It’s also simpler to read on the page (per the complexity argument).  But both are small arguments and not worth arguing about.  At the end of the day a decision had to be made, and it was.

*	HTTP-ish (Accept / Link headers, etc) vs well-known path

*	HTTP-ish is more proper, but viewed as too hard for servers to route (routing on headers, rather than request paths) and more importantly too hard for clients to send (setting headers).
*	well-known URLs (like /favicon.ico) are gross, though.
*	Decision: use a well-known URL.
*	We defined RFC 5785 first instead, to make using a well-known path less offensive.

*	One HTTP request vs two.

*	Two requests: clients first fetch /.well-known/host-meta (to find where to do a webfinger query), then fetch that.

*	PRO: the host-meta document can be a static file, which makes delegation to other webfinger service providers easier for custom domains.
*	CON: twice the latency, especially for mobile
*	CON: extra client complexity

*	One request: clients just do a query immediately to /.well-known/webfinger, without consulting host-meta.

*	PRO: half the latency
*	PRO: less client complexity
*	CON: service providers may need to reverse-proxy the query to the right backend.
*	CON: harder for small domain names with static webservers to delegate.

*	Decision: Just one HTTP requests, because we care more about client simplicity than server simplicity.

*	HTTPS-only vs HTTPS-recommended

*	HTTPS-only:

*	PRO: secure
*	PRO: simpler for clients (one round-trip)
*	CON: hard for some servers to setup (config, certs, etc)

*	HTTPS-recommended:

*	CON: added client complexity.  But at least good clients can opportunistically fetch both in parallel and only use HTTP if they’re feeling trusting, once they see the HTTPS one fails. If HTTPS succeeds, no added latency.
*	PRO: easier 

*	Decision: HTTPS-recommended.  Clients may choose to only do HTTPS, as can servers, which means in practice almost all servers will probably only be HTTPS.
*	Debate: this seems inconsistent with our policy of caring about clients and simplicity more than servers.  And it seems like a failure to decide, since we say both are optional for either party, counter to the assumption above that specs need requirements for either client or server.
*

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Nov 2012 22:44:38 -0500

John,

I would not be opposed to requiring HTTPS only, but I can definitely see
some domains where TLS simply isn't important.  I agree that for use of
OpenID, it is.  So for a bunch of domains out there that have no concern in
the world for security - all info is just out on the Internet in the clear -
why force HTTPS?

I beg you not to force a re-write or changes to JRD at this point.  Things
like "Expires" can be ignored.  Arguably, it shouldn't have been there in
the first place since HTTP could have provided that bit of info.  However,
aliases and properties (doc level and link level) can be useful.  The
example in the current -04 draft (Section 4.3) shows a good example of that.
We don't need to go into detail in the WF spec in these fields, but anyone
who writes a document that might define a link relation where properties are
used would detail precise usage.

The XRD spec (and JRD spec) are trivial and I'd like to leave it as-is,
otherwise we'll be at this for another 6 months effectively re-writing.
What we discussed during the last IETF meeting was to insert some example
that show use of these fields so implementers didn't have to even read the
XRD spec.  I believe the examples show every possible element.  There is no
more complexity than what is written.

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of John Bradley
Sent: Tuesday, November 27, 2012 9:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Webfinger goals doc

On the https: issue.  The use of webfinger by authentication protocols leads
to it being a tempting target for compromise.

If an attacker can fake your webfinger document by compromising a RP's DNS
then they can send you to a fake IdP to collect your login credentials.

I expect that a number of things advertised in WenFinger may have similar
security concerns.

So my personal preference would be go https: only for everything.  I know
that is probably not the answer that many others would give, but WF servers
having TLS certificates is not unreasonable, and fallback to http will
compromise those things that need security or just cause mysterious
interoperability issues.

I would add that JRD could use some simplification.   I was one of the XRD
authors with Eran back in the day. 

I think many of the XRD elements are related to some of the XRI concepts and
can just be dropped.

Our format needs links and perhaps a subject.  Everything else is probably
counter productive at this point.

Regards

John B.

I just had a chat with Blaine after his recent "I'm out!" email.  I don't
think he's actually out--- he's been working on WebFinger for as long as I
have and cares a lot about it.  I think he was just grumpy about the
process, speed, and confused about goals and decisions.

Anyway, we had a very productive conversation on chat and wrote a doc
together to clarify thought processes and decisions:

https://docs.google.com/document/d/1Yr00Tr5d71-E6x7VDtmEaC48SendGWQe7XcY99pj
QWs/edit#
<https://docs.google.com/document/d/1Yr00Tr5d71-E6x7VDtmEaC48SendGWQe7XcY99p
jQWs/edit> 

The doc is open for comments.  I'll try to keep the doc edited and neutral.
It outlines requirements (aka goals for webfinger), assumptions, and
decisions with pros & cons for each and what decision was ultimately made
and why.

My apologies if you don't like the document's medium or fluidity, but it's
the tool I have to work with, and better than nothing.  If you object to the
fluidity and want something concrete to reply to in email, I've snapshotted
the document to http://goo.gl/fTMC1 but I won't accept comments or make
changes there.  Use whatever mechanism you prefer.

- Brad

Requirements

*	given just a string that looks like " <mailto:[email-masked]>
[email-masked]", find a machine-readable metadata document.

*	background: since the death of the "finger" protocol (from which
webfinger gets its name), email-looking identifiers like "
<mailto:[email-masked]> [email-masked]" have been write-only: you can email it
(maybe, if it speaks SMTP), but you can't do any read/discovery operations
on it.  You can't find its supported or preferred protocols, its name, its
avatar, its public key, its identity/social/blog server, etc.
*	the format of the identifier matters because people ("regular
users") effortlessly identify with their email addresses, and already use
them for sharing outside (and inside) of social networks

*	corollary: WebFinger is not about doing discovery on URLs or URIs or
IRIs or XRIs or any other "dorky" identifier.  Webfinger is about doing a
discovery (read) operation on something a non-technical user would write on
a napkin or give you on a business card.

*	delegation to webfinger-as-a-service by larger providers from
self-hosted or organisational domains is possible (cf. DNS NS records)
*	latency of updates must be low (unlike DNS)
*	no service provider (no company) is special-cased.

Assumptions

*	the string " <mailto:[email-masked]> [email-masked]" is NOT
necessarily an email address, even though most people today associate it
with an email address.

*	corollary: the "acct:" URI scheme and draft-ietf-appsawg-acct-uri-01
etc

*	complexity in specs leads to few and/or poor implementations and
ultimately hinders adoption

*	corollary: value simplicity wherever possible, even if it means some
things are harder or not possible for some parties.
*	i.e. we'd rather have a 3 page spec that makes 90% of people happy
rather than a 30 page spec that makes 95% of people happy, especially if
such a smaller spec means a much improved chance of adoption.

*	obvious, but: optional parts in specs need to be optional for only
one party (client or server) and required for the other.

*	i.e. there needs to always be an intersection of features in the
spec that both parties support.  e.g. can't have both clients and servers
decide to only speak

*	few users own their own domain name and will run their own identity
server

*	. and those that do own their own domain name will mostly want to
delegate management of their webfinger profiles or will know what they're
doing and therefore don't need to be catered to.
*	further assumption: most will be running Wordpress or some such
software already.
*	corollary: we don't have to cater to this small audience much..
they'll know what they're doing, or their hosting software will.  

*	should be easy to do both client and server. Ideal solution balances
both (delegation for simpler servers)?
*	standards MUST be programmer-friendly

Decisions

*	HTTP vs DNS

*	DNS (SRV, TXT, etc) precludes JavaScript clients (as of 2006-2012),
so rejected. HTTP instead.

*	JSON vs XML

*	Per assumption above, we needed to pick at least one as required.
We chose JSON.  If both parties advertise (via HTTP headers) that they
prefer XML, that's fine.  JSON is easier for JavaScript clients, as one
advantage.  It's also simpler to read on the page (per the complexity
argument).  But both are small arguments and not worth arguing about.  At
the end of the day a decision had to be made, and it was.

*	HTTP-ish is more proper, but viewed as too hard for servers to route
(routing on headers, rather than request paths) and more importantly too
hard for clients to send (setting headers).
*	well-known URLs (like /favicon.ico) are gross, though.
*	Decision: use a well-known URL.
*	We defined RFC 5785 first instead, to make using a well-known path
less offensive.

*	Two requests: clients first fetch /.well-known/host-meta (to find
where to do a webfinger query), then fetch that.

*	PRO: the host-meta document can be a static file, which makes
delegation to other webfinger service providers easier for custom domains.
*	CON: twice the latency, especially for mobile
*	CON: extra client complexity

*	One request: clients just do a query immediately to
/.well-known/webfinger, without consulting host-meta.

*	PRO: half the latency
*	PRO: less client complexity
*	CON: service providers may need to reverse-proxy the query to the
right backend.
*	CON: harder for small domain names with static webservers to
delegate.

*	Decision: Just one HTTP requests, because we care more about client
simplicity than server simplicity.

*	HTTPS-only:

*	PRO: secure

*	HTTPS-recommended:

*	CON: added client complexity.  But at least good clients can
opportunistically fetch both in parallel and only use HTTP if they're
feeling trusting, once they see the HTTPS one fails. If HTTPS succeeds, no
added latency.
*	PRO: easier 

*	Decision: HTTPS-recommended.  Clients may choose to only do HTTPS,
as can servers, which means in practice almost all servers will probably
only be HTTPS.
*	Debate: this seems inconsistent with our policy of caring about
clients and simplicity more than servers.  And it seems like a failure to
decide, since we say both are optional for either party, counter to the
assumption above that specs need requirements for either client or server.
*

---

From: Dick Hardt <[email-masked]>
Date: Tue, 27 Nov 2012 21:03:47 -0800

Let's be brave and say HTTPS-only.

Requiring HTTPS enabled OAuth 2.0 to be MUCH simpler than OAuth 1.0 (yes, a little apples and oranges comparison, but there was a similar requirement conversation that had the same goal of pushing complexity to the server from the client -- it also simplifies the security model)

-- Dick

---

From: Mike Jones <[email-masked]>
Date: Wed, 28 Nov 2012 05:18:31 +0000

+1

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Tuesday, November 27, 2012 9:04 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [apps-discuss] Webfinger goals doc

-- Dick

On Nov 27, 2012, at 6:17 PM, Brad Fitzpatrick <[email-masked]<mailto:[email-masked]>> wrote:

https://docs.google.com/document/d/1Yr00Tr5d71-E6x7VDtmEaC48SendGWQe7XcY99pjQWs/edit#<https://docs.google.com/document/d/1Yr00Tr5d71-E6x7VDtmEaC48SendGWQe7XcY99pjQWs/edit>

- Brad

Requirements

  *   given just a string that looks like "[email-masked]<mailto:[email-masked]>", find a machine-readable metadata document.

     *   background: since the death of the "finger" protocol (from which webfinger gets its name), email-looking identifiers like "[email-masked]<mailto:[email-masked]>" have been write-only: you can email it (maybe, if it speaks SMTP), but you can't do any read/discovery operations on it.  You can't find its supported or preferred protocols, its name, its avatar, its public key, its identity/social/blog server, etc.
     *   the format of the identifier matters because people ("regular users") effortlessly identify with their email addresses, and already use them for sharing outside (and inside) of social networks

        *   corollary: WebFinger is not about doing discovery on URLs or URIs or IRIs or XRIs or any other "dorky" identifier.  Webfinger is about doing a discovery (read) operation on something a non-technical user would write on a napkin or give you on a business card.

Assumptions

  *   the string "[email-masked]<mailto:[email-masked]>" is NOT necessarily an email address, even though most people today associate it with an email address.

     *   corollary: the "acct:" URI scheme and draft-ietf-appsawg-acct-uri-01 etc

     *   corollary: value simplicity wherever possible, even if it means some things are harder or not possible for some parties.
     *   i.e. we'd rather have a 3 page spec that makes 90% of people happy rather than a 30 page spec that makes 95% of people happy, especially if such a smaller spec means a much improved chance of adoption.

     *   i.e. there needs to always be an intersection of features in the spec that both parties support.  e.g. can't have both clients and servers decide to only speak

     *   ... and those that do own their own domain name will mostly want to delegate management of their webfinger profiles or will know what they're doing and therefore don't need to be catered to.
     *   further assumption: most will be running Wordpress or some such software already.
     *   corollary: we don't have to cater to this small audience much.. they'll know what they're doing, or their hosting software will.

Decisions

  *   HTTP vs DNS

  *   JSON vs XML

     *   Per assumption above, we needed to pick at least one as required.  We chose JSON.  If both parties advertise (via HTTP headers) that they prefer XML, that's fine.  JSON is easier for JavaScript clients, as one advantage.  It's also simpler to read on the page (per the complexity argument).  But both are small arguments and not worth arguing about.  At the end of the day a decision had to be made, and it was.

        *   PRO: half the latency

     *   HTTPS-only:

        *   PRO: secure

     *   HTTPS-recommended:

        *   CON: added client complexity.  But at least good clients can opportunistically fetch both in parallel and only use HTTP if they're feeling trusting, once they see the HTTPS one fails. If HTTPS succeeds, no added latency.
        *   PRO: easier

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Nov 2012 03:34:31 -0500

Dick,

Here's my list of reasons why we should not mandate HTTPS:

1) TLS certificates are difficult to deploy by many

2) Many hosting providers do not support TLS because they do not support the
relatively new SNI extensions for TLS (even my own server did not support
SNI until recently and some deployed browsers still do not)

3) TLS certificates cost more money than the domain name.  This is a serious
issue for many, especially in developing countries.  Few people support
DNSSEC and RFC 6698.  If the world supported DNSSEC and people could create
self-signed certificates, TLS could be widely embraced by everyone, I
suspect.

4) If everything I'm sharing via WF is accessible via HTTP, what's the point
of protecting the WF query with HTTPS?  It definitely makes sense for OpenID
or other sensitive services, but not for more "public" applications like
"where's Paul's blog" and "where's Paul's avatar"?

Are there encryption restrictions in some countries that make TLS illegal?
If so, we could add that as reason #5.

All that said, I don't care if it was mandated, but I just don't see the
reason for it in some instances and I am concerned that it will limit
deployment of the service.

If we could get the world to implement DNSSEC and RFC 6698. problems solved.
By the time that is done, SNI issues will be long gone, too.

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dick Hardt
Sent: Wednesday, November 28, 2012 12:04 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [apps-discuss] Webfinger goals doc

Requiring HTTPS enabled OAuth 2.0 to be MUCH simpler than OAuth 1.0 (yes, a
little apples and oranges comparison, but there was a similar requirement
conversation that had the same goal of pushing complexity to the server from
the client -- it also simplifies the security model)

-- Dick

- Brad

Requirements

Assumptions

Decisions

*	HTTP vs DNS

*	JSON vs XML

*	PRO: half the latency

*	HTTPS-only:

*	PRO: secure

*	HTTPS-recommended:

---

From: Sandeep Shetty <[email-masked]>
Date: Wed, 28 Nov 2012 16:04:08 +0530

On Wed, Nov 28, 2012 at 9:07 AM, Brad Fitzpatrick <[email-masked]> wrote:
> Let it serve as a FAQ for newcomers then, like my explaining earlier today
> why we didn't lean more HTTPish.

Thanks Brad & Blaine for putting this together. It's very helpful for
newbies to WebFinger like me to begin to understand the constraints
and trade-offs made. If only all specs came with a doc like this :)

-- 
Sandeep Shetty

---

From: John Bradley <[email-masked]>
Date: Wed, 28 Nov 2012 10:40:31 -0300

Yes, we put that language in SWD.  That needs to be in the WF spec as well.

John
On 2012-11-28, at 7:54 AM, Ben Laurie <[email-masked]> wrote:

> On 28 November 2012 05:28, Brad Fitzpatrick <[email-masked]> wrote:
>> I'm +1 on HTTPS-only too.  I plan to run my own webfinger server, too, and I
>> recognize it'll be more pain since my personal domain doesn't have certs or
>> an https server running already, but I'm fine with some inconvenience in
>> exchange for security and simpler clients.
> 
> Please also mention that non-browser clients need to actually check
> the end certificate is for the right domain :-)
> 
>> 
>> 
>> On Tue, Nov 27, 2012 at 9:18 PM, Mike Jones <[email-masked]>
>> wrote:
>>> 
>>> +1
>>> 
>>> 
>>> 
>>> Requiring HTTPS enabled OAuth 2.0 to be MUCH simpler than OAuth 1.0 (yes,
>>> a little apples and oranges comparison, but there was a similar requirement
>>> The doc is open for comments.  I'll try to keep the doc edited and
>>> neutral.  It outlines requirements (aka goals for webfinger), assumptions,
>>> and decisions with pros & cons for each and what decision was ultimately
>>> made and why.
>>> 
>>> 
>>> 
>>> background: since the death of the “finger” protocol (from which webfinger
>>> gets its name), email-looking identifiers like “[email-masked]” have been
>>> write-only: you can email it (maybe, if it speaks SMTP), but you can’t do
>>> any read/discovery operations on it.  You can’t find its supported or
>>> preferred protocols, its name, its avatar, its public key, its
>>> identity/social/blog server, etc.
>>> the format of the identifier matters because people (“regular users”)
>>> effortlessly identify with their email addresses, and already use them for
>>> sharing outside (and inside) of social networks
>>> 
>>> corollary: WebFinger is not about doing discovery on URLs or URIs or IRIs
>>> or XRIs or any other “dorky” identifier.  Webfinger is about doing a
>>> delegation to webfinger-as-a-service by larger providers from self-hosted
>>> or organisational domains is possible (cf. DNS NS records)
>>> the string “[email-masked]” is NOT necessarily an email address, even
>>> though most people today associate it with an email address.
>>> 
>>> corollary: value simplicity wherever possible, even if it means some
>>> i.e. we’d rather have a 3 page spec that makes 90% of people happy rather
>>> than a 30 page spec that makes 95% of people happy, especially if such a
>>> smaller spec means a much improved chance of adoption.
>>> 
>>> obvious, but: optional parts in specs need to be optional for only one
>>> party (client or server) and required for the other.
>>> 
>>> i.e. there needs to always be an intersection of features in the spec that
>>> both parties support.  e.g. can’t have both clients and servers decide to
>>> only speak
>>> 
>>> … and those that do own their own domain name will mostly want to delegate
>>> management of their webfinger profiles or will know what they’re doing and
>>> therefore don’t need to be catered to.
>>> corollary: we don’t have to cater to this small audience much.. they’ll
>>> know what they’re doing, or their hosting software will.
>>> 
>>> Per assumption above, we needed to pick at least one as required.  We
>>> chose JSON.  If both parties advertise (via HTTP headers) that they prefer
>>> XML, that’s fine.  JSON is easier for JavaScript clients, as one advantage.
>>> It’s also simpler to read on the page (per the complexity argument).  But
>>> both are small arguments and not worth arguing about.  At the end of the day
>>> a decision had to be made, and it was.
>>> 
>>> HTTP-ish is more proper, but viewed as too hard for servers to route
>>> PRO: the host-meta document can be a static file, which makes delegation
>>> to other webfinger service providers easier for custom domains.
>>> One request: clients just do a query immediately to
>>> CON: added client complexity.  But at least good clients can
>>> opportunistically fetch both in parallel and only use HTTP if they’re
>>> Decision: HTTPS-recommended.  Clients may choose to only do HTTPS, as can
>>> servers, which means in practice almost all servers will probably only be
>>> HTTPS.
>>> Debate: this seems inconsistent with our policy of caring about clients
>>> and simplicity more than servers.  And it seems like a failure to decide,
>>> since we say both are optional for either party, counter to the assumption
>>> above that specs need requirements for either client or server.
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 28 Nov 2012 10:50:28 -0300

I agree that TLS will be hard to impossible for many people off their main domain.  That was one of the reasons for having a subdomain so that you could delegate it via DNS to a server that can support it.

That idea seems to be dead however. 

The question is if publishing a WF document that can't safely support a number of protocols is:
a) worth it.
b) may encourage many RP to ignore the TLS requirement for some protocols and create unmanageable security issues.

Letting clients do the wrong thing is hard to put back in the box from experience.

The safest thing is to only allow the WF service over TLS.

I know that in opposition to the social linking use case.  That is one of the problems of trying to solve two similar but not the same problems with one solution.

This is an important issue and we should close on it one way or the other.   I hate having to have clients try https and fall back to http for some relations.   I see it going very wrong sometimes.

John B.

On 2012-11-28, at 5:41 AM, Joseph Anthony Pasquale Holsten <[email-masked]> wrote:

> Big folks will have no problem. Privileged folks with vanity domains like myself will get over it.
> 
> The main use case it screws up is delegation, since you can't bootstrap from a cheap domain.
> 
> On 2012-11-28, at 00:34 , "Paul E. Jones" <[email-masked]> wrote:
> 
>> Dick,
>> 
>> Here’s my list of reasons why we should not mandate HTTPS:
>> 2) Many hosting providers do not support TLS because they do not support the relatively new SNI extensions for TLS (even my own server did not support SNI until recently and some deployed browsers still do not)
>> 3) TLS certificates cost more money than the domain name.  This is a serious issue for many, especially in developing countries.  Few people support DNSSEC and RFC 6698.  If the world supported DNSSEC and people could create self-signed certificates, TLS could be widely embraced by everyone, I suspect.
>> 4) If everything I’m sharing via WF is accessible via HTTP, what’s the point of protecting the WF query with HTTPS?  It definitely makes sense for OpenID or other sensitive services, but not for more “public” applications like “where’s Paul’s blog” and “where’s Paul’s avatar”?
>> 
>> Are there encryption restrictions in some countries that make TLS illegal?  If so, we could add that as reason #5.
>> 
>> All that said, I don’t care if it was mandated, but I just don’t see the reason for it in some instances and I am concerned that it will limit deployment of the service.
>> 
>> If we could get the world to implement DNSSEC and RFC 6698… problems solved.  By the time that is done, SNI issues will be long gone, too.
>> 
>> Paul
>> 
>> 	• given just a string that looks like “[email-masked]”, find a machine-readable metadata document.
>> 		• background: since the death of the “finger” protocol (from which webfinger gets its name), email-looking identifiers like “[email-masked]” have been write-only: you can email it (maybe, if it speaks SMTP), but you can’t do any read/discovery operations on it.  You can’t find its supported or preferred protocols, its name, its avatar, its public key, its identity/social/blog server, etc.
>> 		• the format of the identifier matters because people (“regular users”) effortlessly identify with their email addresses, and already use them for sharing outside (and inside) of social networks
>> 			• corollary: WebFinger is not about doing discovery on URLs or URIs or IRIs or XRIs or any other “dorky” identifier.  Webfinger is about doing a discovery (read) operation on something a non-technical user would write on a napkin or give you on a business card.
>> 	• clients can be implemented in browsers in JavaScript
>> 		• corollary: CORS shout-out in spec
>> 		• corollary: no DNS component
>> 	• delegation to webfinger-as-a-service by larger providers from self-hosted or organisational domains is possible (cf. DNS NS records)
>> 	• latency of updates must be low (unlike DNS)
>> 	• no service provider (no company) is special-cased.
>> Assumptions
>> 
>> 
>> 	• the string “[email-masked]” is NOT necessarily an email address, even though most people today associate it with an email address.
>> 		• corollary: the “acct:” URI scheme and draft-ietf-appsawg-acct-uri-01 etc
>> 	• complexity in specs leads to few and/or poor implementations and ultimately hinders adoption
>> 		• corollary: value simplicity wherever possible, even if it means some things are harder or not possible for some parties.
>> 		• i.e. we’d rather have a 3 page spec that makes 90% of people happy rather than a 30 page spec that makes 95% of people happy, especially if such a smaller spec means a much improved chance of adoption.
>> 	• obvious, but: optional parts in specs need to be optional for only one party (client or server) and required for the other.
>> 		• i.e. there needs to always be an intersection of features in the spec that both parties support.  e.g. can’t have both clients and servers decide to only speak
>> 	• there will be more clients than servers
>> 		• corollary: it should be easier to write/run a client than a server
>> 	• few users own their own domain name and will run their own identity server
>> 		• … and those that do own their own domain name will mostly want to delegate management of their webfinger profiles or will know what they’re doing and therefore don’t need to be catered to.
>> 		• further assumption: most will be running Wordpress or some such software already.
>> 		• corollary: we don’t have to cater to this small audience much.. they’ll know what they’re doing, or their hosting software will.  
>> 	• should be easy to do both client and server. Ideal solution balances both (delegation for simpler servers)?
>> 	• standards MUST be programmer-friendly
>> Decisions
>> 
>> 
>> 	• HTTP vs DNS
>> 		• DNS (SRV, TXT, etc) precludes JavaScript clients (as of 2006-2012), so rejected. HTTP instead.
>> 	• JSON vs XML
>> 		• Per assumption above, we needed to pick at least one as required.  We chose JSON.  If both parties advertise (via HTTP headers) that they prefer XML, that’s fine.  JSON is easier for JavaScript clients, as one advantage.  It’s also simpler to read on the page (per the complexity argument).  But both are small arguments and not worth arguing about.  At the end of the day a decision had to be made, and it was.
>> 	• HTTP-ish (Accept / Link headers, etc) vs well-known path
>> 
>> 		• HTTP-ish is more proper, but viewed as too hard for servers to route (routing on headers, rather than request paths) and more importantly too hard for clients to send (setting headers).
>> 		• well-known URLs (like /favicon.ico) are gross, though.
>> 		• Decision: use a well-known URL.
>> 		• We defined RFC 5785 first instead, to make using a well-known path less offensive.
>> 	• One HTTP request vs two.
>> 		• Two requests: clients first fetch /.well-known/host-meta (to find where to do a webfinger query), then fetch that.
>> 			• PRO: the host-meta document can be a static file, which makes delegation to other webfinger service providers easier for custom domains.
>> 			• CON: twice the latency, especially for mobile
>> 			• CON: extra client complexity
>> 		• One request: clients just do a query immediately to /.well-known/webfinger, without consulting host-meta.
>> 			• PRO: half the latency
>> 			• PRO: less client complexity
>> 			• CON: service providers may need to reverse-proxy the query to the right backend.
>> 			• CON: harder for small domain names with static webservers to delegate.
>> 		• Decision: Just one HTTP requests, because we care more about client simplicity than server simplicity.
>> 	• HTTPS-only vs HTTPS-recommended
>> 		• HTTPS-only:
>> 			• PRO: secure
>> 			• PRO: simpler for clients (one round-trip)
>> 			• CON: hard for some servers to setup (config, certs, etc)
>> 		• HTTPS-recommended:
>> 			• CON: added client complexity.  But at least good clients can opportunistically fetch both in parallel and only use HTTP if they’re feeling trusting, once they see the HTTPS one fails. If HTTPS succeeds, no added latency.
>> 			• PRO: easier
>> 		• Decision: HTTPS-recommended.  Clients may choose to only do HTTPS, as can servers, which means in practice almost all servers will probably only be HTTPS.
>> 		• Debate: this seems inconsistent with our policy of caring about clients and simplicity more than servers.  And it seems like a failure to decide, since we say both are optional for either party, counter to the assumption above that specs need requirements for either client or server.
>> 		•  
>> 
>

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 28 Nov 2012 14:58:53 +0100

On 28 November 2012 14:50, John Bradley <[email-masked]> wrote:

> I agree that TLS will be hard to impossible for many people off their main
> domain.  That was one of the reasons for having a subdomain so that you
> could delegate it via DNS to a server that can support it.
>
> I know that in opposition to the social linking use case.  That is one of
> the problems of trying to solve two similar but not the same problems with
> one solution.
>
> This is an important issue and we should close on it one way or the other.
>   I hate having to have clients try https and fall back to http for some
> relations.   I see it going very wrong sometimes.
>

If HTTPS is considered a MUST, could webfinger work in practice with https
and a self signed certificate?

> >> 2) Many hosting providers do not support TLS because they do not
> support the relatively new SNI extensions for TLS (even my own server did
> not support SNI until recently and some deployed browsers still do not)
> >> 3) TLS certificates cost more money than the domain name.  This is a
> serious issue for many, especially in developing countries.  Few people
> support DNSSEC and RFC 6698.  If the world supported DNSSEC and people
> could create self-signed certificates, TLS could be widely embraced by
> everyone, I suspect.
> >> 4) If everything I’m sharing via WF is accessible via HTTP, what’s the
> point of protecting the WF query with HTTPS?  It definitely makes sense for
> OpenID or other sensitive services, but not for more “public” applications
> like “where’s Paul’s blog” and “where’s Paul’s avatar”?
> >>
> >> Are there encryption restrictions in some countries that make TLS
> illegal?  If so, we could add that as reason #5.
> >>
> >> All that said, I don’t care if it was mandated, but I just don’t see
> the reason for it in some instances and I am concerned that it will limit
> >> If we could get the world to implement DNSSEC and RFC 6698… problems
> solved.  By the time that is done, SNI issues will be long gone, too.
> >>
> >> Paul
> >>
> >> From: [email-masked] [mailto:
> [email-masked]] On Behalf Of Dick Hardt
> >> Requiring HTTPS enabled OAuth 2.0 to be MUCH simpler than OAuth 1.0
> (yes, a little apples and oranges comparison, but there was a similar
> requirement conversation that had the same goal of pushing complexity to
> the server from the client -- it also simplifies the security model)
> >>
> >> -- Dick
> >>
> >> I just had a chat with Blaine after his recent "I'm out!" email.  I
> don't think he's actually out--- he's been working on WebFinger for as long
> as I have and cares a lot about it.  I think he was just grumpy about the
> >> My apologies if you don't like the document's medium or fluidity, but
> it's the tool I have to work with, and better than nothing.  If you object
> to the fluidity and want something concrete to reply to in email, I've
> snapshotted the document to http://goo.gl/fTMC1 but I won't accept
> comments or make changes there.  Use whatever mechanism you prefer.
> >>
> >> - Brad
> >>
> >>
> >>              • background: since the death of the “finger” protocol
> (from which webfinger gets its name), email-looking identifiers like “
> [email-masked]” have been write-only: you can email it (maybe, if it
> speaks SMTP), but you can’t do any read/discovery operations on it.  You
> can’t find its supported or preferred protocols, its name, its avatar, its
> public key, its identity/social/blog server, etc.
> >>              • the format of the identifier matters because people
> (“regular users”) effortlessly identify with their email addresses, and
> already use them for sharing outside (and inside) of social networks
> >>                      • corollary: WebFinger is not about doing
> discovery on URLs or URIs or IRIs or XRIs or any other “dorky” identifier.
>  Webfinger is about doing a discovery (read) operation on something a
> non-technical user would write on a napkin or give you on a business card.
> >>      • delegation to webfinger-as-a-service by larger providers from
> >>      • the string “[email-masked]” is NOT necessarily an email address,
> even though most people today associate it with an email address.
> >>              • corollary: value simplicity wherever possible, even if
> it means some things are harder or not possible for some parties.
> >>              • i.e. we’d rather have a 3 page spec that makes 90% of
> people happy rather than a 30 page spec that makes 95% of people happy,
> especially if such a smaller spec means a much improved chance of adoption.
> >>      • obvious, but: optional parts in specs need to be optional for
> only one party (client or server) and required for the other.
> >>              • i.e. there needs to always be an intersection of
> features in the spec that both parties support.  e.g. can’t have both
> clients and servers decide to only speak
> >>              • … and those that do own their own domain name will
> mostly want to delegate management of their webfinger profiles or will know
> what they’re doing and therefore don’t need to be catered to.
> >>              • corollary: we don’t have to cater to this small audience
> much.. they’ll know what they’re doing, or their hosting software will.
> >>      • should be easy to do both client and server. Ideal solution
> balances both (delegation for simpler servers)?
> >>              • Per assumption above, we needed to pick at least one as
> required.  We chose JSON.  If both parties advertise (via HTTP headers)
> that they prefer XML, that’s fine.  JSON is easier for JavaScript clients,
> as one advantage.  It’s also simpler to read on the page (per the
> complexity argument).  But both are small arguments and not worth arguing
> about.  At the end of the day a decision had to be made, and it was.
> >>              • HTTP-ish is more proper, but viewed as too hard for
> servers to route (routing on headers, rather than request paths) and more
> importantly too hard for clients to send (setting headers).
> >>              • Two requests: clients first fetch /.well-known/host-meta
> (to find where to do a webfinger query), then fetch that.
> >>                      • PRO: the host-meta document can be a static
> file, which makes delegation to other webfinger service providers easier
> for custom domains.
> >>              • One request: clients just do a query immediately to
> >>              • Decision: Just one HTTP requests, because we care more
> about client simplicity than server simplicity.
> >>                      • CON: added client complexity.  But at least good
> clients can opportunistically fetch both in parallel and only use HTTP if
> they’re feeling trusting, once they see the HTTPS one fails. If HTTPS
> succeeds, no added latency.
> >>                      • PRO: easier
> >>              • Decision: HTTPS-recommended.  Clients may choose to only
> do HTTPS, as can servers, which means in practice almost all servers will
> probably only be HTTPS.
> >>              • Debate: this seems inconsistent with our policy of
> caring about clients and simplicity more than servers.  And it seems like a
> failure to decide, since we say both are optional for either party, counter
> to the assumption above that specs need requirements for either client or
> server.
> >>              •
> >>
> >
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 Nov 2012 06:56:41 -0800

> Let's be brave and say HTTPS-only.

-1. As a security geek, I would love to see everything run under encryption and integrity assurance. As a security operations geek, I assure you that the web PKI is no up to the task for this.

If the information being provided by Webfinger *at a particular site* needs to have privacy and integrity assurance, then that site should run the Webfinger part of its web service under HTTPS. Just like it should for any other data from the site.

--Paul Hoffman

---

From: Dick Hardt <[email-masked]>
Date: Wed, 28 Nov 2012 07:24:07 -0800

> If the information being provided by Webfinger *at a particular site* needs to have privacy and integrity assurance, then that site should run the Webfinger part of its web service under HTTPS. Jus…

The challenge then is ensuring implementors correctly decide which information needs integrity assurance and which don't. As a security geek, I would imagine you appreciate that challenge. To an uninformed implementor, something that seems innocuous can have dramatic consequences.

Having WF run over HTTPS simplifies clients, and I would argue simplifies server deployment since there are no decisions to make. It MUST be HTTPS.

-- Dick

---

From: Ben Laurie <[email-masked]>
Date: Wed, 28 Nov 2012 10:54:38 +0000

---

From: Brad Fitzpatrick <[email-masked]>
Date: Tue, 27 Nov 2012 18:17:45 -0800

My apologies if you don't like the document's medium or fluidity, but it's
the tool I have to work with, and better than nothing.  If you object to
the fluidity and want something concrete to reply to in email, I've
snapshotted the document to http://goo.gl/fTMC1 but I won't accept comments
or make changes there.  Use whatever mechanism you prefer.

- Brad

*

   - given just a string that looks like “[email-masked]”, find a
   machine-readable metadata document.
      - background: since the death of the “finger” protocol (from which
      webfinger gets its name), email-looking identifiers like “
      [email-masked]” have been write-only: you can email it (maybe, if it
      speaks SMTP), but you can’t do any read/discovery operations on it.  You
      can’t find its supported or preferred protocols, its name, its
avatar, its
      public key, its identity/social/blog server, etc.
      - the format of the identifier matters because people (“regular
      users”) effortlessly identify with their email addresses, and already use
      them for sharing outside (and inside) of social networks
         - corollary: WebFinger is not about doing discovery on URLs or
         URIs or IRIs or XRIs or any other “dorky” identifier.
Webfinger is about
         doing a discovery (read) operation on something a
non-technical user would
         write on a napkin or give you on a business card.
      - clients can be implemented in browsers in JavaScript
      - corollary: CORS shout-out in spec
      - corollary: no DNS component
   - delegation to webfinger-as-a-service by larger providers from
   self-hosted or organisational domains is possible (cf. DNS NS records)
   - latency of updates must be low (unlike DNS)
   - no service provider (no company) is special-cased.

Assumptions

   - the string “[email-masked]” is NOT necessarily an email address, even
   though most people today associate it with an email address.
      - corollary: the “acct:” URI scheme and
      draft-ietf-appsawg-acct-uri-01 etc
   - complexity in specs leads to few and/or poor implementations and
   ultimately hinders adoption
      - corollary: value simplicity wherever possible, even if it means
      some things are harder or not possible for some parties.
      - i.e. we’d rather have a 3 page spec that makes 90% of people happy
      rather than a 30 page spec that makes 95% of people happy, especially if
      such a smaller spec means a much improved chance of adoption.
   - obvious, but: optional parts in specs need to be optional for only one
   party (client or server) and required for the other.
      - i.e. there needs to always be an intersection of features in the
      spec that both parties support.  e.g. can’t have both clients and servers
      decide to only speak
   - there will be more clients than servers
      - corollary: it should be easier to write/run a client than a server
   - few users own their own domain name and will run their own identity
   server
      - … and those that do own their own domain name will mostly want to
      delegate management of their webfinger profiles or will know what they’re
      doing and therefore don’t need to be catered to.
      - further assumption: most will be running Wordpress or some such
      software already.
      - corollary: we don’t have to cater to this small audience much..
      they’ll know what they’re doing, or their hosting software will.
   - should be easy to do both client and server. Ideal solution balances
   both (delegation for simpler servers)?
   - standards MUST be programmer-friendly

Decisions

   - HTTP vs DNS
      - DNS (SRV, TXT, etc) precludes JavaScript clients (as of 2006-2012),
      so rejected. HTTP instead.
   - JSON vs XML
      - Per assumption above, we needed to pick at least one as required.
       We chose JSON.  If both parties advertise (via HTTP headers) that they
      prefer XML, that’s fine.  JSON is easier for JavaScript clients, as one
      advantage.  It’s also simpler to read on the page (per the complexity
      argument).  But both are small arguments and not worth arguing about.  At
      the end of the day a decision had to be made, and it was.
   - HTTP-ish (Accept / Link headers, etc) vs well-known path

   - HTTP-ish is more proper, but viewed as too hard for servers to route
      (routing on headers, rather than request paths) and more importantly too
      hard for clients to send (setting headers).
      - well-known URLs (like /favicon.ico) are gross, though.
      - Decision: use a well-known URL.
      - We defined RFC 5785 first instead, to make using a well-known path
      less offensive.
   - One HTTP request vs two.
      - Two requests: clients first fetch /.well-known/host-meta (to find
      where to do a webfinger query), then fetch that.
         - PRO: the host-meta document can be a static file, which makes
         delegation to other webfinger service providers easier for
custom domains.
         - CON: twice the latency, especially for mobile
         - CON: extra client complexity
      - One request: clients just do a query immediately to
      /.well-known/webfinger, without consulting host-meta.
         - PRO: half the latency
         - PRO: less client complexity
         - CON: service providers may need to reverse-proxy the query to
         the right backend.
         - CON: harder for small domain names with static webservers to
         delegate.
      - Decision: Just one HTTP requests, because we care more about client
      simplicity than server simplicity.
   - HTTPS-only vs HTTPS-recommended
      - HTTPS-only:
         - PRO: secure
         - PRO: simpler for clients (one round-trip)
         - CON: hard for some servers to setup (config, certs, etc)
      - HTTPS-recommended:
         - CON: added client complexity.  But at least good clients can
         opportunistically fetch both in parallel and only use HTTP if they’re
         feeling trusting, once they see the HTTPS one fails. If HTTPS
succeeds, no
         added latency.
         - PRO: easier
      - Decision: HTTPS-recommended.  Clients may choose to only do HTTPS,
      as can servers, which means in practice almost all servers will probably
      only be HTTPS.
      - Debate: this seems inconsistent with our policy of caring about
      clients and simplicity more than servers.  And it seems like a failure to
      decide, since we say both are optional for either party, counter to the
      assumption above that specs need requirements for either client or server.
      -

*

---

From: Brad Fitzpatrick <[email-masked]>
Date: Tue, 27 Nov 2012 19:37:10 -0800

On Tue, Nov 27, 2012 at 7:32 PM, Paul E. Jones <[email-masked]>wrote:

> I’m confused.  Haven’t we reached a decision on every point?
>

Maybe?  But we haven't shipped anything.

But I didn't write it to influence decisions, just to record them.

> At this point, it seems like it’s largely an exercise of editorial
> refinement.
>

Let it serve as a FAQ for newcomers then, like my explaining earlier today
why we didn't lean more HTTPish. That and Blaine's confusion motivated
writing the doc, which I think will be more useful than it was painful.  I
like exercises.

> Blaine, you definitely were not ignored.  I’m not playing dictator, either
> ;-)  Your input has been invaluable, though I understand some things you
> wanted (most notably the ability to have an absolutely static site with
> flat files and no Apache re-writing) are not in the current spec.  However,
> it’s definitely far simpler than before.  The only sore point was the
> “subdomain” and it appears this is to be removed by consensus. (I’m still
> trying to understand if that’s the case.)
>

I'm likewise curious on that.  I haven't heard any pro-subdomain arguments
lately.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Tue, 27 Nov 2012 21:28:07 -0800

I'm +1 on HTTPS-only too.  I plan to run my own webfinger server, too, and
I recognize it'll be more pain since my personal domain doesn't have certs
or an https server running already, but I'm fine with some inconvenience in
exchange for security and simpler clients.

On Tue, Nov 27, 2012 at 9:18 PM, Mike Jones <[email-masked]>wrote:

>  +1****
>
> ** **
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *Dick Hardt
> *Sent:* Tuesday, November 27, 2012 9:04 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [apps-discuss] Webfinger goals doc****
>
> ** **
>
> Let's be brave and say HTTPS-only.****
>
> ** **
>
> conversation that had the same goal of pushing complexity to the server
> from the client -- it also simplifies the security model)****
>
> ** **
>
> -- Dick****
>
> ** **
>
> ****
> ****
> process, speed, and confused about goals and decisions.****
>
> ** **
>
> together to clarify thought processes and decisions:****
>
> ** **
>
>
> ****
> ** **
> made and why.****
> ** **
> The decisions are I'm sure subject to change, but hopefully not too much.*
> ***
>
> ** **
>
> Let me know what I missed.****
>
> ** **
>
> comments or make changes there.  Use whatever mechanism you prefer.****
>
> ** **
>
> - Brad****
>
> ** **
>
> ** **
>
> Copy of doc for posterity:****
>
> ** **
>
> *WebFinger Goals, Assumptions, and Decisions (SNAPSHOT1)*****
>
> *aka background reading on understanding the WebFinger spec*****
> Requirements****
>
> ** **
>
>    machine-readable metadata document.****
>
>
>       public key, its identity/social/blog server, etc.****
>       them for sharing outside (and inside) of social networks****
>
>
>     - corollary: WebFinger is not about doing discovery on URLs or URIs
>          or IRIs or XRIs or any other “dorky” identifier.  Webfinger is about doing
>          a discovery (read) operation on something a non-technical user would write
>          on a napkin or give you on a business card.****
>
>
>    - clients can be implemented in browsers in JavaScript****
>
>
>     - corollary: CORS shout-out in spec****
>       - corollary: no DNS component****
>
>
>    self-hosted or organisational domains is possible (cf. DNS NS records)*
>    ***
>    - latency of updates must be low (unlike DNS)****
>    - no service provider (no company) is special-cased.****
>
> Assumptions****
>
> ** **
>
>    though most people today associate it with an email address.****
>
>
>       draft-ietf-appsawg-acct-uri-01 etc****
>
>
>    ultimately hinders adoption****
>
>
>       some things are harder or not possible for some parties.****
>       - i.e. we’d rather have a 3 page spec that makes 90% of people
>       happy rather than a 30 page spec that makes 95% of people happy, especially
>       if such a smaller spec means a much improved chance of adoption.****
>
>
>    - obvious, but: optional parts in specs need to be optional for only
>    one party (client or server) and required for the other.****
>
>
>       decide to only speak****
>    - there will be more clients than servers****
>
>
>     - corollary: it should be easier to write/run a client than a server**
>       **
>
>
>    server****
>       doing and therefore don’t need to be catered to.****
>       software already.****
>       they’ll know what they’re doing, or their hosting software will.  **
>       **
>
>
>    both (delegation for simpler servers)?****
>    - standards MUST be programmer-friendly****
>
> Decisions****
>
> ** **
>
>    - HTTP vs DNS****
>
>
>       so rejected. HTTP instead.****
>
>
>    - JSON vs XML****
>
>
>       the end of the day a decision had to be made, and it was.****
>
>
>    - HTTP-ish (Accept / Link headers, etc) vs well-known path****
>
> ** **
>
>     - HTTP-ish is more proper, but viewed as too hard for servers to
>       route (routing on headers, rather than request paths) and more importantly
>       too hard for clients to send (setting headers).****
>       - well-known URLs (like /favicon.ico) are gross, though.****
>       - Decision: use a well-known URL.****
>       - We defined RFC 5785 first instead, to make using a well-known
>       path less offensive.****
>
>
>    - One HTTP request vs two.****
>
>
>       where to do a webfinger query), then fetch that.****
>
>
>          ****
>          - CON: twice the latency, especially for mobile****
>          - CON: extra client complexity****
>
>
>       /.well-known/webfinger, without consulting host-meta.****
>
>
>     - PRO: half the latency****
>          - PRO: less client complexity****
>          the right backend.****
>          delegate.****
>       simplicity than server simplicity.****
>
>
>    - HTTPS-only vs HTTPS-recommended****
>
>
>     - HTTPS-only:****
>
>
>     - PRO: secure****
>          - PRO: simpler for clients (one round-trip)****
>          - CON: hard for some servers to setup (config, certs, etc)****
>
>
>     - HTTPS-recommended:****
>
>
>          added latency.****
>          - PRO: easier ** **
>       only be HTTPS.****
>       ****
>       - ** **
>  ** **
> ** **

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 28 Nov 2012 06:50:51 -0800

On Wed, Nov 28, 2012 at 12:34 AM, Paul E. Jones <[email-masked]>wrote:

> Dick,****
>
> ** **
>
> Here’s my list of reasons why we should not mandate HTTPS:****
>

True.

> ****
>
> 2) Many hosting providers do not support TLS because they do not support
> the relatively new SNI extensions for TLS (even my own server did not
> support SNI until recently and some deployed browsers still do not)
>

I would've worried about SNI a couple years ago, but these days it's
pervasive enough that I wouldn't care.

> could create self-signed certificates, TLS could be widely embraced by

Certs are free:  http://www.startcom.org/ -- they're a root CA.

> like “where’s Paul’s blog” and “where’s Paul’s avatar”?

This is the best point.

> All that said, I don’t care if it was mandated, but I just don’t see the
> deployment of the service.****
>
> ** **
>
> solved.  By the time that is done, SNI issues will be long gone, too.****
>
> ** **
>
> Paul****
>
> ** **
>
> *Sent:* Wednesday, November 28, 2012 12:04 AM
>
>    - corollary: WebFinger is not about doing discovery on URLs or URIs or
>          IRIs or XRIs or any other “dorky” identifier.  Webfinger is about doing a
>          a napkin or give you on a business card.****
>
>
>    - corollary: the “acct:” URI scheme and draft-ietf-appsawg-acct-uri-01
>       etc****
>
>
>    - corollary: value simplicity wherever possible, even if it means some
>       things are harder or not possible for some parties.****
>    - corollary: it should be easier to write/run a client than a server***
>       *
>
>
>       hard for clients to send (setting headers).****
>          - PRO: easier ****

---

From: John Bradley <[email-masked]>
Date: Wed, 28 Nov 2012 13:23:10 -0300

Self signed certificates are a touch pointless.   They only provide integrity protection and that is not really an issue.

The problem is that you don't want to have RP mistakenly redirecting users to fake endpoints where they can be phished simply by a DNS attack on the RP.

That requires PKIX certificates.   I wish there were another practical way that didn't require that, but at the moment it about the only (I agree not super strong) way a client has to ensure it is talking to the right host.

John B.

On 2012-11-28, at 10:58 AM, Melvin Carvalho <[email-masked]> wrote:

> If HTTPS is considered a MUST, could webfinger work in practice with https and a self signed certificate?  
>  
> 
> John B.
> 
> 
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Nov 2012 11:49:01 -0500

I get a little worried about this style of security argument.

Buried in the earlier conversation we had people proposing this as a
facility that could be invoked in the browser using javascript. Next we are
talking about mandating TLS.

Given the security 'model' of Javascript is that the attacker gets to chose
the code that runs in my browser, I can't see that any WebFinger protocol
that can be implemented as client side Javascript is going to be acceptable
as a means for accessing data that is not completely public.

So what is the TLS there for?

I am quite happy to accept that maybe WebFinger should be a TLS protocol
and that it would allow more interesting possibilities. But those
possibilities would involve client authentication so that my contact info,
photo etc were only delivered to an authorized party.

If we are talking about that type of scheme, I applaud it.

But if this scheme is going to be accessible from client side javascript
then its game over. Just like the existing schemes are privacy nightmares
that are going to result in billion dollar litigation settlements down the
line, this is going to compound the problem.

I think that something like WebFinger should only run as application code
such as a browser feature or it should run in the server that the client
connects to. Trying to make something as privacy sensitive as WebFinger
work in a way that is backwards compatible with existing Javascript is
ridiculous.

So I think we should reverse the SRV decision for the express purpose of
disabling Javascript access.

On Wed, Nov 28, 2012 at 12:03 AM, Dick Hardt <[email-masked]> wrote:

> from the client -- it also simplifies the security model)
>
> -- Dick
>
>          URIs or IRIs or XRIs or any other “dorky” identifier.  Webfinger is about
>          doing a discovery (read) operation on something a non-technical user would
>       if such a smaller spec means a much improved chance of adoption.
>       - DNS (SRV, TXT, etc) precludes JavaScript clients (as of
>       2006-2012), so rejected. HTTP instead.
>    - JSON vs XML
>       path less offensive.
>       - Decision: Just one HTTP requests, because we care more about
>       client simplicity than server simplicity.
>       - Decision: HTTPS-recommended.  Clients may choose to only do
>       HTTPS, as can servers, which means in practice almost all servers will
>       probably only be HTTPS.

-- 
Website: http://hallambaker.com/

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 28 Nov 2012 11:57:59 -0500

> as a means for accessing data that is not completely public.

That's not what TLS would be for in this case, it's to protect the JS code from
getting spoofed WF information. Browsers check cert chains in TLS, so when you
access the WF service at https://example.com it confirms that it really is
example.com.

  -joe

> I am quite happy to accept that maybe WebFinger should be a TLS protocol and
> that it would allow more interesting possibilities. But those possibilities
> would involve client authentication so that my contact info, photo etc were
> only delivered to an authorized party.
>
> connects to. Trying to make something as privacy sensitive as WebFinger work
> in a way that is backwards compatible with existing Javascript is
> ridiculous.
>

--
Joe Gregorio        http://bitworking.org

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 28 Nov 2012 09:08:15 -0800

I have no opinion on whether WF should mandate TLS. However, the
discussion in this thread about the security implications of not
mandating TLS are equivocated. The assumption is that TLS can be
optional and then servers can choose which assets will be discoverable
via TLS or not based on their sensitivity. However, at the moment that
non-TLS protected HTTP is allowed, then it becomes impossible for
servers to protect sensitive data since spec-compliant libraries will
necessarily be vulnerable to TLS downgrade attacks. You can get
HTTP-only interoperability by default or TLS-downgrade-protection by
default, but not both.

What that means is that WF, by allowing HTTP-cleartext transport, is
unsuitable as a discovery mechanism for sensitive applications, such
as authorization. In particular, standards such as OpenIDConnect
should not consider WF as a possible discovery mechanism on the basis
of non-mandated TLS alone.

However, as I mentioned above, this is a choice, you can't get both
worlds. I am just speaking in the interest of making the choice clear.

-- 
--Breno

---

From: William Mills <[email-masked]>
Date: Wed, 28 Nov 2012 11:49:14 -0800 (PST)

Well said.  I believe your point about TLS being required for authentication endpoint discovery is important and absolutely correct and extremely important.

>________________________________
> From: Breno de Medeiros <[email-masked]>
>To: Joe Gregorio <[email-masked]> 
>Cc: [email-masked]; "[email-masked]" <[email-masked]> 
>Sent: Wednesday, November 28, 2012 9:08 AM

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 29 Nov 2012 09:52:50 +0900

On 2012/11/29 2:08, Breno de Medeiros wrote:
> necessarily be vulnerable to TLS downgrade attacks.

Downgrade attacks are a general issue, and are being addressed 
separately (sorry, forgot the WG/draft/RFC).

Regards,   Martin.

> You can get

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Nov 2012 00:33:59 -0500

John,

Personally, I would place a requirement in the OpenID Connect specs that
says that only TLS can be used when issuing a WF query.  This allows WF to
be used where security is important and where it's not, but ensures that
when used for OpenID Connect, security is not compromised.

Having said that, is there no visible means for the user to know with
absolute certainty when using OpenID Connect that he is interacting with his
Provider?  With OpenID 2.0, for example, I only enter my credentials in a
page that I know is my Provider and I know for certain that it is, since the
Provider page opens in a browser window that is secured with TLS.  I can
visually inspect that it's right.

Assuming OpenID Connect does the same, then even if the URL is modified in
flight, the user could see it's the wrong destination when they get there.

(Sorry for being ignorant.  I've still not read through the OpenID Connect
specs to understand how it works.  OpenID was fairly trivial to implement; I
did the Provider server implementation in an afternoon.  I was moderately
stunned by the number of documents related to OpenID Connect... so I read
none.)

Paul

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of John Bradley
> Sent: Wednesday, November 28, 2012 8:50 AM
> Cc: [email-masked] Discuss
> I agree that TLS will be hard to impossible for many people off their
> main domain.  That was one of the reasons for having a subdomain so that
> you could delegate it via DNS to a server that can support it.
> 
> b) may encourage many RP to ignore the TLS requirement for some
> protocols and create unmanageable security issues.
> 
> I know that in opposition to the social linking use case.  That is one
> of the problems of trying to solve two similar but not the same problems
> with one solution.
> 
> This is an important issue and we should close on it one way or the
> other.   I hate having to have clients try https and fall back to http
> for some relations.   I see it going very wrong sometimes.
> 
> John B.
> 
> 
> 
> >> support the relatively new SNI extensions for TLS (even my own server
> >> did not support SNI until recently and some deployed browsers still
> >> do not)
> >> 4) If everything I'm sharing via WF is accessible via HTTP, what's
> the point of protecting the WF query with HTTPS?  It definitely makes
> sense for OpenID or other sensitive services, but not for more "public"
> applications like "where's Paul's blog" and "where's Paul's avatar"?
> >>
> >> All that said, I don't care if it was mandated, but I just don't see
> the reason for it in some instances and I am concerned that it will
> limit deployment of the service.
> >>
> >> If we could get the world to implement DNSSEC and RFC 6698. problems
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Dick Hardt
> >> requirement conversation that had the same goal of pushing complexity
> >> to the server from the client -- it also simplifies the security
> >> model)
> >>
> >> -- Dick
> >>
> don't think he's actually out--- he's been working on WebFinger for as
> long as I have and cares a lot about it.  I think he was just grumpy
> about the process, speed, and confused about goals and decisions.
> >>
> neutral.  It outlines requirements (aka goals for webfinger),
> assumptions, and decisions with pros & cons for each and what decision
> was ultimately made and why.
> >>
> it's the tool I have to work with, and better than nothing.  If you
> object to the fluidity and want something concrete to reply to in email,
> I've snapshotted the document to http://goo.gl/fTMC1 but I won't accept
> >> 	. given just a string that looks like "[email-masked]", find a
> >> 		. background: since the death of the "finger" protocol (from
> which webfinger gets its name), email-looking identifiers like
> "[email-masked]" have been write-only: you can email it (maybe, if it
> speaks SMTP), but you can't do any read/discovery operations on it.  You
> can't find its supported or preferred protocols, its name, its avatar,
> its public key, its identity/social/blog server, etc.
> >> 		. the format of the identifier matters because people
> ("regular users") effortlessly identify with their email addresses, and
> >> 			. corollary: WebFinger is not about doing discovery
on
> URLs or URIs or IRIs or XRIs or any other "dorky" identifier.  Webfinger
> is about doing a discovery (read) operation on something a non-technical
> user would write on a napkin or give you on a business card.
> >> 	. clients can be implemented in browsers in JavaScript
> >> 		. corollary: CORS shout-out in spec
> >> 		. corollary: no DNS component
> >> 	. delegation to webfinger-as-a-service by larger providers from
> >> 	. latency of updates must be low (unlike DNS)
> >> 	. no service provider (no company) is special-cased.
> >> Assumptions
> >>
> >>
> >> 	. the string "[email-masked]" is NOT necessarily an email address,
> >> 		. corollary: the "acct:" URI scheme and draft-ietf-appsawg-
> acct-uri-01 etc
> >> 	. complexity in specs leads to few and/or poor implementations and
> >> 		. corollary: value simplicity wherever possible, even if it
> means some things are harder or not possible for some parties.
> >> 		. i.e. we'd rather have a 3 page spec that makes 90% of
> >> 	. obvious, but: optional parts in specs need to be optional for
> >> 		. i.e. there needs to always be an intersection of features
> in the spec that both parties support.  e.g. can't have both clients and
> servers decide to only speak
> >> 	. there will be more clients than servers
> >> 		. corollary: it should be easier to write/run a client than
> a server
> >> 	. few users own their own domain name and will run their own
> identity server
> >> 		. . and those that do own their own domain name will mostly
> want to delegate management of their webfinger profiles or will know
> what they're doing and therefore don't need to be catered to.
> >> 		. further assumption: most will be running Wordpress or some
> such software already.
> >> 		. corollary: we don't have to cater to this small audience
> much.. they'll know what they're doing, or their hosting software will.
> >> 	. should be easy to do both client and server. Ideal solution
> >> 	. standards MUST be programmer-friendly Decisions
> >>
> >>
> >> 	. HTTP vs DNS
> >> 		. DNS (SRV, TXT, etc) precludes JavaScript clients (as of
> >> 	. JSON vs XML
> >> 		. Per assumption above, we needed to pick at least one as
> that they prefer XML, that's fine.  JSON is easier for JavaScript
> clients, as one advantage.  It's also simpler to read on the page (per
> the complexity argument).  But both are small arguments and not worth
> arguing about.  At the end of the day a decision had to be made, and it
> was.
> >> 	. HTTP-ish (Accept / Link headers, etc) vs well-known path
> >>
> >> 		. HTTP-ish is more proper, but viewed as too hard for
> servers to route (routing on headers, rather than request paths) and
> more importantly too hard for clients to send (setting headers).
> >> 		. well-known URLs (like /favicon.ico) are gross, though.
> >> 		. Decision: use a well-known URL.
> >> 		. We defined RFC 5785 first instead, to make using a well-
> known path less offensive.
> >> 	. One HTTP request vs two.
> >> 		. Two requests: clients first fetch /.well-known/host-meta
> >> 			. PRO: the host-meta document can be a static file,
> which makes delegation to other webfinger service providers easier for
> custom domains.
> >> 			. CON: twice the latency, especially for mobile
> >> 			. CON: extra client complexity
> >> 		. One request: clients just do a query immediately to
> >> 			. PRO: half the latency
> >> 			. PRO: less client complexity
> >> 			. CON: service providers may need to reverse-proxy
the
> query to the right backend.
> >> 			. CON: harder for small domain names with static
> webservers to delegate.
> >> 		. Decision: Just one HTTP requests, because we care more
> >> 	. HTTPS-only vs HTTPS-recommended
> >> 		. HTTPS-only:
> >> 			. PRO: secure
> >> 			. PRO: simpler for clients (one round-trip)
> >> 			. CON: hard for some servers to setup (config,
certs,
> etc)
> >> 		. HTTPS-recommended:
> >> 			. CON: added client complexity.  But at least good
> clients can opportunistically fetch both in parallel and only use HTTP
> if they're feeling trusting, once they see the HTTPS one fails. If HTTPS
> >> 			. PRO: easier
> >> 		. Decision: HTTPS-recommended.  Clients may choose to only
> do HTTPS, as can servers, which means in practice almost all servers
> will probably only be HTTPS.
> >> 		. Debate: this seems inconsistent with our policy of caring
> about clients and simplicity more than servers.  And it seems like a
> failure to decide, since we say both are optional for either party,
> counter to the assumption above that specs need requirements for either
> client or server.
> >> 		.
> >>
> >
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Nov 2012 00:44:45 -0500

One does not need to run the server on both the HTTPS and HTTP port.  If your domain supports HTTPS, run it only on HTTPS.  Clients MUST query there first.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad Fitzpatrick
Sent: Wednesday, November 28, 2012 12:28 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [apps-discuss] Webfinger goals doc

I'm +1 on HTTPS-only too.  I plan to run my own webfinger server, too, and I recognize it'll be more pain since my personal domain doesn't have certs or an https server running already, but I'm fine with some inconvenience in exchange for security and simpler clients.

On Tue, Nov 27, 2012 at 9:18 PM, Mike Jones <[email-masked]> wrote:

+1

-- Dick

- Brad

Requirements

Assumptions

Decisions

*	HTTP vs DNS

*	JSON vs XML

*	PRO: half the latency

*	HTTPS-only:

*	PRO: secure

*	HTTPS-recommended:

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 28 Nov 2012 22:06:26 -0800

TLS downgrade attacks means that you always run a server over HTTP even
when you don't provided that the client will fall back to HTTP when HTTPS
port is unavailable. The only difference is that the attacker is doing the
HTTP hosting instead.

If the library for WF is compliant then it will accept downgrade attacks
for interoperability. Unless the spec mandates that compliant client
implementations must support configurable option to indicate if only HTTPS
is allowed (technically the inputs for WF would be an email address and
some security flag with a default value that SHOULD be modifiable) we can't
expect that compliant  WF clients will expose this configuration. And if
not we can't use WF as a building block for authentication protocols. It is
just a violation of layering if OpenIDConnect will invoke the WF client and
then try to second guess what the HTTP client that was wrapped within the
WF client did during discovery.
On Nov 28, 2012 9:44 PM, "Paul E. Jones" <[email-masked]> wrote:

> One does not need to run the server on both the HTTPS and HTTP port.  If
> your domain supports HTTPS, run it only on HTTPS.  Clients MUST query there
> first.****
>
> ** **
>
> Paul****
>
> ** **
>
> [email-masked]] *On Behalf Of *Brad Fitzpatrick
> *Sent:* Wednesday, November 28, 2012 12:28 AM
> exchange for security and simpler clients.****
>
> ** **
>
> ** **
>
> wrote:****
> ...

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Nov 2012 02:27:10 -0500

Right, I think applications that need secure transport should insist on
being able to prevent fallback to HTTP. 

From: Breno de Medeiros [mailto:[email-masked]] 
Sent: Thursday, November 29, 2012 1:06 AM
To: Paul E. Jones
Cc: [email-masked]; Brad Fitzpatrick; [email-masked]
Subject: Re: [apps-discuss] Webfinger goals doc

TLS downgrade attacks means that you always run a server over HTTP even when
you don't provided that the client will fall back to HTTP when HTTPS port is
unavailable. The only difference is that the attacker is doing the HTTP
hosting instead.

If the library for WF is compliant then it will accept downgrade attacks for
interoperability. Unless the spec mandates that compliant client
implementations must support configurable option to indicate if only HTTPS
is allowed (technically the inputs for WF would be an email address and some
security flag with a default value that SHOULD be modifiable) we can't
expect that compliant  WF clients will expose this configuration. And if not
we can't use WF as a building block for authentication protocols. It is just
a violation of layering if OpenIDConnect will invoke the WF client and then
try to second guess what the HTTP client that was wrapped within the WF
client did during discovery.

first.

Paul

On Behalf Of Brad Fitzpatrick

 

+1

-- Dick

- Brad

Requirements

Assumptions

Decisions

*	HTTP vs DNS

*	JSON vs XML

*	PRO: half the latency

*	 

...

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Nov 2012 10:58:34 -0300

I think that is downgrade attacks in TLS.

I think Breno was referring to an attacker only needing to do a DNS exploit to be successful if the discovery protocol itself falls back to HTTTP if https: is not available.

On 2012-11-28, at 9:52 PM, "Martin J. Dürst" <[email-masked]> wrote:

> Downgrade attacks are a general issue, and are being addressed separately (sorry, forgot the WG/draft/RFC).
> 
> Regards,   Martin.
> 
>> You can get

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Nov 2012 11:44:38 -0300

Yes, the problem as Breno points out is that standard WF libraries would need to understand two security contexts one for not falling back and one that is more lax.

It seems to me that WF libraries should do http: or https: only mixing them adds complication and likely security issues that will be hard to uncover.

John B.

On 2012-11-29, at 3:06 AM, Breno de Medeiros <[email-masked]> wrote:

> TLS downgrade attacks means that you always run a server over HTTP even when you don't provided that the client will fall back to HTTP when HTTPS port is unavailable. The only difference is that the attacker is doing the HTTP hosting instead.
> 
> If the library for WF is compliant then it will accept downgrade attacks for interoperability. Unless the spec mandates that compliant client implementations must support configurable option to indicate if only HTTPS is allowed (technically the inputs for WF would be an email address and some security flag with a default value that SHOULD be modifiable) we can't expect that compliant  WF clients will expose this configuration. And if not we can't use WF as a building block for authentication protocols. It is just a violation of layering if OpenIDConnect will invoke the WF client and then try to second guess what the HTTP client that was wrapped within the WF client did during discovery.
>

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 28 Nov 2012 09:25:56 -0800 (PST)

Forwarding a message I sent to apps-discuss (I was not subscribed to 
webfinger so my post bounced). I apologize for the double posting to 
apps-discuss, but I don't want to break the cc: on this thread.

I have no opinion on whether WF should mandate TLS. However, the discussion 
in this thread about the security implications of not mandating TLS are 
equivocated. The assumption is that TLS can be optional and then servers 
can choose which assets will be discoverable via TLS or not based on their 
sensitivity. However, at the moment that non-TLS protected HTTP is allowed, 
then it becomes impossible for servers to protect sensitive data since 
spec-compliant libraries will necessarily be vulnerable to TLS downgrade 
attacks. You can get HTTP-only interoperability by default or 
TLS-downgrade-protection by default, but not both.

What that means is that WF, by allowing HTTP-cleartext transport, is unsuitable 
as a discovery mechanism for sensitive applications, such as authorization. 
In particular, standards such as OpenIDConnect should not consider WF as a 
possible discovery mechanism on the basis of non-mandated TLS alone.

However, as I mentioned above, this is a choice, you can't get both worlds. 
I am just speaking in the interest of making the choice clear.

On Wednesday, November 28, 2012 7:24:07 AM UTC-8, Dick Hardt wrote:
>
>
> On Nov 28, 2012, at 6:56 AM, Paul Hoffman <[email-masked]<javascript:>> 
> wrote: 
>
> > On Nov 27, 2012, at 9:03 PM, Dick Hardt <[email-masked]<javascript:>> 
> wrote: 
> > 
> > -1. As a security geek, I would love to see everything run under 
> encryption and integrity assurance. As a security operations geek, I assure 
> you that the web PKI is no up to the task for this. 
> > 
> > If the information being provided by Webfinger *at a particular site* 
> needs to have privacy and integrity assurance, then that site should run 
> the Webfinger part of its web service under HTTPS. Just like it should for 
> any other data from the site. 
>
>
> The challenge then is ensuring implementors correctly decide which 
> information needs integrity assurance and which don't. As a security geek, 
> I would imagine you appreciate that challenge. To an uninformed 
> implementor, something that seems innocuous can have dramatic consequences. 
>
> Having WF run over HTTPS simplifies clients, and I would argue simplifies 
> server deployment since there are no decisions to make. It MUST be HTTPS. 
>
> -- Dick

---

From: t.petch <[email-masked]>
Date: Fri, 30 Nov 2012 09:58:07 +0000

----- Original Message -----
From: "Joe Gregorio" <[email-masked]>
To: "Phillip Hallam-Baker" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 28, 2012 4:57 PM
Subject: Re: [apps-discuss] Webfinger goals doc

> as a means for accessing data that is not completely public.

That's not what TLS would be for in this case, it's to protect the JS
code from
getting spoofed WF information. Browsers check cert chains in TLS, so
when you
access the WF service at https://example.com it confirms that it really
is
example.com.

<tp>
pace the quality of the check performed by the browser.

My browser (as used by the vast majority of the world) makes CRL checks
optional, as
it does warnings about invalid certificates (e.g. expired, mismatch of
name,
unable to follow to a trusted anchor, messages that most of my friends
ignore because the software manufacturer is 'trustworthy').  Not that
long ago,
it even made SSL2 and SSL3 optional (but deprecated TLS1.0).  This last
I once
pointed out to my local council who provide an Internet service for the
publid
and they assured me that their IT department
knew what they were doing.

TLS(SSL) provides a channel with a level of security that only the
ciphersuite knows to a destination that the browser has decided is
suitable.  That padlock on the screen is a figleaf for the
neuroses of those with a limited knowledge of security:-(

Tom Petch
</tp>.
  -joe