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
