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

From: Evan Prodromou <[email-masked]>
Date: Thu, 29 Nov 2012 07:49:23 -0500

-1

It's the wrong layer. Defining library interfaces seems out of scope.

I suggest sticking this in security considerations.

Breno de Medeiros <[email-masked]> wrote:

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

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 29 Nov 2012 08:56:09 -0800

> It's the wrong layer. Defining library interfaces seems out of scope.

I don't disagree. But the conclusion from a security perspective
doesn't change. One shouldn't use WF for security applications such as
authorization with the currently proposed spec formulation.

> 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
>>
>>
>>
>> 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
>>
>>
>>
>> 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.
>>
>>
>>
>> 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
>>
>>
>>
>> On Nov 27, 2012, at 6: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.
>>
>>
>> ...

-- 
--Breno

---

From: Blaine Cook <[email-masked]>
Date: Thu, 29 Nov 2012 11:24:31 -0600

I know I said I wouldn't, but...

OpenID and other similar protocols handle the verification of domain &
ownership. Any protocol where authn/authz happen will also do this.

Isn't it safest if we assume that webfinger is for "untrusted" discovery
(like DNS, which still works, thankyouverymuch) and actions that need more
security / authentication should define that themselves?

b.

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Nov 2012 14:41:19 -0300

Blaine,

You may be right and openID should not be trying to use WF.

There was a lot of pressure put on the two groups to avoid having two discovery protocols.

As I have said several times, adding the additional requirements for security to WF may be breaking it for its original more FoF like purpose.

Connect's use case for discovery ls simply finding the IdP relationship for a identifier the user gives to a RP securely to prevent phishing.
We could extract the domain and do a simple https://  GET to the .well-known/openid-configuration.

All the other stuff in WF is extraneous to us.  Using WF to let a host provide per account delegation of IdP services is nice in theory, but may windup compromising both protocols.

John B.

On 2012-11-29, at 2:24 PM, Blaine Cook <[email-masked]> wrote:

> OpenID and other similar protocols handle the verification of domain & ownership. Any protocol where authn/authz happen will also do this.
> 
> Isn't it safest if we assume that webfinger is for "untrusted" discovery (like DNS, which still works, thankyouverymuch) and actions that need more security / authentication should define that themselves?
> 
> b.
>

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 29 Nov 2012 10:18:25 -0800

> You may be right and openID should not be trying to use WF.

+ 1

> There was a lot of pressure put on the two groups to avoid having two

Yes, and my objective here was to clarify the implications of doing
so. With the current write up, it's not feasible to use WF in an authz
context.

>
> As I have said several times, adding the additional requirements for
> security to WF may be breaking it for its original more FoF like purpose.
>
> Connect's use case for discovery ls simply finding the IdP relationship for
> a identifier the user gives to a RP securely to prevent phishing.
> All the other stuff in WF is extraneous to us.  Using WF to let a host
> provide per account delegation of IdP services is nice in theory, but may
> windup compromising both protocols.

More is less for security.

Let's give up on the goal of re-using WF for OpenIDConnect and allow
WF to converge to a solution that is more suitable to its specified
goals.

-- 
--Breno

---

From: William Mills <[email-masked]>
Date: Thu, 29 Nov 2012 10:32:20 -0800 (PST)

Well this is horrible.  If WF/SWD isn't usable for authz discovery that is a major major flaw in my opinion.  It's the reason I'm interested in it, because I want to solve auth endpoint discovery for OAuth desktop and mobile clients given a user's mail address.

This has got to get fixed.

>________________________________
> From: Breno de Medeiros <[email-masked]>
>To: John Bradley <[email-masked]> 
>Cc: [email-masked]; [email-masked]; Brad Fitzpatrick <[email-masked]> 
>Sent: Thursday, November 29, 2012 10:18 AM

---

From: Joseph Holsten <[email-masked]>
Date: Thu, 29 Nov 2012 10:53:26 -0800

Show of hands, who's saying we should support http-sans-tls?

Didn't we agree that supporting small providers was not a goal? I seriously can't think of a situation where any site that offers accounts to the public should not be expected to run https.

Clearly big fish and motivated vanity domain folks will make it work.

--
http://josephholsten.com

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 29 Nov 2012 14:01:13 -0500

I disagree.

The spec as written calls out several times that HTTPS should be used to 
get some sense of the authenticity of the server. It might be worthwhile 
calling out authentication protocols (did't it used to say something 
like that, Paul...?) but right now it's still quite clear.

Which clients require that level of authenticity, and whether they 
should fall back to HTTP, is an implementation detail.

I think for a system like OpenID Connect, it'd clearly make sense to say 
in the specs for that system, "Also, don't accept Webfinger without 
HTTPS." Done.

Trying to impose a model based on libraries and function calls and what 
exactly the arguments to those function calls would be is just at a 
different layer of abstraction from where this spec is.

-Evan

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

---

From: Tim Bray <[email-masked]>
Date: Thu, 29 Nov 2012 11:01:50 -0800

I have to say this discussion is causing me some pain.  I’m one of the
people who got here via working on OIDC and, while I think that
AccountChooser-ish stuff is going to be a better IDP discovery
mechanism in many cases, having a way to go fishing for an IDP given
an email address feels like an awfully useful thing.

There’s another level of discovery, which is, once I know that the IDP
is "example.com", how do you find out the 3 or so endpoints that you
need to use to make OIDC work? (It may be the case that there’s a long
history of discussion on this in OIDF, but I’m a n00b.)  It occurs to
me that if you went and fetched
example.com/.well-known/webfinger?r=example.com you might be able to
look there for rel values like auth-endpoint and userinfo-endpoint.
Not sure that’s optimal, but taking it off the table now feels a
little disappointing.

So put me down as a vote for TLS-always, but with two clearly
acknowledged biases:
- as someone who wants to accomplish auth-related goals. It’s
perfectly plausible that there are other uses for WF which will make
it a useful thing even if it can’t be helpful for OpenID
- as someone who thinks all Web traffic should always be TLS except in
those cases where there’s a powerful argument that some other factor
is more important than end-user safety/privacy

 -T

---

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

SWD is for secure discovery of authz endpoints.  That won't change. The question is if WF which is more FoF based ( I say that in a positive way) should compromise its utility of easy deployment in untrusted environments to accommodate our needs.  Being able to put a link in a html page that points to your web finger doc is a fine thing, and being able to host that anyplace is also fine.   It is just however possible that combining that with secure discovery of authz info may be a bridge to far.

If we want to merge them that's great, but the core use case for SWD needs to be supported.   We need to agree on what we are trying to solve for.

As Brad and Blane point out it is a legitimate question to ask what is WF for.    I am OK with WF not solving world hunger.   We just need to not have expectations set appropriately.

John B.

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 29 Nov 2012 14:05:36 -0500

I disagree.

I think it's been repeated over and over that if you require some 
authenticity to the results, use HTTPS and check the cert. You may not 
get true results, but at least you'll get the results as claimed by the 
host you're requesting from.

For systems like OpenID Connect, that's plenty.

-Evan

