Re: [apps-discuss] Webfinger goals doc

[John Bradley <[e-mail]>]

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.

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.
>> 		•  
>> 
>