Re: [apps-discuss] Webfinger

Eran Hammer-Lahav <eran@hueniverse.com> Sat, 19 November 2011 15:03 UTC

Return-Path: <eran@hueniverse.com>
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 2F8ED21F8511 for <apps-discuss@ietfa.amsl.com>; Sat, 19 Nov 2011 07:03:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Level:
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 1c6aYb-3-bTg for <apps-discuss@ietfa.amsl.com>; Sat, 19 Nov 2011 07:03:24 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id A1D3D21F8500 for <apps-discuss@ietf.org>; Sat, 19 Nov 2011 07:03:23 -0800 (PST)
Received: (qmail 8448 invoked from network); 19 Nov 2011 15:03:22 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Nov 2011 15:03:22 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 19 Nov 2011 08:03:21 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "Paul E. Jones" <paulej@packetizer.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Date: Sat, 19 Nov 2011 08:03:05 -0700
Thread-Topic: [apps-discuss] Webfinger
Thread-Index: AcySiOHWZHrUUWZ0SIe1B4nUS477zwUQENTg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com>
In-Reply-To: <032101cc9288$e3a06910$aae13b30$@packetizer.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234526735EDEDP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: Joseph Smarr <jsmarr@google.com>
Subject: Re: [apps-discuss] 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: Sat, 19 Nov 2011 15:03:26 -0000

This is a good start. Some feedback and nits:


1.       The protocol flow is incorrect and needs to be adjusted based on the final host-meta specification (RFC 6415). Namely, WebFinger must follow section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger providers to support the JRD format. This does not preclude using XRD (XML) but it will ensure that every compliant WebFinger implementation provides full JSON support which is much more likely to be adopted. This is something we could not do in host-meta due to the late stage it was in, but this is the right time to make the switch (without taking away any existing functionality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each example needs actual JRD code.

In addition, I would very much like to see WebFinger extend the host-meta endpoint by defining a 'resource' query parameter. Using the example in RFC 6415 section 1.1.1 (example not properly encoded to make it easier to read):

> GET /.well-known/host-meta?resource=http://example.com/xy HTTP/1.1

   {
      "subject":"http://example.com/xy",

      "properties":{
        "http://spec.example.net/color":"red"
      },

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/hub",
        },
        {
          "rel":"hub",
          "href":"http://example.com/another/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/john",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy"
        }
      ]
    }

The rules for this extension parameter are pretty simple:


1.       JSON is implied. If the server understands '?resource' it MUST return a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.) it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making sure the response is both JRD and has the requested subject (this will ensure full compatibility with any other host-meta endpoint).

I would like to see such endpoint extension required for WebFinger so that clients can make a single call and get the full WebFinger result in JSON. This would significantly improve adoption and usability, and adds very little work to providers.

EHL


From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

Folks,

We just submitted this:
http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

The tools for Webfinger are now defined, but the procedures need to be clearer with respect to what most of us understand as "webfinger".  This is just a first stab at making that happen and we hope to progress this to publish an RFC in the application area.

We welcome any comments you have on the topic, either privately or publicly.

Paul