I look forward to working with Blaine, Mike and others interested on the apps list.
I anticipate being able to find a way forward. Regards John B. On 2012-04-15, at 10:56 AM, Melvin Carvalho wrote: > > > On 15 April 2012 08:21, Eran Hammer <e...@hueniverse.com> wrote: > 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. > > > As stephen suggests, could we possibly continue this fascinating discussion > on apps discuss? > > I know people are passionate about this issue, and that's a positive thing. > > But I think it probably would be most productive, if we could all try to keep > personal attacks to a minimum. > > > > > 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] > Sent: Thursday, April 12, 2012 3:41 PM > To: Mike Jones > Cc: Hannes Tschofenig; 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> 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/"|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 or 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
