Re: [apps-discuss] Webfinger goals doc

[Melvin Carvalho <[e-mail]>]

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

> I agree that TLS will be hard to impossible for many people off their main
> domain.  That was one of the reasons for having a subdomain so that you
> could delegate it via DNS to a server that can support it.
>
> That idea seems to be dead however.
>
> The question is if publishing a WF document that can't safely support a
> number of protocols is:
> a) worth it.
> b) may encourage many RP to ignore the TLS requirement for some protocols
> and create unmanageable security issues.
>
> Letting clients do the wrong thing is hard to put back in the box from
> experience.
>
> The safest thing is to only allow the WF service over TLS.
>
> I know that in opposition to the social linking use case.  That is one of
> the problems of trying to solve two similar but not the same problems with
> one solution.
>
> This is an important issue and we should close on it one way or the other.
>   I hate having to have clients try https and fall back to http for some
> relations.   I see it going very wrong sometimes.
>

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


>
> John B.
>
>
>
> On 2012-11-28, at 5:41 AM, Joseph Anthony Pasquale Holsten <
> [e-mail]> wrote:
>
> > Big folks will have no problem. Privileged folks with vanity domains
> like myself will get over it.
> >
> > The main use case it screws up is delegation, since you can't bootstrap
> from a cheap domain.
> >
> > On 2012-11-28, at 00:34 , "Paul E. Jones" <[e-mail]> wrote:
> >
> >> Dick,
> >>
> >> Here’s my list of reasons why we should not mandate HTTPS:
> >> 1) TLS certificates are difficult to deploy by many
> >> 2) Many hosting providers do not support TLS because they do not
> support the relatively new SNI extensions for TLS (even my own server did
> not support SNI until recently and some deployed browsers still do not)
> >> 3) TLS certificates cost more money than the domain name.  This is a
> serious issue for many, especially in developing countries.  Few people
> support DNSSEC and RFC 6698.  If the world supported DNSSEC and people
> could create self-signed certificates, TLS could be widely embraced by
> everyone, I suspect.
> >> 4) If everything I’m sharing via WF is accessible via HTTP, what’s the
> point of protecting the WF query with HTTPS?  It definitely makes sense for
> OpenID or other sensitive services, but not for more “public” applications
> like “where’s Paul’s blog” and “where’s Paul’s avatar”?
> >>
> >> Are there encryption restrictions in some countries that make TLS
> illegal?  If so, we could add that as reason #5.
> >>
> >> All that said, I don’t care if it was mandated, but I just don’t see
> the reason for it in some instances and I am concerned that it will limit
> deployment of the service.
> >>
> >> If we could get the world to implement DNSSEC and RFC 6698… problems
> solved.  By the time that is done, SNI issues will be long gone, too.
> >>
> >> Paul
> >>
> >> From: [e-mail] [mailto:
> [e-mail]] On Behalf Of Dick Hardt
> >> Sent: Wednesday, November 28, 2012 12:04 AM
> >> 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.
> >>      • HTTPS-only vs HTTPS-recommended
> >>              • HTTPS-only:
> >>                      • PRO: secure
> >>                      • PRO: simpler for clients (one round-trip)
> >>                      • CON: hard for some servers to setup (config,
> certs, etc)
> >>              • HTTPS-recommended:
> >>                      • CON: added client complexity.  But at least good
> clients can opportunistically fetch both in parallel and only use HTTP if
> they’re feeling trusting, once they see the HTTPS one fails. If HTTPS
> succeeds, no added latency.
> >>                      • PRO: easier
> >>              • Decision: HTTPS-recommended.  Clients may choose to only
> do HTTPS, as can servers, which means in practice almost all servers will
> probably only be HTTPS.
> >>              • Debate: this seems inconsistent with our policy of
> caring about clients and simplicity more than servers.  And it seems like a
> failure to decide, since we say both are optional for either party, counter
> to the assumption above that specs need requirements for either client or
> server.
> >>              •
> >>
> >
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>