Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

[Blaine Cook <[e-mail]>]

On 12 April 2012 17:51, Mike Jones <[e-mail]> 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}/
[e-mail]/"|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.