On 12-11-29 12:24 PM, Blaine Cook wrote:
> Isn't it safest if we assume that webfinger is for "untrusted" 
> discovery (like DNS, which still works, thankyouverymuch) and actions 
> that need more security / authentication should define that themselves?
>
> b.
>
> On Nov 29, 2012 9:56 AM, "Breno de Medeiros" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Thu, Nov 29, 2012 at 4:49 AM, Evan Prodromou <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > -1
>     >
>     > Breno de Medeiros <[email-masked] <mailto:[email-masked]>>
>     wrote:
>     >
>     > On Nov 28, 2012 9:44 PM, "Paul E. Jones" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>
>     >> From: [email-masked]
>     <mailto:[email-masked]>
>     [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     >> To: [email-masked] <mailto:[email-masked]>
>     >> Cc: [email-masked] <mailto:[email-masked]>
>     >> On Tue, Nov 27, 2012 at 9:18 PM, Mike Jones
>     <[email-masked] <mailto:[email-masked]>>
>     >> wrote:
>     >>
>     >> +1
>     >>
>     >>
>     >>
>     >> From: [email-masked]
>     <mailto:[email-masked]>
>     [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     >> On Behalf Of Dick Hardt
>     >> To: [email-masked] <mailto:[email-masked]>
>     >> Cc: [email-masked] <mailto:[email-masked]>
>     >> On Nov 27, 2012, at 6:17 PM, Brad Fitzpatrick
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >>
>     >>
>     >> given just a string that looks like "[email-masked]
>     <mailto:[email-masked]>", find a
>     >> 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
>     >> the format of the identifier matters because people ("regular
>     users")
>     >> or XRIs or any other "dorky" identifier.  Webfinger is about
>     doing a
>     >> the string "[email-masked] <mailto:[email-masked]>" is NOT
>     necessarily an email address, even
>     >> corollary: the "acct:" URI scheme and
>     draft-ietf-appsawg-acct-uri-01 etc
>     >>
>     >> i.e. we'd rather have a 3 page spec that makes 90% of people
>     happy rather
>     >> 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.
>     >>
>     >> 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
>     >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Nov 2012 14:06:04 -0500

Why?  There isn't even a requirement in the current spec for a client to use
HTTP.

Paul

> -----Original Message-----
> From: Breno de Medeiros [mailto:[email-masked]]
> Sent: Thursday, November 29, 2012 11:56 AM
> To: Evan Prodromou
> Cc: Paul E. Jones; Brad Fitzpatrick; [email-masked]; apps-
> [email-masked]
> I don't disagree. But the conclusion from a security perspective doesn't
> change. One shouldn't use WF for security applications such as
> > 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.
> >
> >> 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
> >>
> >>
> >>
> >> [mailto:[email-masked]]
> >> 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.
> >>
> >>
> >>
> >>
> >>
> >> <[email-masked]>
> >> wrote:
> >>
> >> +1
> >>
> >>
> >>
> >> [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 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.
> >>
> >>
> >>
> >> 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
> >> 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
> >> 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
> >> corollary: the "acct:" URI scheme and draft-ietf-appsawg-acct-uri-01
> >> etc
> >>
> >> 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.
> >> further assumption: most will be running Wordpress or some such
> >> software already.
> >> 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)?
> >> DNS (SRV, TXT, etc) precludes JavaScript clients (as of 2006-2012),
> >> so rejected. HTTP instead.
> >>
> >> JSON vs XML
> >>
> >> 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.
> >>
> >> (routing on headers, rather than request paths) and more importantly
> >> too hard for clients to send (setting headers).
> >> 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: service providers may need to reverse-proxy the query to the
> >> right backend.

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 29 Nov 2012 11:08:24 -0800

On Thu, Nov 29, 2012 at 11:01 AM, Evan Prodromou <[email-masked]> wrote:
> I disagree.
>
> The spec as written calls out several times that HTTPS should be used to get
> some sense of the authenticity of the server. It might be worthwhile calling
> out authentication protocols (did't it used to say something like that,
> Paul...?) but right now it's still quite clear.
>
> Which clients require that level of authenticity, and whether they should
> fall back to HTTP, is an implementation detail.

Actually, no, it's not an implementation detail. It's a crucial choice
for the spec that clarifies what is the set of suitable applications
for it.

What would be clear is to say that WF MUST attempt TLS transport and
MUST fail if TLS negotiation, including certificate validation, fails.

Any compliant implementation is clearly still free in this case to
allow for non-spec compliant configuration choice that bypasses the
TLS checks, as long as they also support a spec-compliant
configuration in a clear manner.

> I think for a system like OpenID Connect, it'd clearly make sense to say in
> the specs for that system, "Also, don't accept Webfinger without HTTPS."
> Done.
>
>>>> (yes,
>>>> don't
>>>> assumptions,
>>>> it's
>>>> IRIs
>>>> self-hosted
>>>> that
>>>> prefer

-- 
--Breno

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 29 Nov 2012 14:08:59 -0500

Do you mean, "There's not a requirement to fall back to HTTP?"

Because otherwise what you're saying doesn't make any sense.

-Evan

---

From: William Mills <[email-masked]>
Date: Thu, 29 Nov 2012 11:09:57 -0800 (PST)

I thought they had already been merged into one thing since they are so very similar?

> From: John Bradley <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: Breno de Medeiros <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; Brad Fitzpatrick <[email-masked]> 
>Sent: Thursday, November 29, 2012 11:01 AM
>>>>> >> If
>>>>> >> or an https server running already, but I'm fine with some
>>>>> >> inconvenience
 in
>>>>> >> The decisions are I'm sure subject to change, but hopefully
 not too
>>>>> >> much.
>>>>> >> gets its name), email-looking identifiers like “[email-masked]” have
>>>>> >>
 been
>>>>> >> discovery (read) operation on something a non-technical user
 would
>>>>> >> write on
 one
>>>>> >> management of their webfinger profiles or will know what they’re doing
>>>>> >>
 and
>>>>> >> software
>>>>> >> too
>>>>> >> delegation

---

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

I'm putting this into the security considerations section:

The recommended use of HTTPS is to ensure that information is not modified
during transit.  It should be appreciated that in environments where an
HTTPS server is normally available, there exists the possibility that a
compromised network might have its WebFinger server operating on HTTPS
replaced with one operating only over HTTP.  As such, clients that need to
ensure data is not compromised should not issue queries over a non-secure
connection.  While Section 5.1 allows for clients that fail to establish an
HTTPS connection to attempt a query using HTTP, a client and any underlying
client libraries are not required to re-issue queries using HTTP and SHOULD
NOT when security for a given application that uses WebFinger is paramount.

Sound good?

> Sent: Thursday, November 29, 2012 2:08 PM
> To: Evan Prodromou
> > The spec as written calls out several times that HTTPS should be used
> > to get some sense of the authenticity of the server. It might be
> > worthwhile calling out authentication protocols (did't it used to say
> > something like that,
> for the spec that clarifies what is the set of suitable applications for
> it.
> 
> Any compliant implementation is clearly still free in this case to allow
> for non-spec compliant configuration choice that bypasses the TLS checks,
> as long as they also support a spec-compliant configuration in a clear
> manner.
> 
> > I think for a system like OpenID Connect, it'd clearly make sense to
> > say in the specs for that system, "Also, don't accept Webfinger
> without HTTPS."
> > Done.
> >
> > Trying to impose a model based on libraries and function calls and
> > what exactly the arguments to those function calls would be is just at
> > a different layer of abstraction from where this spec is.
> >
> > -Evan
> >
> >
> >> doesn't change. One shouldn't use WF for security applications such
> >> as authorization with the currently proposed spec formulation.
> >>
> >>> 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.
> >>>
> >>>> 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
> >>>>
> >>>>
> >>>>
> >>>> (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
> >>>>
> >>>>
> >>>>
> >>>> Anyway, we had a very productive conversation on chat and wrote a
> >>>> doc together to clarify thought processes and decisions:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> webfinger
> >>>> gets its name), email-looking identifiers like "[email-masked]" have
> been
> can't
> >>>> do
> >>>> any read/discovery operations on it.  You can't find its supported
> or
> them
> >>>> for
> >>>> or XRIs or any other "dorky" identifier.  Webfinger is about doing
> a
> >>>> discovery (read) operation on something a non-technical user would
> write
> >>>> on
> >>>> corollary: the "acct:" URI scheme and draft-ietf-appsawg-acct-uri-
> 01 etc
> >>>>
> >>>> rather
> decide
> >>>> to
> >>>> delegate
> >>>> management of their webfinger profiles or will know what they're
> doing
> >>>> and
> >>>> XML, that's fine.  JSON is easier for JavaScript clients, as one
> >>>> advantage.
> >>>> But
> >>>> both are small arguments and not worth arguing about.  At the end
> of the
> >>>> day
> less
> where
> >>>> to
> right

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 29 Nov 2012 14:18:43 -0500

+1

-Evan

---

From: William Mills <[email-masked]>
Date: Thu, 29 Nov 2012 11:20:22 -0800 (PST)

Well, the first sentence is basically going wrong, it talks about only the integrity guarantee when in fact the certificate authenticity and identity that goes with it are equally important; so not only do you care that the data has not been tampered with, you ALSO care that it came from where it was supposed to.

> From: Paul E. Jones <[email-masked]>
>To: 'Breno de Medeiros' <[email-masked]>; 'Evan Prodromou' <[email-masked]> 
>Cc: 'Brad Fitzpatrick' <[email-masked]>; [email-masked]; [email-masked] 
>Sent: Thursday, November 29, 2012 11:10 AM

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 29 Nov 2012 11:24:00 -0800

> NOT when security for a given application that uses WebFinger is paramount.

Security Considerations are not normative language. See the language I
proposed about MUST use TLS and MUST fail if TLS negotiation,
including certificate validation, fails.

In the security considerations you could then discuss why the
normative language is written as such and say that applications may
want to allow HTTP fallback for non-security sensitive applications as
long as the compliant behavior is also implemented and easily
configurable.

-- 
--Breno

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Nov 2012 16:28:54 -0300

Tim,

The flow in OIDC is that the Client uses SWD/WF to find the "issuer" (Identity provider).
That is a link relation of http://openid.net/specs/connect/1.0/issuer

Having users enter config information for authorization servers that may change is a horrible maintenance issue (seen in Yadis).

The client then appends  /.well-known/openid-configuration to the issuer URI then performs a GET on that to retrieve the IdP's configuration as a JSON document.

Account Chooser provides the issuer and login_hint (email) as parameters to RP that are using that based on what is stored in HTML5 local storage.

So one might observe that someone using a browser that has been repopulated by there IdP with issuer and login_hint when they go to a RP that uses account chooser there is no WF/SWD discovery happening.

Where WF/SWD is useful is bootstrapping account chooser at the RP, or at RP not using the browser/common domain service.

So OIDC has that second level of secure discovery based on knowing the issuer/domain built in already.

What WF/SWD is giving is the ability to have per account delegation of authorization in a domain.

At [email-masked] may want to say his IdP is Google and delegate to that while [email-masked] may want to run her own server someplace.

SWD & WF both allow per user specification of the issuer.  Originally in OIDC Dave Recordon did not have per user discovery we just took the domain name from the email as the issuer and retrieved the 
configuration from /.well-known/openid-configuration.

It was much simpler for the client.

A legitimate question for OIC is if with account chooser now available as a push discovery mechanism for people wanting to do complicated things (a user can have chooser push any issuer and email to the RP), perhaps the super simple IdP discovery is enough for those other situations.    That prevents us from having to mess up WF with extra security considerations.

I am just taking the redial position(stolen from Breno)  that if we are making things harder for clients we are perhaps heading in the wrong direction.

John B.

On 2012-11-29, at 4:01 PM, Tim Bray <[email-masked]> wrote:

>>>>>> inconvenience in

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Nov 2012 14:39:07 -0500

We already have language in the text, both in 5.1 and the security
considerations section, that speaks of certificate validation.

Also, I can make the SHOULD NOT in the security considerations section
lowercase.  It makes no difference.  It's only guidance.

Paul

> Sent: Thursday, November 29, 2012 2:24 PM
> To: Paul E. Jones
> Cc: Evan Prodromou; Brad Fitzpatrick; [email-masked]; apps-
> [email-masked]
> > The recommended use of HTTPS is to ensure that information is not
> > modified during transit.  It should be appreciated that in
> > environments where an HTTPS server is normally available, there exists
> > the possibility that a compromised network might have its WebFinger
> > server operating on HTTPS replaced with one operating only over HTTP.
> > As such, clients that need to ensure data is not compromised should
> > not issue queries over a non-secure connection.  While Section 5.1
> > allows for clients that fail to establish an HTTPS connection to
> > attempt a query using HTTP, a client and any underlying client
> > libraries are not required to re-issue queries using HTTP and SHOULD
> proposed about MUST use TLS and MUST fail if TLS negotiation, including
> certificate validation, fails.
> 
> In the security considerations you could then discuss why the normative
> language is written as such and say that applications may want to allow
> HTTP fallback for non-security sensitive applications as long as the
> compliant behavior is also implemented and easily configurable.
> 
> >
> > Sound good?
> >
> >> Cc: Paul E. Jones; Brad Fitzpatrick; [email-masked];
> >> apps- [email-masked]
> >> > The spec as written calls out several times that HTTPS should be
> >> > used to get some sense of the authenticity of the server. It might
> >> > be worthwhile calling out authentication protocols (did't it used
> >> > to say something like that,
> >> Actually, no, it's not an implementation detail. It's a crucial
> >> choice for the spec that clarifies what is the set of suitable
> >> applications for it.
> >>
> >> > I think for a system like OpenID Connect, it'd clearly make sense
> >> > to say in the specs for that system, "Also, don't accept Webfinger
> >> without HTTPS."
> >> > Done.
> >> >
> >> > what exactly the arguments to those function calls would be is just
> >> > at a different layer of abstraction from where this spec is.
> >> >
> >> > -Evan
> >> >
> >> >
> >> >> doesn't change. One shouldn't use WF for security applications
> >> >> such as authorization with the currently proposed spec formulation.
> >> >>
> >> >>> 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.
> >> >>>
> >> >>> 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.
> >> >>>
> >> >>>> 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.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> 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
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> <[email-masked]>
> >> >>>> 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-E6x7VDtmEaC48Send
> >> >>>> GWQ
> >> >>>> e7XcY99pjQWs/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
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> "[email-masked]" have
> >> >>>> supported
> >> >>>> corollary: WebFinger is not about doing discovery on URLs or
> >> >>>> URIs
> >> or
> >> >>>> IRIs
> >> >>>> happy rather than a 30 page spec that makes 95% of people happy,
> >> >>>> especially if
> >> such a
> >> >>>> . 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
> >> >>>> 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.
> argument).
> >> >>>> Decision: Just one HTTP requests, because we care more about
> >> >>>> client simplicity than server simplicity.
> >> >>>>
> >> >>>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Nov 2012 14:40:34 -0500

Yeah, but that's covered separately.

From: William Mills [mailto:[email-masked]] 
Sent: Thursday, November 29, 2012 2:20 PM
To: Paul E. Jones; 'Breno de Medeiros'; 'Evan Prodromou'
Cc: 'Brad Fitzpatrick'; [email-masked]; [email-masked]
Subject: Re: [apps-discuss] Webfinger goals doc

Well, the first sentence is basically going wrong, it talks about only the
integrity guarantee when in fact the certificate authenticity and identity
that goes with it are equally important; so not only do you care that the
data has not been tampered with, you ALSO care that it came from where it
was supposed to.

  _____  

From: Paul E. Jones <[email-masked]>
To: 'Breno de Medeiros' <[email-masked]>; 'Evan Prodromou'
<[email-masked]> 
Cc: 'Brad Fitzpatrick' <[email-masked]>; [email-masked];
[email-masked] 
Sent: Thursday, November 29, 2012 11:10 AM
Subject: Re: [apps-discuss] Webfinger goals doc

Sound good?

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Nov 2012 14:47:48 -0500

There are useful applications of WF where HTTPS is not needed.  At the same
time, there is absolutely nothing to prevent an OpenID Connect client from
only using TLS.  In fact, I would make that a requirement in OpenID Connect.

Paul

> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Joseph Holsten
> Sent: Thursday, November 29, 2012 1:53 PM
> To: [email-masked]; [email-masked]
> Didn't we agree that supporting small providers was not a goal? I
> seriously can't think of a situation where any site that offers accounts
> to the public should not be expected to run https.
> 
> >> Connect's use case for discovery ls simply finding the IdP
> >> relationship for a identifier the user gives to a RP securely to
> prevent phishing.
> >> All the other stuff in WF is extraneous to us.  Using WF to let a
> >> host provide per account delegation of IdP services is nice in
> >> theory, but may windup compromising both protocols.
> >
> >> OpenID and other similar protocols handle the verification of domain
> >> & ownership. Any protocol where authn/authz happen will also do this.
> >>
> >>>> to indicate if only HTTPS is allowed (technically the inputs for WF
> >>>> violation of layering if OpenIDConnect will invoke the WF client
> >>>> and then try to second guess what the HTTP client that was wrapped
> port.
> >>>>> your domain supports HTTPS, run it only on HTTPS.  Clients MUST
> >>>>> query there first.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Paul
> >>>>>
> >>>>>
> >>>>>
> >>>>> doesn't have certs or an https server running already, but I'm
> >>>>> fine with some inconvenience in exchange for security and simpler
> >>>>> clients.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> 1.0 (yes, a little apples and oranges comparison, but there was a
> >>>>> 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.
> >>>>>
> >>>>>
> >>>>>
> >>>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> 01
> >>>>> than a 30 page spec that makes 95% of people happy, especially if
> such
> >>>>> a
> >>>>> few users own their own domain name and will run their own
> identity
> >>>>> server
> >>>>>
> they
> of
> >>>>> the day

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 29 Nov 2012 11:55:54 -0800

> only using TLS.  In fact, I would make that a requirement in OpenID Connect.

Specs need to be cognizant about how implementations will be written.
If the spec says that an implementation can support HTTP fallback it's
likely that all of them will do this by default and not all of them
will allow the choice to disable such fallback to be configurable. So
OpenIDConnect spec is placed in the bizarre situation to recommend a
discovery layer which may have many compliant implementations that do
not (and cannot be made to) satisfy a core security requirement.

I am a believer that specs should be written to give guidance to the
open source developers that are going to write the code.

-- 
--Breno

---

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

Yeah, clients are not REQUIRED to use HTTP.  The text says:

"Clients MUST first attempt a query the server using HTTPS and utilize HTTP
only if an HTTPS connection cannot be established".

It does not say the client MUST try HTTP, only that they MUST use HTTPS.
There is the suggestion, of course, that clients would then issue an HTTP
query since that would be ideal for many applications.

That said, there is nothing wrong with OpenID Connect requiring only use of
HTTPS.  I'd fully support such a requirement in the OpenID Connect specs.

Paul

> [email-masked]] On Behalf Of Evan Prodromou
> Sent: Thursday, November 29, 2012 2:09 PM
> To: [email-masked]
> > Why?  There isn't even a requirement in the current spec for a client
> > to use HTTP.
> >
> > Paul
> >
> >>> value that SHOULD be
> >>> 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
> >>>> security
> >>>> https://docs.google.com/document/d/1Yr00Tr5d71-E6x7VDtmEaC48SendGWQ
> >>>> e7
> >>>> XcY99pjQWs/edit#
> >>>>
> >>>>
> >>>>
> >>>> mechanism
> >>>> 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.
> >>>>
> >>>> 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.
> >>>> 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
> >>>>
> >>>> 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
> >>>> 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).

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 29 Nov 2012 12:08:00 -0800

> Yeah, clients are not REQUIRED to use HTTP.  The text says:

Sigh.

In practice the motivation is to support more cases, not less. I meant
they should be REQUIRED not to support HTTP for spec compliance. What
they do when they don't care about spec compliance doesn't affect me.

-- 
--Breno

---

From: John Panzer <[email-masked]>
Date: Thu, 29 Nov 2012 12:07:56 -0800

On Thu, Nov 29, 2012 at 11:47 AM, Paul E. Jones <[email-masked]>wrote:

> There are useful applications of WF where HTTPS is not needed.

Could we list those?  I'm having trouble coming up with any myself that
aren't something like a localhost loopback for testing, frankly.

>  At the same
> > even
> > some
> > spec
> > balances
> > We
> > route

---

From: William Mills <[email-masked]>
Date: Thu, 29 Nov 2012 12:11:33 -0800 (PST)

So it might be worthwhile in that doc to state explicitly that there will be cases where HTTP SHOULD NOT be used and clients need to support an exclusively HTTPS mode?

>To: 'Evan Prodromou' <[email-masked]>; [email-masked] 
>Sent: Thursday, November 29, 2012 12:01 PM

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Nov 2012 15:17:21 -0500

The example in section 4.1 is a good example.

Every single bit of information is served over HTTP.  Bob's blog, Bob's
vcard info, Bob's profile page, etc.  It's all public information.

There are only certain applications where HTTPS is vital.  Even OpenID 2.0
does not need HTTPS, really. If I had my OpenID Provider endpoint URL in WF
and somebody changed the value when I tried to access the service, I would
know when the window opened that it's not the correct site.  My OpenID login
URL (https://openid.packetizer.com/login/) would present a page when I log
in that I could clearly identify as bogus.

Still, use of TLS might be preferred for OpenID 2.0 just to help prevent a
situation where the user is not paying attention to the fact they were
redirected to a phishing site.  So, I'm not arguing against use of TLS for
OpenID 2.0 or OpenID Connect.  I'm only saying that there are only certain
uses of WF that truly need it.  If WF is only use for stuff like in Section
4.1, TLS is not needed.

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of John Panzer
Sent: Thursday, November 29, 2012 3:08 PM
To: [email-masked]
Cc: Joseph Holsten; [email-masked]
Subject: Re: [apps-discuss] Webfinger goals doc

On Thu, Nov 29, 2012 at 11:47 AM, Paul E. Jones <[email-masked]>
wrote:

 

 At the same

Paul

---

From: Joseph Anthony Pasquale Holsten <[email-masked]>
Date: Thu, 29 Nov 2012 12:22:29 -0800

We talked about this: https://groups.google.com/forum/#!topic/webfinger/WpYWy-Bpcwo

On 2012-11-29, at 12:17 , "Paul E. Jones" <[email-masked]> wrote:

> Every single bit of information is served over HTTP.  Bob’s blog, Bob’s vcard info, Bob’s profile page, etc.  It’s all public information.
>  
> There are only certain applications where HTTPS is vital.  Even OpenID 2.0 does not need HTTPS, really. If I had my OpenID Provider endpoint URL in WF and somebody changed the value when I tried to access the service, I would know when the window opened that it’s not the correct site.  My OpenID login URL (https://openid.packetizer.com/login/) would present a page when I log in that I could clearly identify as bogus.
>  
> Still, use of TLS might be preferred for OpenID 2.0 just to help prevent a situation where the user is not paying attention to the fact they were redirected to a phishing site.  So, I’m not arguing against use of TLS for OpenID 2.0 or OpenID Connect.  I’m only saying that there are only certain uses of WF that truly need it.  If WF is only use for stuff like in Section 4.1, TLS is not needed.
>  
> Paul
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Panzer
> Could we list those?  I'm having trouble coming up with any myself that aren't something like a localhost loopback for testing, frankly.
>  
>  
>  At the same

---

From: John Panzer <[email-masked]>
Date: Thu, 29 Nov 2012 14:31:12 -0800

It's Bob's entire public identity.  Knowing it wasn't altered in transit or
served from a take origin is kind of... important.
On Nov 29, 2012 12:17 PM, "Paul E. Jones" <[email-masked]> wrote:

> The example in section 4.1 is a good example.****
>
> ** **
>
> Every single bit of information is served over HTTP.  Bob’s blog, Bob’s
> vcard info, Bob’s profile page, etc.  It’s all public information.****
>
> ** **
>
> know when the window opened that it’s not the correct site.  My OpenID
> login URL (https://openid.packetizer.com/login/) would present a page
> when I log in that I could clearly identify as bogus.****
>
> ** **
>
> redirected to a phishing site.  So, I’m not arguing against use of TLS for
> OpenID 2.0 or OpenID Connect.  I’m only saying that there are only certain
> 4.1, TLS is not needed.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *John Panzer
> *Sent:* Thursday, November 29, 2012 3:08 PM
> *To:* [email-masked]
> *Cc:* Joseph Holsten; [email-masked]
> *Subject:* Re: [apps-discuss] Webfinger goals doc****
>
> ** **
>
> wrote:****
> There are useful applications of WF where HTTPS is not needed. ****
>
> ** **
>
> aren't something like a localhost loopback for testing, frankly.****
>
> ** **
>
>  ****
>
>  At the same
> only using TLS.  In fact, I would make that a requirement in OpenID
> Connect.****
>
>
> Paul
>
> > From: [email-masked] [mailto:apps-discuss-****
>
> > https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> ** **
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Nov 2012 17:55:41 -0500

Protecting the JRD response is no more or less important than protecting his
resources (e.g., his vcard).  If the data to which the JRD points is all
accessible to the public over HTTP, having HTTPS for the JRD itself is not
very useful.  The security weakness just shift to the other resource.  And
in many instances, it absolutely does not matter.

There is nothing served from my current WF server that necessitates use of
security, because all the stuff I point to is not secured.  I suspect this
will be the case for many deployments.

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of John Panzer
Sent: Thursday, November 29, 2012 5:31 PM
To: [email-masked]
Cc: Joseph A Holsten; [email-masked]
Subject: Re: [apps-discuss] Webfinger goals doc

Paul

 

 At the same

Paul

---

From: Joseph Holsten <[email-masked]>
Date: Thu, 29 Nov 2012 15:03:49 -0800

Kingsley,

Are you telling us you've implemented a custom PKI outside the de-facto web CA structure? And it isn't just use TLS with custom web-of-trust network for cert verification?

Because from my perspective, the best authority chain I can expect from an in-browser JS client is from ye olde web CAs. And if we allow HTTP-sans-TLS, we can't even guarantee that. 

--
http://josephholsten.com

On Nov 29, 2012, at 14:44, Kingsley Idehen <[email-masked]> wrote:

> On 11/29/12 5:31 PM, John Panzer wrote:
>> It's Bob's entire public identity.  Knowing it wasn't altered in transit or served from a take origin is kind of...         important.
>> 
> 
> You have to distinguish "profile discovery" from "profile authenticity" esp., when dealing with nebulous identity and profile oriented matters. This is the point I believe Blaine is alluding to in his comments re. separation of powers. 
> 
> HTTPS doesn't ensure authenticity on it own, the entire CA network has been long compromised. You really need to add logic into the structured data i.e., via machine-readable entity relationship semantics to truly address this problem. Thus, for sake of getting     Webfinger to a critical beachhead, best to keep these matters separate. 
> 
> Disclosure: We already have Webfinger working in scenarios where     Identity verification and profile claims authenticity are the focal point. This all happened without making any change requests re. the current Webfinger spec :-) 
> 
> Kingsley 
> Regards,
> Kingsley Idehen	      
> Founder & CEO 
> OpenLink Software     
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 29 Nov 2012 19:44:41 -0800

On Nov 29, 2012, at 2:55 PM, "Paul E. Jones" <[email-masked]> wrote:

> Protecting the JRD response is no more or less important than protecting his resources (e.g., his vcard).  If the data to which the JRD points is all accessible to the public over HTTP, having HTTPS for the JRD itself is not very useful.  The security weakness just shift to the other resource.  And in many instances, it absolutely does not matter.
>  
> There is nothing served from my current WF server that necessitates use of security, because all the stuff I point to is not secured.  I suspect this will be the case for many deployments.

If there is just one thing you point to that does need to be trusted, then it can't.

-- Dick

---

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

Yeah, I agree.  That said, I mentioned before that using OpenID 2.0, even if
you tampered with my WF response, I would recognize something is wrong when
I'm not taken to the right site to log in.  Thus, trust does not need to be
placed on WF in that instance.  Trust needs to be placed on my OpenID
Provider's page.

If OpenID Connect is different in that it must trust the response from WF or
else things break down, then it should require TLS.  I have no objection to
that.

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dick Hardt
Sent: Thursday, November 29, 2012 10:45 PM
To: [email-masked]
Cc: [email-masked]; 'Joseph A Holsten'
Subject: Re: [apps-discuss] Webfinger goals doc

If there is just one thing you point to that does need to be trusted, then
it can't.

-- Dick

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 29 Nov 2012 20:19:08 -0800

On Thu, Nov 29, 2012 at 8:14 PM, Paul E. Jones <[email-masked]> wrote:
> I’m not taken to the right site to log in.

The overwhelming majority of the users wouldn't.

> Thus, trust does not need to be
> Provider’s page.

If this were true, phishing attacks would not exist.

> else things break down, then it should require TLS.  I have no objection to

There's nothing different from OpenIDConnect.

Any authz protocol should use secure discovery protocol if using
discovery at all. Discovery protocols that have HTTP fallback support
are not sufficiently secure for this purpose.

-- 
--Breno

---

From: William Mills <[email-masked]>
Date: Thu, 29 Nov 2012 20:34:47 -0800 (PST)

+1

>To: Paul E. Jones <[email-masked]> 
>Cc: [email-masked]; [email-masked]; Joseph A Holsten <[email-masked]> 
>Sent: Thursday, November 29, 2012 8:19 PM

---

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

> > Yeah, I agree.  That said, I mentioned before that using OpenID 2.0,
> > even if you tampered with my WF response, I would recognize something
> > is wrong when I'm not taken to the right site to log in.
> 

Well, they should.  Let's say you're visiting web site that looks legit, but
is actually engages in identity theft.  If you try to log into the site, the
site might use WF to see that your OpenID Provider is Google, for example,
then throw up a fake page that looks like Google, but isn't.  No amount of
protection in WF is going to prevent that sort of thing from happening.  The
breakdown there isn't WF, but the fact that the user did not take note that
the site where the user ID and password were entered were a fake site.
Users MUST inspect such things.
 
> If this were true, phishing attacks would not exist.

See above.  I just showed you an example of a phishing attack in spite of
the fact that one's WF server might use TLS.
 
> > If OpenID Connect is different in that it must trust the response from
> > WF or else things break down, then it should require TLS.  I have no
> > objection to that.
> 

No, I disagree with that.  Two points:

1) If it is important to ensure one receives a tamper-free WF reply, then
use TLS only. There is absolutely nothing wrong with OpenID Connect
insisting on use of TLS.  I'd support that 100%.  It would NOT have to fall
back to HTTP no requirement exists in the WF spec that demands it.
2) Following the logic of the above phishing attack, the authorization
protocol absolutely must be secure regardless of whatever discovery protocol
is employed.  Users must be able to have a guarantee that they are at the
right location and that they are not entering user/password information into
a phishing site.

Paul

---

From: Dick Hardt <[email-masked]>
Date: Thu, 29 Nov 2012 20:49:30 -0800

(attempting to change subject line to reflect the topic)

I think we can agree that:

1) Some uses of WF will require TLS

2) Some uses of WF may not require TLS 

Here are some questions that might help us come to consensus. If not, well, I think they are interesting anyway. :)

Q1: How will implementors know which uses of WF require TLS? Do we leave that up to the use case? If TLS is a MUST, then no use of WF needs to specify HTTPS vs HTTP.

Q2: What is lost by making TLS a MUST? Let's get clear on the functionality we lose. There is extra the obvious extra effort in deploying TLS, and some domain owners will not be able to do it because of how their domain is CURRENTLY managed. What else?

-- Dick

---

From: Mike Jones <[email-masked]>
Date: Fri, 30 Nov 2012 05:36:06 +0000

I'm with Breno and others who have spoken up for https-only, for the reasons they already clearly stated.

I'd suggest that rather than OpenID Connect profiling the base spec to prohibit the use of http: URLs, the base spec should describe only the use of https:.  (That's actually a significant simplification for clients as well, as they only have one URL to use then.)

I'd assert that if a different specification wants to use a WebFinger-like discovery protocol and wants to specify the use of http: URLs as a fallback mechanism, the onus should be on that specification to specify the downgrade mechanism.  It should not be in the base specification.

                                                            Cheers,

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Thursday, November 29, 2012 8:35 PM
To: Breno de Medeiros; Paul E. Jones
Cc: Joseph A Holsten; [email-masked]; [email-masked]
Subject: Re: [apps-discuss] Webfinger goals doc

+1

________________________________
From: Breno de Medeiros <[email-masked]<mailto:[email-masked]>>
To: Paul E. Jones <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Joseph A Holsten <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 29, 2012 8:19 PM
Subject: Re: [apps-discuss] Webfinger goals doc

>
>
>
> Paul
>
>
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> On Behalf Of Dick Hardt
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; 'Joseph A Holsten'
>
>
> On Nov 29, 2012, at 2:55 PM, "Paul E. Jones" <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>
> [email-masked]<mailto:[email-masked]>

--
--Breno
_______________________________________________
apps-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John Panzer <[email-masked]>
Date: Thu, 29 Nov 2012 22:53:02 -0800

+1.
On Nov 29, 2012 9:36 PM, "Mike Jones" <[email-masked]> wrote:

>  I'm with Breno and others who have spoken up for https-only, for the
> reasons they already clearly stated.****
>
> ** **
>
> I'd suggest that rather than OpenID Connect profiling the base spec to
> prohibit the use of http: URLs, the base spec should describe only the use
> of https:.  (That's actually a significant simplification for clients as
> well, as they only have one URL to use then.)****
>
> ** **
>
> I'd assert that if a different specification wants to use a WebFinger-like
> discovery protocol and wants to specify the use of http: URLs as a fallback
> mechanism, the onus should be on that specification to specify the
> downgrade mechanism.  It should not be in the base specification.****
>
> ** **
>
>                                                             Cheers,****
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *William Mills
> *Sent:* Thursday, November 29, 2012 8:35 PM
> *To:* Breno de Medeiros; Paul E. Jones
> *Cc:* Joseph A Holsten; [email-masked]; [email-masked]
> +1****
>    ------------------------------
>
> *From:* Breno de Medeiros <[email-masked]>
> *To:* Paul E. Jones <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Joseph A Holsten
> <[email-masked]>
> *Sent:* Thursday, November 29, 2012 8:19 PM
> even if
> WF or

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 30 Nov 2012 12:23:46 +0100

Hi all,

I've been pretty silent those days and actually busy following the various threads...but happy to see that it triggered so much interest. My apologies for the long talk ahead...

I'd like to share with you the case of the OMA (Open Mobile Alliance) Social Network Web enabler, which aims at specifying interoperable protocols (and component behaviors) between both client-server (intra-domain) and server-server (inter-domain federation) and in that sense is another "user" of webfinger like openid connect may be.
This spec has started in May '11 and was technically ready in july this year, but for a set of reasons it is still in "closing draft" version now. One of these reasons is the dependency on webfinger. To make it short, we use it (think more at the concept of discovery) for 1) autoconfiguration, 2) cross-domain discovery. Please also keep in mind that our intention is a) to leverage network-based authentication of users whenever possible, b) to interoperate with other federated social networks even if not fully "SNEW-compliant". But currently "our" webfinger is actually hostmeta/lrdd/xrd...

For SneW to only reference webfinger (besides keeping host-meta for oexchange/ostatus interop) it would need be supported over plain http as well, and without mandating the resource parameter (not known to the client neither the first nor the second time for autoconfiguration). The server could answer with resource-specific information (rel/endpoints) to the https request in case it recognizes the user, but not to the initial http one. Similarly, requests to the same webfinger endpoint without resource parameter could easily return hostwide information, that could be different whether it comes from http or https.
Finally, clients SHOULD use https, but there may be valid cases as shown where this cannot be used at first.

**RATIONALE**
We started by normatively embedding the "original" webfinger flow into the spec, which of course was hostmeta+lrdd+xrd based. With this we had intention b) for free as the most popular federated social network stack, ostatus, uses the same mechanism. Then seeing the webfinger activity being launched here, we updated that text to simply refer to it. However it has now derived from the original technologies and we are now somehow making up our minds on how to solve it at best.

