search

indieweb / indieauth

IndieAuth.net website code and IndieAuth Specification
52 stars 7 forks source link

Add JSON document to spec #138

Closed dshanske closed 1 week ago

dshanske commented 2 weeks ago

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

saschanaz commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 1 week ago

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 commented 1 week ago

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.