[webfinger] Simplifying and unjamming WebFinger

Tim Bray <tbray@textuality.com> Fri, 14 June 2013 17:16 UTC

Return-Path: <tbray@textuality.com>
X-Original-To: webfinger@ietfa.amsl.com
Delivered-To: webfinger@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1028C21F9AF7 for <webfinger@ietfa.amsl.com>; Fri, 14 Jun 2013 10:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.432
X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Bq+D5-xdahz2 for <webfinger@ietfa.amsl.com>; Fri, 14 Jun 2013 10:16:34 -0700 (PDT)
Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1073B21F9B42 for <webfinger@ietf.org>; Fri, 14 Jun 2013 10:16:33 -0700 (PDT)
Received: by mail-vb0-f43.google.com with SMTP id e12so619829vbg.16 for <webfinger@ietf.org>; Fri, 14 Jun 2013 10:16:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=F74CT4KYwu7jdXSdKzNTWIvQ5pV6O2GO0bK2SYd8S5g=; b=TjPnWuQLPwh8G+g0ltAe1ySKN94F1FwyPGdC91bN4WKD8hgfsI0srqpsedLq4JkRyf qIP9p/vT9QTB9rO2tVICCdNUdGk4+XuizuWCmCHcb+t6CwRwil7rtWVpEur8dv+scSuy zWgsplGehyLNY7bnwqftbc+YjLKmLTYKpy/TJCBcRnAcl9V8RTHcAM2D8Q/mBzxsAYyD CIReleP9FN3BEf4keVJa3FvM4lFiZXQbzRSGzf5U/gvJZ+sZc00Bhyi3eFl0kjpolVhp Kg4h7LaFl+UzUkDq04d0ajh7wrqCIk0D1EQaI07ASpNWRS4ymCnIR7w+Pk3gs2/ZVrmf xb0Q==
MIME-Version: 1.0
X-Received: by with SMTP id br10mr1058080vdb.103.1371230192815; Fri, 14 Jun 2013 10:16:32 -0700 (PDT)
Received: by with HTTP; Fri, 14 Jun 2013 10:16:32 -0700 (PDT)
X-Originating-IP: []
Date: Fri, 14 Jun 2013 10:16:32 -0700
Message-ID: <CAHBU6is9Fq8YkT=FFCa7qTn-=cFH75JCn6_uSahuhqb7AvbJCg@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "webfinger@ietf.org" <webfinger@ietf.org>
Content-Type: multipart/alternative; boundary=20cf307f37d68c656004df206863
X-Gm-Message-State: ALoCoQlRE+nHp/dgDqxWEw1pRKbzK+nsCqPgRNUCX2r6+SgNjnYs249cau7noCkPAOVsO8jDo1Hr
Subject: [webfinger] Simplifying and unjamming WebFinger
X-BeenThere: webfinger@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <webfinger.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webfinger>, <mailto:webfinger-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/webfinger>
List-Post: <mailto:webfinger@ietf.org>
List-Help: <mailto:webfinger-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webfinger>, <mailto:webfinger-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2013 17:16:40 -0000

I’ve been following the endless back and forth on this with a feeling of
despair... people seem to be talking back and forth past each other.  Lots
of people think there are problems, Paul thinks there are no problems.

Back in the day, when I first heard of WebFinger, it was the simplest thing
imaginable: Put in an email address and get back some pointers to IDPs or
whatever.  Somewhere along the way, it morphed into getting metadata about
any Resource.  Which meant that you couldn’t just use an email address, you
had to turn it into a URI.

And thus the problem in the spec.  You have to figure out which URI scheme
to use (acct:, mailto:, device:) and this will affect the output in ways
that have to be specified in Other Places.

But I don’t have a general-purpose problem about wanting metadata for
arbitrary URIs.  I have several immediate pressing problems for retrieving
metadata about  email addresses.   The former is now seriously getting in
the way of the latter.

So, how about a WebFinger light, in which the form of the query is


Which yields a JRD.  You could still have the rel-selection and so on. It
would be easy to understand. It would be self-contained. The draft would
shrink in size dramatically. It would be instantly usable by OpenID
Connect.  It would probably sail through the IESG.