Subject: Re: [apps-discuss] An alteration to the WebFinger Spec

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 1 Nov 2012 15:43:47 +0100

On Thu, Nov 1, 2012 at 7:40 AM, Paul E. Jones <[email-masked]> 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.

---

From: Mike Jones <[email-masked]>
Date: Thu, 1 Nov 2012 15:06:15 +0000

+1!

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Wednesday, October 31, 2012 11:40 PM
To: [email-masked]; [email-masked]
Subject: [apps-discuss] An alteration to the WebFinger Spec

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 ;-)

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.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 1 Nov 2012 12:19:31 -0400

Comments below:

PEJ: OK.  It is only an example, so it can be removed. Is there a different example you would like to see, or are the other two sufficient? 

* WebFinger, being JSON-only, should only document /.well-known/host-meta.json

  Status.net and whoever else can continue to serve webfinger for compatibility

  being 6415 compliant.

PEJ: Given we are not deprecating RFC 6415, that seems like a reasonable compromise.  A server could still support both, but anything that is officially “WebFinger” will use only the .json resource.  I’ll remove host-meta and post an updated “alt” spec shortly.

  all-encompassing endpoint.  If you really want this, DO NOT REUSE host-meta

  host-meta.

PEJ: I think this one might be more challenging.  There is a camp that likes the RFC 6415-way of doing things with a host-meta document and then an LRDD resource.  Then there is the other camp who says “I want the simplest possible client and want to issue exactly one query, period.”  The “rel” parameter allows server-side filtering in the event the response might be voluminous; this reduces client-side processing work.  I let the camps battle this one, but I can see good arguments on both sides.

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

PEJ: WebFinger servers that serve the public (Internet) MUST use CORS; enterprise WebFinger servers are not required to do so.  That was the consensus of the group thus far and there are several who have demanded CORS support.

* Section 8.1: "When a query is issued host-meta" ... "pointing to the location 

PEJ: I’m not following what you’re saying.  The text says “When a query is issued to /.well-known/host-meta.json, the target domain’s web server MUST return a 301, 302, or 307 … pointing to…”.  I’m making no assumptions, just specifying how resources must be redirected to enable a service provider to provide the services on behalf the domain.  

PEJ: Hold that for -ALT-R1 :-)

Paul