Here are some requirements:

-          We need to be able to discover host-wide information. This is needed both for autoconfiguration where we discover the oauth2 endpoints (thanks Bill for the draft to let us get to token) and the protocol endpoint, but also for oexchange (still xrd-based btw)

-          The client may not (and sometimes should not) know the real identity of the user so we cannot rely exclusively on a protocol based on this assumption ("resource" is now mandatory)

-          Network-based identification mechanisms deployed by operators sometimes only work on HTTP. For these reasons we sometimes need to issue an http query first to get network-identified, have a cookie set up, then issue the same query again over https (the dual approach wrt http fallback).

We're actively monitoring this list to get a better understanding of where webfinger is going and just like openidconnect whether we ultimately will use it or not.  At this stage we still rely on hostmeta+xrd because of 1) interop with ostatus-based networks, 2) hostwide information accessible.
We acknowledge that HTTPS is needed for autoconfiguration (despite a potential first "ping" for mobile networks...) but federation discovery is currently frequently hosted over plain via xrd.

Support for current webfinger draft means an extra endpoint to expose, and the further need to parse jrd besides xrd (despite it is the most suitable format over json).
I was one of the first promoters of this also within the mobile industry but I am now looking for guidance on the true value for it. SNeW may reference openidconnect in a future release as well, and ideally if all of us would use the same foundation, the better, but at this stage it seems like some doubts are emerging on what is the added value wrt what's already available, and how much it fits the main use cases.

