Re: [apps-discuss] Webfinger goals doc

[John Panzer <[e-mail]>]

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" <[e-mail]> 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.****
>
> ** **
>
> 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:* [e-mail] [mailto:[e-mail]] *On
> Behalf Of *John Panzer
> *Sent:* Thursday, November 29, 2012 3:08 PM
> *To:* [e-mail]
> *Cc:* Joseph Holsten; [e-mail]
> *Subject:* Re: [apps-discuss] Webfinger goals doc****
>
> ** **
>
> On Thu, Nov 29, 2012 at 11:47 AM, Paul E. Jones <[e-mail]>
> 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
> 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
>
> > -----Original Message-----
> > From: [e-mail] [mailto:apps-discuss-****
>
> > [e-mail]] On Behalf Of Joseph Holsten
> > Sent: Thursday, November 29, 2012 1:53 PM
> > To: [e-mail]; [e-mail]
> > Subject: Re: [apps-discuss] Webfinger goals doc
> >
> > 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
> >
> > On Nov 29, 2012, at 10:18, Breno de Medeiros <[e-mail]> wrote:
> >
> > > On Thu, Nov 29, 2012 at 9:41 AM, John Bradley <[e-mail]>
> > wrote:
> > >> Blaine,
> > >>
> > >> 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
> > >> discovery protocols.
> > >
> > > 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.
> > >> 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.
> > >
> > > 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.
> > >
> > >>
> > >> John B.
> > >>
> > >> On 2012-11-29, at 2:24 PM, Blaine Cook <[e-mail]> wrote:
> > >>
> > >> 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.
> > >>
> > >> On Nov 29, 2012 9:56 AM, "Breno de Medeiros" <[e-mail]>
> wrote:
> > >>>
> > >>> On Thu, Nov 29, 2012 at 4:49 AM, Evan Prodromou <[e-mail]>
> > wrote:
> > >>>> -1
> > >>>>
> > >>>> 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.
> > >>>
> > >>>>
> > >>>> I suggest sticking this in security considerations.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> Breno de Medeiros <[e-mail]> wrote:
> > >>>>
> > >>>> TLS downgrade attacks means that you always run a server over HTTP
> > >>>> even when you don't provided that the client will fall back to HTTP
> > >>>> when HTTPS port is unavailable. The only difference is that the
> > >>>> attacker is doing the HTTP hosting instead.
> > >>>>
> > >>>> If the library for WF is compliant then it will accept downgrade
> > >>>> attacks for interoperability. Unless the spec mandates that
> > >>>> compliant client implementations must support configurable option
> > >>>> to indicate if only HTTPS is allowed (technically the inputs for WF
> > >>>> would be an email address and some security flag with a default
> > >>>> value that SHOULD be modifiable) we can't expect that compliant  WF
> > >>>> clients will expose this configuration. And if not we can't use WF
> > >>>> as a building block for authentication protocols. It is just a
> > >>>> violation of layering if OpenIDConnect will invoke the WF client
> > >>>> and then try to second guess what the HTTP client that was wrapped
> > >>>> within the WF client did during discovery.
> > >>>>
> > >>>> On Nov 28, 2012 9:44 PM, "Paul E. Jones" <[e-mail]>
> > 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: [e-mail]
> > >>>>> [mailto:[e-mail]]
> > >>>>> On Behalf Of Brad Fitzpatrick
> > >>>>> Sent: Wednesday, November 28, 2012 12:28 AM
> > >>>>> To: [e-mail]
> > >>>>> Cc: [e-mail]
> > >>>>> 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
> > >>>>> <[e-mail]>
> > >>>>> wrote:
> > >>>>>
> > >>>>> +1
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> From: [e-mail]
> > >>>>> [mailto:[e-mail]]
> > >>>>> On Behalf Of Dick Hardt
> > >>>>> Sent: Tuesday, November 27, 2012 9:04 PM
> > >>>>> To: [e-mail]
> > >>>>> Cc: [e-mail]
> > >>>>> 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
> > >>>>> <[e-mail]>
> > >>>>> 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-E6x7VDtmEaC48SendGW
> > >>>>> Qe7XcY99pjQWs/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 "[e-mail]", find a
> > >>>>> machine-readable metadata document.
> > >>>>>
> > >>>>> background: since the death of the "finger" protocol (from which
> > >>>>> webfinger
> > >>>>> gets its name), email-looking identifiers like "[e-mail]"
> > 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 "[e-mail]" 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.
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> apps-discuss mailing list
> > >>>>> [e-mail]
> > >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> > >>>>>
> > >>>>> ...
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> --Breno
> > >>> _______________________________________________
> > >>> apps-discuss mailing list
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/apps-discuss
> > >>
> > >> _______________________________________________
> > >> apps-discuss mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/apps-discuss
> > >
> > >
> > >
> > > --
> > > --Breno
> > _______________________________________________
> > apps-discuss mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> ** **
>