Tone aside, this is not the first time you distorted process and technical facts to suit your goals. Just look up some of our exchanges from a year ago and the transcript of the Prague meeting for highlights.
EH From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, April 13, 2012 9:18 AM To: Blaine Cook Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Hi Blaine. I must admit, I’m pretty surprised by the tone of your reply. I’ll say up front that I have absolutely no problem with anyone disagreeing with me on a technical or tactical basis. If you think I’m wrong, have at it. But I am pretty shocked that you would decide to impugn my motives. We’ve only met twice and both times I thought we had really useful and productive discussions about how to move digital identity on the Web forward – something I believe that we’re both passionate about. You don’t really know me, though, which is apparent from your remarks below. I believe that those who have worked with me for years would vouch that I am a forthright and evenhanded standards participant who listens to all points of view, tries to build a consensus that works, and produce quality results. I thought about your note overnight and whether I should reply at all. I’m fine with give and take, but I believe that I need to say that if you read what you wrote below, I think you’ll agree that the tone you used was counter-productive and an apology is in order. -- Mike P.S. I’ll address your technical points below in a separate note at some point – some I agree with and some I don’t. But I felt that I needed to address my motives being questioned separately and first. I hope we can both come out of this with a better understanding of one another and work together towards the important goals that we both share. From: Blaine Cook [mailto:rom...@gmail.com]<mailto:[mailto:rom...@gmail.com]> Sent: Thursday, April 12, 2012 3:41 PM To: Mike Jones Cc: Hannes Tschofenig; oauth@ietf.org<mailto:oauth@ietf.org> WG Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) On 12 April 2012 17:51, Mike Jones <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>> wrote: Thanks for asking these questions Hannes. I'll first provide a brief feature comparison of Simple Web Discovery and WebFinger and then answer your questions. FEATURE COMPARISON RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: SWD returns the resource location(s) for a specific resource for a specific principal. WebFinger returns all resources for the principal. The example at http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2 "Retrieving a Person's Contact Information" is telling. The WebFinger usage model seems to be "I'll get everything about you and then fish through it to decide what to do with it." The protocol assumption that all WebFinger information must be public is also built into the protocol where the CORS response header "Access-Control-Allow-Origin: *" is mandated, per http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7. The privacy characteristics of these approaches are very different. (It's these very same privacy characteristics that led sysadmins to nearly ubiquitously disabling the fingerd service!) Particularly for the OAuth use cases, narrow, scoped, and potentially permissioned responses seem preferable. This is absolutely false. SWD provides no privacy whatsoever. SWD makes it somewhat harder to crawl large numbers of profiles, but it does not incorporate any real security, and any attempt to suggest that it does is misleading and deceptive. Webfinger, like any good HTTP service, is designed to allow access control using appropriate means. That access control should not be *bound* to the protocol, in the same way that HTTP does not have any REQUIRED access control mechanisms, since doing so would severely restrict future usage of a core protocol. FUD has no place in a discussion of the technical and social merits of a protocol. For what it's worth, my intent with webfinger *from day one, nearly four years ago*, has been to provide permissioned profile data *using EXISTING* (or new, where appropriate or necessary, based on *running code and deployment EXPERIENCE*) access control mechanisms for profile data. The idea that there is ONE view of the data is patently false. For example, depending on who is requesting my profile data, I might return different contact telephone numbers, and this behaviour is completely feasible using webfinger. DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURITY: WebFinger is built on a "document model", where a single document is returned that contains multiple resources for a principal. SWD is built on an "API model", where the location(s) of a particular resource for a principal are returned. The problem with the document model is that different parties or services may be authoritative for different resources for a given principal, and yet all need the rights to edit the resulting document. This hurts deployability, because document edits then need to be coordinated among parties that may have different rights and responsibilities, and may have negative security implications as well. (Just because I can change your avatar doesn't mean that I should be able to change your mail server.) WS-* was built on an API model, and that worked out very well. APIs and documents on the web are the same thing; how you represent them behind the scenes is up to you, and that's been a core principle of the web since shortly after its inception. Suggesting otherwise profoundly misunderstands how implementation of web services happens. SWD says nothing of how to update profile data, so the security concerns here are a total red herring. REDIRECT FUNCTIONALITY AND DEPLOYABILTY: SWD includes the ability to redirect some or all SWD requests to another location (possibly depending upon the specific resource and principal parameters). Deployers hosting numerous sites for others told the SWD authors that this functionality is critical for deployability, as it means that the SWD server for a domain can live in a location outside the domain. WebFinger is lacking this functionality. Given that OAuth is likely to be used in hosted environments, this functionality seems pretty important. Umm, I'm not even sure what to say to this. host-meta is a static file that points to a profile server (generally expected to be a dynamic "API" server) that can be hosted on any domain. The fact that you're suggesting that this core piece of webfinger functionality is *missing* seriously undermines my belief that you're acting in good faith, Mike. NUMBER OF ROUND TRIPS: WebFinger discoveries for user information normally require both a host-meta query to retrieve the template and then a second query to retrieve the user's information. This functionality is achieved in a single SWD query. ... at the cost of greater client complexity. A webfinger lookup may be implemented with the following trivial shell script: curl -s http://example.com/.well-known/host-meta|awk "/lrdd/,/template/"|tr -d '\n'|sed -e "s/^.*template='\([^']*\)'.*$/\1/"|sed -e "s/{uri}/u...@example.com/<http://u...@example.com/>"|xargs curl -s so long as your HTTP client properly follows redirects, this approach will always produce a valid webfinger profile, and if proper caching is implemented, will only make requests to /.well-known/host-meta when the document is expired. SWD, on the other hand, implements a non-HTTP redirect mechanism, meaning that optimal caching rules can't be obeyed by standard HTTP clients. Moreover, SWD *requires* conditionals by presenting one code path for the non-redirect case and one code path for the immediate response case. The complexity for client implementations should be foremost in this work, and the decisions made by SWD don't indicate to me that these factors have been considered. Indeed, I wonder why is SWD designed to pre-optimize for presumed scaling challenges that are faced by only the very largest providers (namely, the fact that two lookups are required for webfinger instead of one in the ideal case), when: 1. Those scaling challenges are simply not real threats. host-meta can be cached using existing HTTP mechanisms 2. The fact that SWD only returns one service definition per request means that more than one request will often be required to obtain the necessary information about a user. 3. The chances that Google or Microsoft will host dynamic response SWD services on the gmail.com<http://gmail.com> or hotmail.com<http://hotmail.com> domains is next to nil, and will therefore need to issue redirects anyways. For smaller providers (e.g., personal domains hosted in static or rigid environments), hosting a SWD server at /.well-known/simple-web-discovery may be challenging indeed. Thus, all clients will need to support the redirect behaviour natively, and for those who write specs but not code, it is *more* complex to have conditional behaviour like that than to have a defined flow that is always followed. Further, it's more complex for small service providers to host static content that is invariant and properly cached (e.g., by transparent proxy caches like varnish and squid) when CGI parameters are appended, as with SWD. XML AND JSON VERSUS JSON: WebFinger specifies both XML and JSON support, whereas SWD specifies only JSON. The SWD position is that it's simpler to specify only one way of doing the same thing, with JSON being chosen because it's simpler for developers to use than XML - the same decision as made for the OAuth specs. Webfinger only used XRD in the first place to satisfy the OpenID community. This is infuriating format-fetishism, and misses the point entirely. JSON is preferred, and I, for one, would happily modify host-meta and webfinger to require JSON is people feel this strongly about it. DEFINING SPECIFIC RESOURCES: Besides specifying a discovery protocol, WebFinger also defines specific resources and kinds of resources to be used with that protocol: the "acct" URI scheme, the "acct" Link Relation. These should be considered on their own merits, but logically should be decoupled from the discovery protocol into a different document or documents. It's not clear these features would be needed in OAuth contexts. I have long argued against the acct URI, but the consensus-based approach of the IETF has over-ridden me on that one. If you feel similarly, you are free to voice that opinion. It shocks me that you're saying that the OAuth WG shouldn't consider host-meta/webfinger because it defines something that isn't of interest to the OAuth WG. The whole point of my argument at the WG meeting in Paris was that Webfinger and SWD-like protocols are of such consequence to the web at large that the interests of the OAuth WG should not be used to define the parameters for their behaviour. I'm more convinced that you're using your power within this WG to have SWD rubber-stamped so that you can ship OpenID Connect as you've defined it. QUESTIONS 1) Aren't these two mechanisms solving pretty much the same problem? They are solving an overlapping set of problems, but with very different privacy characteristics, different deployability characteristics, different security characteristics, and somewhat different mechanisms. Again, I totally disagree with your assessment here, Mike. 2) Do we need to have two standards for the same functionality? No - Simple Web Discovery is sufficient for the OAuth use cases (and likely for others as well). I agree with this – since SWD is an explicit (though unstated) fork of Webfinger, there is no need to have two standards. 3) Do you guys have a position or comments regarding either one of them? The functionality in Simple Web Discovery is minimal and sufficient for the OAuth use cases, whereas some of the functionality and assumptions made in WebFinger are harmful, both from a privacy and from a deployability perspective. SWD should proceed to standardization; WebFinger should not. I believe Mike has made misleading statements regarding the privacy and deployability perspective, either intentionally, or because he fundamentally does not understand the security or deployment scenarios that motivate the decisions. In summary: 1. I believe that SWD and Webfinger are essentially the same protocol, with different authors names at the top. 2. I don't care which one "wins", though I think that SWD's use of HTTP is questionable, and that the claims of privacy and deployability advantages offered by SWD are overblown and potentially misleading. 3. My concerns about SWD apply equally to any concerns anyone would leverage against Webfinger. 4. Which is to say, I think we should have one protocol that is defined by an open discussion. 5. We've had an open discussion on the webfinger list and apps-discuss and in the context of host-meta that the SWD folks have chosen not to engage with for the past three years. 6. The OAuth list is *not* the place for this discussion to happen, just so that Mike Jones can quickly push a spec through the formal process using a list that has well-known problems of too-high mail volume and whose topic is unrelated to the goals of Webfinger/SWD. This is important enough to get right, and getting it wrong will almost certainly lead to years of incompatibility and frustration, as Stephen mentioned. I encourage everyone involved to take this seriously, let go of personal attachment and presumptions of dependencies, and consider this work in an appropriate context (with an inclusive, not exclusive community). b.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