(again my apologies for those who read till here)
Walter

Da: [email-masked] [mailto:[email-masked]] Per conto di John Panzer
Inviato: venerdì 30 novembre 2012 7.53
A: [email-masked]
Cc: [email-masked]; Joseph A Holsten
Oggetto: Re: [apps-discuss] Webfinger goals doc

+1.
On Nov 29, 2012 9:36 PM, "Mike Jones" <[email-masked]<mailto:[email-masked]>> wrote:

                                                            Cheers,

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of William Mills
Sent: Thursday, November 29, 2012 8:35 PM
To: Breno de Medeiros; Paul E. Jones
Cc: Joseph A Holsten; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [apps-discuss] Webfinger goals doc

+1

On Thu, Nov 29, 2012 at 8:14 PM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
> I'm not taken to the right site to log in.

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

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

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

---

From: John Bradley <[email-masked]>
Date: Fri, 30 Nov 2012 09:02:35 -0300

The US Gov profile and and RP caring about security profiled openID 2 discovery to be TLS only.

It turned out to be a large and difficult problem in openID 2, and has hurt adoption some places.

I would prefer not to go through that again.

John B.

---

From: John Bradley <[email-masked]>
Date: Fri, 30 Nov 2012 09:08:23 -0300

WF can't stop bad RP from Phishing.

