IETF Logo Mail Archive

[apps-discuss] Looking at Webfinger

Mark Nottingham <mnot@mnot.net> Tue, 03 July 2012 05:47 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7CA21F8771 for <apps-discuss@ietfa.amsl.com>; Mon, 2 Jul 2012 22:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.404
X-Spam-Level:
X-Spam-Status: No, score=-105.404 tagged_above=-999 required=5 tests=[AWL=-2.805, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR9vTgiHmuPg for <apps-discuss@ietfa.amsl.com>; Mon, 2 Jul 2012 22:47:10 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCB121F8768 for <apps-discuss@ietf.org>; Mon, 2 Jul 2012 22:47:10 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0D2C622E1F4 for <apps-discuss@ietf.org>; Tue, 3 Jul 2012 01:47:10 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 03 Jul 2012 15:47:07 +1000
Message-Id: <F80C8C9C-7AB8-4B7E-BFD2-4D69499D21A1@mnot.net>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
Subject: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2012 05:47:11 -0000

I've pretty much ignored the whole webfinger / acct: / SWD discussion (too much!). However, since it's apparent it may soon become Real, I had a look.

In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Thought It Would Be." :)

With that in mind, a few questions / comments (I'll resist going into editorial matters, for the time being):

* First and foremost, why use host-meta? What value does adding this extra step to the dance bring, beyond "We've defined it, therefore we must use it?"

As I think I've said many times before, the whole point of a .well-known URI is to group like uses together, to avoid having a "dictionary" resource that gets bloated with many application's unrelated data, thereby overburdening clients with too much information (especially when they're constrained, e.g., mobile).

As such, host-meta is a spectacularly bad example of a well-known URI. Defining a end-all-be-all well-known-URI kind of removes the point of having a registry, after all...

Instead, why not just define a NEW well-known URI for user data? That has a more constrained scope, and saves one round trip (or more). E.g.,

GET /.well-known/webfinger?user=bob%40example.com HTTP/1.0
Host: example.com

I.e., let webfinger define the URI template to use. Yes, some implementations might want to come up with crazy URIs, but is that really a problem we want to solve?

Astute observers will notice that this approach removes the need for an ACCT URI scheme (at least here).
 

* What's the fascination with XRD and JRD? These specifications seem to be creeping into IETF architecture; first it was in a pure security context, but now folks are talking about using them in a much more generic way, as a cornerstone of what we do. As such, I think they deserve a MUCH closer look, especially since we're defining things with "Web" in their name when the W3C has already defined solutions in this space.

Thanks,


--
Mark Nottingham   http://www.mnot.net/

v2.23.0 | Report a Bug | By Email