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

["Paul E. Jones" <[e-mail]>]

Comments below:

 

 

* 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.

 

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

  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.

 

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.

 

* 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.

 

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 

  of the hosted WebFinger service URL"  host-meta is its own thing.  You are

  assuming that host-meta means WebFinger.

 

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.  

 

I might have more minor feedback later, but the above is most of it.

 

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

 

Paul