Add JSON document to spec

[dshanske]

This adds a very simple version of the proposed switch to #133

[saschanaz]

I'm happy with the idea of having JSON, but this seems not backward compatible, i.e. it's not possible to serve metadata for both old and new implementations? Am I understanding correctly?

[dshanske]

It is in the sense that the old version would be at the client_uri...it just means a single app can't serve an HTML and a json version at the same URL.

From the authorization server point of view....it should support the new way of learning information about the app... but it doesn't actually have to learn anything.

[saschanaz]

It is in the sense that the old version would be at the client_uri...it just means a single app can't serve an HTML and a json version at the same URL.

But the apps currently are supposed to provide that in client_id, how can an app decide what format to use in client_id if auth server starts to expect JSON?

[dshanske]

It is in the sense that the old version would be at the client_uri...it just means a single app can't serve an HTML and a json version at the same URL.

But the apps currently are supposed to provide that in client_id, how can an app decide what format to use in client_id if auth server starts to expect JSON?

The app should serve the JSON. Also, I'd expect the servers will fall back on HTML if JSON isn't returned for some time. My implementation does.

[saschanaz]

That wouldn't work if the target server is not updated. And should the spec keep some info about fallback in that case for backward compat, as it does for rel=authorization_endpoint etc?

[dshanske]

That wouldn't work if the target server is not updated. And should the spec keep some info about fallback in that case for backward compat, as it does for rel=authorization_endpoint etc?

If it isn't updated, it would be the equivalent of no html at all at the client id, which would only practically create an issue with displaying the consent page...it would show the URL but no name or image

[saschanaz]

If it isn't updated, it would be the equivalent of no html at all at the client id, which would only practically create an issue with displaying the consent page...it would show the URL but no name or image

Yes, and it would be much more cryptic to user than the current no-metadata apps, as the URL would end with .json (unless the app owns a non-static page) and the result would be not human readable anymore.

[aaronpk]

I used a short URL for my JSON client metadata documents, such as https://indielogin.com/id. There's no requirement that the URL ends in .json.

An authorization server can certainly look for the HTML microformats if the client_id URL is not JSON for fallback, but I'd rather not include that in the spec at this point. The only actual functionality provided by the previous metadata discovery was when the redirect URL was on a different host than the client ID, which is a rare edge case in the first place. The rest should be considered progressive enhancement, providing the app name and logo to the user, but doesn't actually affect the functionality of the flow. The authorization server already had to be able to process the request when client metadata discovery failed anyway, so an AS that doesn't support the new JSON format should be falling back to just displaying the client ID now anyway.

[aaronpk]

One other note for implementers, a client could use the old behavior of providing an HTML client_id if it discovers the older rel=authorization_endpoint at the user's website, but use the new JSON client_id if it discovers the rel=indieauth-metadata. While this isn't a 1:1 change, it would probably be pretty close.