What is can do is stop good RP from being tricked into doing it.

If a trusted RP is suddenly compromised people are less likely to notice it than a new site they are visiting.

Hijacking WF to compromise where legitimate RP redirect users is the concern.

WF is not the only place we need to defend against phishing, but lets not increase the attack surface.

John B.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 30 Nov 2012 11:27:19 -0500

I can appreciate why they would do that since, without TLS, OpenID 2.0 uses
Diffie-Hellman key exchange and that is known to be subject to MITM attacks.

Requiring all government agencies to TLS reasonable.  What was the issue,
though?  By itself, that should not cause heartburn.  Was it that
non-government persons could create accounts on some government sites using
OpenID and the government wanted some assurance that the external user's
credentials were not hacked?  And if so, would they trust my little
one-person server to be secure in all other aspects? :-)

As has been said many times, security is only as strong as the weakest link
in the chain.  For OpenID 2.0, it starts with DNS.  DNS can still be
spoofed, and why people are not jumping up and down over that, I don't know.
(I will note that the US Government uses DNSSEC.  I also use DNSSEC on
packetizer.com.  It should be a requirement, too, as the foundation of any
secure authentication mechanism and there is little excuse for not using it
these days, IMO.)

The next step is the discovery piece.  One can argue this needs to be secure
and I would say this is certainly preferred.  I ran through a scenario with
OpenID 2.0 to try to prove the point that securing the discovery element
will not make the solution secure.  I'll repeat it more concretely.  Let's
say I visit a rogue site and enter my OpenID ID
(https://openid.packetizer.com/paulej).  The rogue site goes through the
usual discovery process -- all of which is secured with TLS -- but then
directs me to a page that is NOT my normal login page.  It could be made to
look like it -- even using TLS -- but it's a fake.  I enter my credentials
and the rogue site now has my OpenID ID, username, and password.  The
breakdown here is that I didn't take note of the fact that the login page
had the wrong URL.  I had better check that it is packetizer.com and not
fooledthefool.com.

So, my question is whether securing WF queries when using OpenID Connect
will prevent this kind of rogue server from stealing credentials in exactly
the same or similar way.  Is there anything to prevent that or must the user
pay attention to ensure that when they enter credentials, they are only
entered into the site that manages their identity?

My guess is that OpenID Connect does not prevent this kind of attack.  I
would not expect it to, either.  Thus, a compromised WF server is really as
much of an annoyance as a security vulnerability, since the "real" security
vulnerability is the fact a user can be directed to a fake login page even
when the WF server is not compromised.

It would be nice if WF responses were not modified in flight.  For that
reason, I would (and do) serve WF replies over TLS.  It does not stop the
rogue site described above, but would prevent MITM attacks.  So, I would
strongly recommend use of TLS if using OpenID Connect and other applications
where it might result in the user providing further security credentials.
That said, if a site not controlled by the government elected not to use
TLS, how does this become a "large and difficult problem"?  There are still
so many areas where the system can be attacked, all the way from DNS at the
bottom to user error at the top.

Paul

> From: John Bradley [mailto:[email-masked]]
> Sent: Friday, November 30, 2012 7:03 AM
> Cc: Paul E. Jones; Dick Hardt; Joseph A Holsten; [email-masked]
> >> If OpenID Connect is different in that it must trust the response
> >> from WF or else things break down, then it should require TLS.  I
> >> have no objection to that.
> >
> >> Protecting the JRD response is no more or less important than
> >> protecting his resources (e.g., his vcard).  If the data to which the
> >> JRD points is all accessible to the public over HTTP, having HTTPS
> >> for the JRD itself is not very useful.  The security weakness just
> >> shift to the other resource.  And in many instances, it absolutely
> does not matter.
> >>
> >>
> >>
> >> There is nothing served from my current WF server that necessitates
> >> use of security, because all the stuff I point to is not secured.  I
> >> suspect this will be the case for many deployments.
> >>
> >>
> >>

---

From: Bob Wyman <[email-masked]>
Date: Fri, 30 Nov 2012 11:43:04 -0500

On Thu, Nov 29, 2012 at 5:31 PM, John Panzer <[email-masked]> wrote:

> It's Bob's entire public identity.  Knowing it wasn't altered in transit
> or served from a take origin is kind of... important.
>
 An alternative to requiring a TLS encrypted link to read Bob's information
would be to permit Bob to sign the documents he publishes. That would allow
some level of integrity and authentication to be provided whether HTTP or
HTTPS had been used. WebFinger says nothing about signing. Why not?

Sincerely;
Bob

>> There are only certain applications where HTTPS is vital.  Even OpenID
>> 2.0 does not need HTTPS, really. If I had my OpenID Provider endpoint URL
>> in WF and somebody changed the value when I tried to access the service, I
>> would know when the window opened that it’s not the correct site.  My
>> OpenID login URL (https://openid.packetizer.com/login/) would present a
>> page when I log in that I could clearly identify as bogus.****
>>
>> ** **
>>
>> Still, use of TLS might be preferred for OpenID 2.0 just to help prevent
>> a situation where the user is not paying attention to the fact they were

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 30 Nov 2012 08:50:55 -0800

> one-person server to be secure in all other aspects? :-)

The issue is not the difficulty of putting up a TLS-enabled server.
The issue is the fact that you can't use protocol-compliant discovery
libraries because they will do HTTP if HTTPS is not available.

-- 
--Breno

---

From: Tim Bray <[email-masked]>
Date: Fri, 30 Nov 2012 08:52:17 -0800

Could you provide a little more detail?  Saying “Someone once had
trouble with this, so let’s not do it again” doesn’t quite do it for
me.

Also, it seems to me times are changing and TLS deployment is becoming
less onerous (disclosure: I’m in the process of turning it on for a
couple of domains right now).  -T

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 29 Nov 2012 11:03:54 -0800

On Thu, Nov 29, 2012 at 11:01 AM, Evan Prodromou <[email-masked]> wrote:

> in the specs for that system, "Also, don't accept Webfinger without HTTPS."
> Done.
>

I agree.  And MUST it on both sides for double protection:

OpenID Connect: servers MUST NOT provide blah blah over insecure webfinger.
OpenID Connect: clients MUST NOT use insecure webfinger.

I'm still fine either way around WebFinger going HTTPS-only, but I don't
think OpenID Connect or anybody else who wants HTTPS-only is a valid reason
to say that WebFinger must be so.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 29 Nov 2012 12:14:31 -0800

That seems like a reasonable client requirement.

On Thu, Nov 29, 2012 at 12:11 PM, William Mills <[email-masked]>wrote:

> So it might be worthwhile in that doc to state explicitly that there will
> be cases where HTTP SHOULD NOT be used and clients need to support an
> exclusively HTTPS mode?
>
> *From:* Paul E. Jones <[email-masked]>
> *To:* 'Evan Prodromou' <[email-masked]>; [email-masked]
> *Cc:* 'Brad Fitzpatrick' <[email-masked]>; [email-masked];
> [email-masked]
> *Sent:* Thursday, November 29, 2012 12:01 PM
>
> *Subject:* Re: [apps-discuss] Webfinger goals doc
>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Fri, 30 Nov 2012 09:20:24 -0800

On Fri, Nov 30, 2012 at 8:43 AM, Bob Wyman <[email-masked]> wrote:

>  An alternative to requiring a TLS encrypted link to read Bob's
> information would be to permit Bob to sign the documents he publishes. That
> would allow some level of integrity and authentication to be provided
> whether HTTP or HTTPS had been used. WebFinger says nothing about signing.
> Why not?
>

WebFinger says nothing about religion or tying shoelaces either.

I intend to use email addresses as the identifier for addressing people
(crazy!) and sharing in my Camlistore project, which means Camlistore can
use WebFinger to find other people's Camlistore servers and communicate
between them.  And in Camlistore, everything is signed.

Yet I'm not trying to push Camlistore into WebFinger.

---

From: Zellyn Hunter <[email-masked]>
Date: Fri, 30 Nov 2012 09:12:37 -0800

If I were trying to find Bob's public signing keys, given his email,
I'd have the same problem Webfinger solves. I suppose there could be a
signature in the response, generated by the server using its
certificate, but that's just the same as using TLS.

Zellyn

On Fri, Nov 30, 2012 at 8:43 AM, Bob Wyman <[email-masked]> wrote:
>>> vcard info, Bob’s profile page, etc.  It’s all public information.
>>>
>>>
>>>
>>> 2.0 does not need HTTPS, really. If I had my OpenID Provider endpoint URL in
>>> WF and somebody changed the value when I tried to access the service, I
>>> would know when the window opened that it’s not the correct site.  My OpenID
>>> login URL (https://openid.packetizer.com/login/) would present a page when I
>>> log in that I could clearly identify as bogus.
>>>
>>>
>>>
>>> Connect.
>>> > >> There was a lot of pressure put on the two groups to avoid having
>>> > >> two
>>> > >> discovery protocols.
>>> > >
>>> > >>>> WF
>>> > >>>>> draft-ietf-appsawg-acct-uri-
>>> > 01
>>> > >>>>> etc
>>> > >>>>>
>>> > >>>>> happy

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 30 Nov 2012 13:38:58 -0500

> libraries because they will do HTTP if HTTPS is not available.

Not necessarily.  Use a library that allows you to control fallback to HTTP
if security is an issue.

Paul

---

From: Bob Wyman <[email-masked]>
Date: Fri, 30 Nov 2012 13:48:21 -0500

> Yet I'm not trying to push Camlistore into WebFinger.
Thanks for your very kind comments. But, can you tell me, if I wanted to
publish a signed JRD using WebFinger, how would I do that?  The JRD
specification <http://tools.ietf.org/html/rfc6415#page-12> linked to the
latest WebFinger draft doesn't seem to address the issue.

---

From: John Bradley <[email-masked]>
Date: Fri, 30 Nov 2012 15:54:45 -0300

Tim,

In openID 2 RP can be tricked into directing people too phishing sites by compromising DNS and providing compromised XRDS information.

This also allows an attacker to login to a RP as any user who is not using a https: scheme claimed_id.

The problem is that IdP rolled out openID 2 without https and then discovered that switching to more secure identifyers for discovery caused a migration problem at the RP or didn't solve the problem because of the possibility of a downgrade attack.

It also caused interoperability issues with some IdP RP requiring https for security some IdP just don't work at some RP.  
This is perceived as broken by users, and not as increased flexibility.

I really think WF should be http or https only.   Trying to do both will probably satisfy no one and lead to lots of interoperability issues.

John B.

---

From: Nico Williams <[email-masked]>
Date: Fri, 30 Nov 2012 13:05:26 -0600

> Q1: How will implementors know which uses of WF require TLS? Do we leave that up to the use case? If TLS is a MUST, then no use of WF needs to specify HTTPS vs HTTP.

If I click on an acct: URL in a browser then I probably just want to
find out things like contact info (besides the name itself, which in
all likelihood is also a working e-mail address).

If OIDC needs a WF resource then it MUST use TLS.

> Q2: What is lost by making TLS a MUST? Let's get clear on the functionality we lose. There is extra the obvious extra effort in deploying TLS, and some domain owners will not be able to do it becau…

Making TLS a MUST by itself does nothing: at worst the requirement
will be ignored in some cases; at best some apps will use TLS but
without validating the server certificate.  Wishing ain't getting.

Nico
--

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 30 Nov 2012 14:08:11 -0500

Is there a standard for signing JSON documents?  I'm not aware of one, but
I'm not aware of many things, so that means nothing.

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bob Wyman
Sent: Friday, November 30, 2012 1:48 PM
To: WebFinger List
Cc: Joseph A Holsten; [email-masked]
Subject: Re: [apps-discuss] Webfinger goals doc

On Fri, Nov 30, 2012 at 12:20 PM, Brad Fitzpatrick <[email-masked]>
wrote:

---

From: John Bradley <[email-masked]>
Date: Fri, 30 Nov 2012 16:24:21 -0300

JOSE 

https://tools.ietf.org/wg/jose/

That is not a recommendation for signing the WF response.

There were options for signing XRD as part of that spec.

John B.

On 2012-11-30, at 4:08 PM, "Paul E. Jones" <[email-masked]> wrote:

> Is there a standard for signing JSON documents?  I’m not aware of one, but I’m not aware of many things, so that means nothing.
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Wyman
> On Fri, Nov 30, 2012 at 12:20 PM, Brad Fitzpatrick <[email-masked]> wrote:
>  An alternative to requiring a TLS encrypted link to read Bob's information would be to permit Bob to sign the documents he publishes. That would allow some level of integrity and authentication to be provided whether HTTP or HTTPS had been used. WebFinger says nothing about signing. Why not?
>  
> I intend to use email addresses as the identifier for addressing people (crazy!) and sharing in my Camlistore project, which means Camlistore can use WebFinger to find other people's Camlistore servers and communicate between them.  And in Camlistore, everything is signed.
>  
> Thanks for your very kind comments. But, can you tell me, if I wanted to publish a signed JRD using WebFinger, how would I do that?  The JRD specification linked to the latest WebFinger draft doesn't seem to address the issue.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 30 Nov 2012 14:42:00 -0500

Thanks.  I'll have to admit I've not read those, but I had seen them.  Duh.

I was aware that XRD had a means if signing documents.  From conversations
I've had with folks, it seemed few people cared to use that, though.  Did
anyone?

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of John Bradley
Sent: Friday, November 30, 2012 2:24 PM
To: [email-masked]
Cc: [email-masked]; 'Joseph A Holsten'
Subject: Re: [apps-discuss] Webfinger goals doc

JOSE 

John B.

 

 

On Fri, Nov 30, 2012 at 12:20 PM, Brad Fitzpatrick <
<mailto:[email-masked]> [email-masked]> wrote:

On Fri, Nov 30, 2012 at 8:43 AM, Bob Wyman < <mailto:[email-masked]>
[email-masked]> wrote:

On Thu, Nov 29, 2012 at 5:31 PM, John Panzer < <mailto:[email-masked]>
[email-masked]> wrote:

Thanks for your very kind comments. But, can you tell me, if I wanted to
publish a signed JRD using WebFinger, how would I do that?  The
<http://tools.ietf.org/html/rfc6415#page-12> JRD specification linked to the
latest WebFinger draft doesn't seem to address the issue.

---

From: John Bradley <[email-masked]>
Date: Fri, 30 Nov 2012 17:05:10 -0300

XRDS were commonly signed, but XRD never saw any deployment outside of WF.

It was designed to allow a non PKIX trust chain so that users could publish their own public keys.
Though that was XRI related.

It is unclear that it adds anything over TLS in the WF case.   XRI wasn't rooted in PKIX host names so it was a different and now irrelevant issue:)

The problem with JWE signed documents is that they need to be base64url decoded before you get to the JSON so you would need to publish signed and unsigned versions for clients wanting the two different versions.
That like almost anything could be made to work, but probably overcomplicates the simple case.

John B.

On 2012-11-30, at 4:42 PM, "Paul E. Jones" <[email-masked]> wrote:

> Thanks.  I’ll have to admit I’ve not read those, but I had seen them.  Duh.
>  
> I was aware that XRD had a means if signing documents.  From conversations I’ve had with folks, it seemed few people cared to use that, though.  Did anyone?
>  
> Paul
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley

---

From: Nico Williams <[email-masked]>
Date: Fri, 30 Nov 2012 15:37:15 -0600

> Q2: What is lost by making TLS a MUST? Let's get clear on the functionality we lose. There is extra the obvious extra effort in deploying TLS, and some domain owners will not be able to do it becau…

Actually, these are the wrong questions.  <impersonate name="EKR">The
right question is "what's the threat model?"</impersonate> :)

Will WF ever need confidentiality protection?  I doubt it, because
then we'd not be talking just about TLS, we'd be talking about
authentication of the WF client and about authorization.  Clearly WF
data is intended to be public, no?  So clearly we only need at most
integrity protection.  But why do we need integrity protection?
Because we don't know what all will be in a WF profile: it's just a
bag of stuff, and some clients will need to be able to trust some of
that stuff, and others won't.

So we have two choices: either always require integrity protection or
require that clients know when they need it.  The former is easy to
specify, but wishin' ain't gettin', so we need to consider the latter.
 But the latter isn't trivial either: suppose I'm following an acct:
URI for my bank so I can find phone numbers to call -- I'll really
want to know I'm calling my bank and not some phisher, but my WF
client may have no idea what I'm up to, and even if it labels data
fetched w/o integ. prot. as untrustworthy, the user may not notice.

So, at this point I'm not sure what to recommend :(  I hope I'm at
least helping us think this through.  Perhaps I'm being pessimistic
about requiring TLS?

Nico
--

---

From: James M Snell <[email-masked]>
Date: Fri, 30 Nov 2012 13:46:31 -0800

The bit of reality that seems to be missing in this whole discussion is
that TLS does not provide data integrity. e.g. The data could have been
compromised at the server. Saying it has to be TLS is not going to address
the real problem, and since WF is intended to provide non-confidential
public data, it's not clear exactly what problem requiring TLS is expected
to actually solve. What's really needed is integrity checking mechanism for
the data.. like [1] or [2].

[1] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07
[2] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02

If confidentiality becomes necessary at some point, implementations can add
in TLS optionally and provide authentication mechanisms as needed.

- James

On Fri, Nov 30, 2012 at 1:37 PM, Nico Williams <[email-masked]>wrote:

> > Q1: How will implementors know which uses of WF require TLS? Do we leave
> that up to the use case? If TLS is a MUST, then no use of WF needs to
> specify HTTPS vs HTTP.
> >
> > Q2: What is lost by making TLS a MUST? Let's get clear on the
> functionality we lose. There is extra the obvious extra effort in deploying
> TLS, and some domain owners will not be able to do it because of how their
> domain is CURRENTLY managed. What else?
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 30 Nov 2012 15:56:28 -0600

On Fri, Nov 30, 2012 at 3:46 PM, James M Snell <[email-masked]> wrote:
> The bit of reality that seems to be missing in this whole discussion is that
> TLS does not provide data integrity. e.g. The data could have been

I didn't really want to go there.  WF could embed PKIX signatures,
say, but I bet no one here wants to got there.  OTOH, you're quite
right: we should want to authenticate the data, not the server.

Nico
--

---

From: John Bradley <[email-masked]>
Date: Fri, 30 Nov 2012 19:08:21 -0300

Yes knowing the data is authentic is what we are after.

The problem with signing is using what key?

We can invent a replacement for PKIX CA or use a TLS certificate to sign the WF documents.

There were discussions around this in the XRD WG.

A JWS signed by the server's certificate is more complicated and arguably no more authentic than retrieving it directly over TLS with certificate checking.

The only advantage the JWS has is that it can be passed on to a third party with the integrity intact.  Though I don't think that is a use case for WF.

Yes there are interesting things you might do with self signed, but I don't thick that serves Connect or the other protocols well.

John B.

---

From: Nico Williams <[email-masked]>
Date: Fri, 30 Nov 2012 16:15:50 -0600

> The problem with signing is using what key?

DKIM!

:)

