Re: An alteration to the WebFinger Spec

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
/.well-known/host-meta.json
  as part of the client's discovery process, not /.well-known/host-meta.
  Status.net and whoever else can continue to serve webfinger for
compatibility
  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
host-meta
  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
  host-meta.

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

* Section 8.1: "When a query is issued host-meta" ... "pointing to the
location
  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.