Re: [apps-discuss] Webfinger goals doc

[Zellyn Hunter <[e-mail]>]

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 <[e-mail]> wrote:
>
>
>
> On Thu, Nov 29, 2012 at 5:31 PM, John Panzer <[e-mail]> 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
>
>>
>> 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
>>>
>>>
>
>