Re: [apps-discuss] Webfinger goals doc

[Joseph Holsten <[e-mail]>]

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-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 “[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