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:[email protected]]
Sent: Thursday, April 12, 2012 3:41 PM
To: Mike Jones
Cc: Hannes Tschofenig; [email protected] WG
Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
On 12 April 2012 17:51, Mike Jones
<[email protected]<mailto:[email protected]>> 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}/[email protected]/<http://[email protected]/>"|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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
