W3C home > Mailing lists > Public > public-fedsocweb@w3.org > November 2012

Re: An alteration to the WebFinger Spec

From: Brad Fitzpatrick <bradfitz@google.com>
Date: Thu, 1 Nov 2012 15:43:47 +0100
Message-ID: <CAAkTpCr3XxWE2Cm3usWksKEyZwxn9n6zDW90ELJMN4wpjcTphA@mail.gmail.com>
To: webfinger@googlegroups.com
Cc: apps-discuss@ietf.org, public-fedsocweb@w3.org
On Thu, Nov 1, 2012 at 7:40 AM, Paul E. Jones <paulej@packetizer.com> wrote:

> Folks,****
> ** **
> Here’s a proposal that some might find acceptable and others will probably
> love.  It’s just a proposal, so no bazookas, please, from those who will
> find it troubling ;-)****
> ** **
> http://hive.packetizer.com/users/paulej/internet-drafts/draft-ietf-appsawg-webfinger-03-ALT.txt

Much nicer!

> ****
> ** What I did with this text is the following:
> **
> **·         **Included all of the current -03 text (not yet published,
> but text folks proposed on the list)****
> **·         **Removed every reference to XML and XRD****
> **·         **Stated that the default format for
> /.well-known/host-meta.json is JRD****
> **·         **Stated that the default format for /.well-known/host-meta
> is implementation-dependent, so clients MUST use the Accept header to
> explicitly request the desired representation when using that resource
> (this is key to backward/forward compatibility and proper use of HTTP and
> Accept)****
> **·         **Removed the “account link relation” section****
> **·         **Removed the interop considerations section, since some feel
> there is no need and I think requiring use of “Accept” on host-meta will
> address any interop concerns****
> **·         **Removed the XML appendix that gave some people heartburn****
> ** **
> This shaved off 6 pages of text, I think will still give us
> backward-compatibility for those who have asked for it, but more clearly
> positions JSON / JRD as the only format developers need to worry with.****
> ** **
> Tell me what you think.

Some notes I took while reading:

* Delete the whole section "4.2. Simplifying the Login Process".  As much as
  I loves me some OpenID, it's out of place in this document.

* WebFinger, being JSON-only, should only document
  as part of the client's discovery process, not /.well-known/host-meta.
  Status.net and whoever else can continue to serve webfinger for
  at /.well-known/host-meta if they'd like to support all of RFC 6415.  But
  WebFinger doesn't need to include docs on supporting all of RFC 6415.  It
  should be possible to write a server which is WebServer compliant without
  being 6415 compliant.

* Section 5.2: ditch the rel=, resource= parameters from host-meta.json.
  It's a HOST meta, not a RESOURCE meta.  It's being morphed into an
  all-encompassing endpoint.  If you really want this, DO NOT REUSE
  and just use /.well-known/webfinger-query.  But I am not proposing that.
  I'm just saying that would be more sane than tacking random crap onto

* Section 6. MUST support CORS, but MAY exclude the header. What? SHOULD

* Section 8.1: "When a query is issued host-meta" ... "pointing to the
  of the hosted WebFinger service URL"  host-meta is its own thing.  You are
  assuming that host-meta means WebFinger.

I might have more minor feedback later, but the above is most of it.
Received on Thursday, 1 November 2012 14:44:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:15:18 UTC