> We can invent a replacement for PKIX CA or use a TLS certificate to sign the WF documents.

Well, to be pedantic you'll probably want a separate EKU for this, and
probably also different keys/certs for this.

> The only advantage the JWS has is that it can be passed on to a third party with the integrity intact.  Though I don't think that is a use case for WF.

Maybe.  Think of layed architectures.

> Yes there are interesting things you might do with self signed, but I don't thick that serves Connect or the other protocols well.

No, let's forget self-signed certs (and bare keys).  It's not useful here.

Nico
--

---

From: Bob Wyman <[email-masked]>
Date: Fri, 30 Nov 2012 17:17:59 -0500

On Fri, Nov 30, 2012 at 5:08 PM, John Bradley <[email-masked]> wrote:

> A JWS signed by the server's certificate is more complicated and arguably
> no more authentic than retrieving it directly over TLS with certificate
> checking.
>
> The only advantage the JWS has is that it can be passed on to a third
> party with the integrity intact.  Though I don't think that is a use case
> for WF.
>
Passing data on to third parties is not a use case that has been discussed
much, if at all, so far. But, perhaps we should. I suggest that "*Data
wants to be aggregated!*" and, we're undoubtedly going to find folk that
build applications that invert collections of WebFinger acct: -> Attributes
mappings and produce Attributes -> acct: mappings. Thus, we'll see folk
offering the ability to query for acct:'s that claim to be in some
geo-region or all acct:'s for folk with blogs on Blogger, or that work at
Example Co. or that have some particular hobby... We might see prospective
search applications that alert you "instantly" whenever "interesting" new
or modified WebFinger data is discovered. Do we care?

