"That's been tried before. It's called RDF."

I'm no RDF proponent. If complexity is a barrier for adoption, XRD is all sorts of win over RDF. Ignoring signatures and just looking at XRD/Link elements, it is not too far from a dictionary.

"For AtomPub you would parse the HTML page for link/@rel="service.post".

I know, bad example. I wanted to use something concrete, rather than just a vague, hypothetical web service. They exist though, now and in the future, and could benefit from discovery. When spec'd, they can simply reference XRD in the discovery section and be done. I think that's useful.

"That's a feature, not a bug. I'm not being flippant, by focusing on solving an easily stated problem in the simplest possible manner you actually improve your chances of shipping something that gets deployed."

I'm with you, 100%. Is there anything in my suggestion that you think detracts from yours? I just renamed a file and changed a couple well-known strings. It doesn't appear to have any additional complexity in terms of processing.

After thinking about it, I'm legitimately interested in a simplified JSON approach to discovery. If it encourages more people to implement it, that's a good thing. Plus, using JSONP, it may be possible to pull off some useful tricks within the browser.

Thanks for posting this. WebFinger is going to be an important piece of infrastructure for Internet going forward. Increasing awareness and refining the protocol is a benefit to all.

That said, it is a fairly trivial matter to take any standard that has underwent significant discussion and revision and suggest ways of simplifying it. The question is what is lost in the simplification?

It is an often heard complaint that the discovery stack is broken into too many discreet components. While I'm personally a fan of this breakdown, I fully acknowledge that it is confusing to wrap your head around each cog in the machine. However, I think this is best addressed at a documentation and education level, rather than concluding that the protocols themselves are flawed.

For sake of discussion, I'm going to call refer to the collective discovery stack (XRD, LRDD, .well-known, etc.) as simply XRD.

XRD defines a discovery mechanism for any URL. WebFinger is not really a protocol as such, but merely a profile of XRD (read: LRDD) that defines how to resolve email addresses (read: acct: URLs). By defining XRD as a generic discovery mechanism, any web-based resource can be queried for discovery. Furthermore, we only impinge upon the well-known namespace once.

For example, say I wanted to discover services associated with my blog, such as AtomPub, Trackback, etc. I could define that using XRD as it stands today. However, I could not do so using what you propose here. I could reuse the JSON encoding, but would have to mint a "blog-finger" entry in the well-known namespace.

The more useful question isn't "is WebFinger too complex?" but rather "is XRD to complex?"

If the answer to the question is yes, maybe its worth defining a generic JSON-based discovery spec. In which case, I'd propose the following modifications to your protocol flow:

1: Get a URL as input.

2: Use the domain from the URL to construct the JSON-Disco URI:
http://<domain>/.well-known/disco.json

3: GET the JSON document at the JSON-Disco URI. The body of the response will be a JSON object:
{
"template": "http://example.org/{uri}"
}

The object has a key of 'template', and the value at the key 'template' is a string, a URI Template with a single variable: 'uri'.

4: Substitue the URL for the {uri} part of the URI Template and expand the URI Template.

5: Do a GET on the generated URI to retrieve a JSON document, a dictionary. Server-side implementations should take care to normalize input URLs. Specifically, URLs without any scheme, which otherwise conform to email address formatting, should be normalized to mailto: URLs.

<the remainder proceeds as described>

(Disclaimer: I personally find there to be a lot of benefit to the discovery stack as specified, including any complexity. I also have projects in development that are making use of it. While I'm not sure there is much to be gained from a simpler JSON-based approach, I still wanted to voice my opinion in the event that such a solution gains traction and deployment.)