Martijn van der Ven

I agree with @fluffy-critter that the response should be whatever is a valid HTTP response as decided by the server. If it must standardise on something, I would propose lifting...

> […] I would hate to make a breaking change in the spec just to stay conformant with RFC 5988/8288 when in reality the live code seems to not care....

@dshanske Feels like this is pending closing by https://github.com/indieweb/indieauth/issues/133. As that would potentially introduce a different recommended way to detect `redirect_uri` (as `redirect_urls`) in the Client ID Document.

Closing this, as all verification is now following RFC 7662.

Because the token endpoint part of the flow seems to solely use Bearer tokens and rely a lot on core OAuth 2.0 mechanics (e.g. revocation is basically [RFC 7009](https://tools.ietf.org/html/rfc7009) without...

I have started some [initial documentation](https://indieweb.org/User:Vanderven.se_martijn/IndieAuth_Client_Information) to see exactly what applications are publishing for discovery. [Current statistics](https://indieweb.org/wiki/index.php?title=User:Vanderven.se_martijn/IndieAuth_Client_Information&oldid=51273): | h-app | h-x-app | rel=redirect_uri | rel=manifest | | --- | ---...

The table above has been updated with new statistics. This shows that `rel="manifest"` are equally as likely to be found on client pages as `h-x-app`. This Web App Manifests may...

The survey has been updated to tally how many client pages are advertising logos in the form of `rel="icon"`, `rel="apple-touch-icon"`, and `rel="mask-icon"` links, as extracted by a microformats parser. Both...

As creator of this issue, I am not opposed. I think a client metadata document and a way to discover it is a perfectly valid alternative to parsing microformats. And...

Now that we are continuously trying to bring IndieAuth more inline with default OAuth, should we consider refering people to the general OAuth threat models? * [RFC 6819: OAuth 2.0...