Is WebFinger aggregation something that needs to be discussed at this
point? Is there anything we should do to either encourage or discourage it?

> Yes there are interesting things you might do with self signed, but I
> don't thick that serves Connect or the other protocols well.
>
> John B.
>

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 30 Nov 2012 14:28:10 -0800

> fetched w/o integ. prot. as untrustworthy, the user may not notice.

You're right on target. In fact, I have made both proposals here:

1. Mandatory TLS
2. Mandatory-to-implement configuration for no-HTTP fallback.
Essentially in this case the inputs to a WF client are an email
address and a boolean to say whether fallback is allowed. May not be
pleasant to write in a spec but I don't think it's out of scope or
even too original as far as specifications go (i.e., specify
compliance behaviors that go beyond wire format).

Instead, what I have generally heard as feedback is various forms of
'fallback is allowed but there are considerations that go in a
security section'. As I explained, there is no guarantee (and in fact
I expect that it will not be the result in general) that WF
implementors will make it easy or even possible for applications to
disable HTTP fallback for the clients that require security. In my
view that makes it impractical for clients that need security to use
common implementations of WF, at which point security applications are
better off inventing new standards than adopting WF. Maybe WFS. :)

-- 
--Breno

---

From: Tim Bray <[email-masked]>
Date: Fri, 30 Nov 2012 15:09:59 -0800

On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros <[email-masked]> wrote:

> pleasant to write in a spec...

OK, let's make this concrete, I don’t think it’s that unpleasant to spec
out:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

In draft-ietf-appsawg-webfinger-06

- Remove the second paragraph of Section 5.1, which begins “Clients MUST
first attempt a query...

Introduce a new section 5.2 and bump up the other sections, as follows

5.2 Use of HTTPS

WebFinger client software MUST accept as input a boolean parameter which
for the purposes of this discussion will be referred as "allow-fallback".

WebFinger client software MUST attempt to retrieve /.well-known/webfinger
using the HTTPS protocol.  If an HTTPS connection is made, and the server
has an invalid certificate, or returns an HTTP status code indicating an
error, the client software MUST report an error and cease attempting to
retrieve the resource.

If the WebFinger client software is unable to establish an HTTPS connection
to the server, behavior depends on the value of the allow-fallback
parameter.  If the value of allow-fallback is true, the client software MAY
fall back to unencrypted HTTP in an attempt to retrieve
/.well-known/webfinger.  If allow-fallback is false, client software MUST
report an error and cease attempting to retrieve the resource.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 30 Nov 2012 15:15:37 -0800

On 30 November 2012 15:09, Tim Bray <[email-masked]> wrote:
> WebFinger client software MUST accept as input a boolean parameter which for
> the purposes of this discussion will be referred as "allow-fallback".

I suspect that many implementations will choose to disregard this
clause in favour of fixing the value to "false".
<<<
WebFinger client software MAY accept as input a boolean parameter,
which for the purposes of this discussion will be referred /to/ as
"allow-fallback".  Otherwise, WebFinger client software MUST assume
that allow-fallback is false.

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 30 Nov 2012 15:18:43 -0800

+1

-- 
--Breno

---

From: Tim Bray <[email-masked]>
Date: Fri, 30 Nov 2012 15:25:09 -0800

Or, a little more smoothly. “If the value of allow-fallback is not
explicitly specified, WebFinger software MUST assume the value is false.”

---

From: Nico Williams <[email-masked]>
Date: Fri, 30 Nov 2012 17:25:55 -0600

On Fri, Nov 30, 2012 at 4:17 PM, Bob Wyman <[email-masked]> wrote:
> much, if at all, so far. But, perhaps we should. I suggest that "Data wants
> to be aggregated!" and, we're undoubtedly going to find folk that build
> applications that invert collections of WebFinger acct: -> Attributes
> search applications that alert you "instantly" whenever "interesting" new or
> modified WebFinger data is discovered. Do we care?

Signing data is not incompatible with aggregating it: the aggregator
has to sign the aggregations and you have to trust the aggregator.
Or, if the aggregation gets unwieldy, or if the aggregator functions
as an index, then you don't sign anything at the aggregator and you
still have to trust it.

> Is WebFinger aggregation something that needs to be discussed at this point?

Probably.  Suppose WF succeeds wildy: then there will be WF crawlers
that build directories.  You know, like search engines.  Presumably
the directory will remember the original URLs and provide them for
such clients that want to get the whole thing and validate signatures.

> Is there anything we should do to either encourage or discourage it?

We shouldn't discourage this.  We should only document security
considerations of this, namely that a WF client should validate
origins when it needs integrity protection (regardless of whether we
authenticate data or servers).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 30 Nov 2012 17:36:37 -0600

I think the right thing to do is to leave WF signing for later and
rely on TLS for integrity protection where it's needed.  I doubt we're
prepared to start doing JWE signatures here, right now.

---

From: Blaine Cook <[email-masked]>
Date: Fri, 30 Nov 2012 16:59:16 -0700

http://tools.ietf.org/html/rfc6797

---

From: William Mills <[email-masked]>
Date: Fri, 30 Nov 2012 16:16:52 -0800 (PST)

I am a +1 on the concept here, +1 also on failing safe rather than open.

Does the term "fallback" here mean "fall back to HTTP without validity checks"?  TLS is the one we're talking about but other methods are possible.  I think with very small language tweaks this can be generic enough to need no re-write when something other than TLS provides the same guarantees.

>To: Martin Thomson <[email-masked]> 
>Cc: "[email-masked] Discuss" <[email-masked]>; "[email-masked]" <[email-masked]>; Joseph Holsten <[email-masked]> 
>Sent: Friday, November 30, 2012 3:18 PM
>Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP
>