Aaron Parecki

I actually have an open issue on Aperture which would help in this situation. The idea I had was to treat every Aperture channel as its own IndieAuth identity, so that you could log in to Micropub apps and they'd end up posting into the Aperture channel. The cool part of that is the apps wouldn't even know that they're posting into an Aperture channel, they just see it as a Micropub endpoint.

Your idea of just treating some channels as writable is also interesting though. The only trick is I can't picture the user flow of how to actually have the app request and get the permissions for that. Definitely worth further thought though!

In order to continue the OAuth compatibility, this would also mean that the code exchange (token request) step would need to work without the me parameter as well.

This breaks the ability to use a shared token endpoint between users, since the token endpoint wouldn't know how to verify the authorization code without the me URL at that point. The workaround for shared token endpoints is to have a per-user token endpoint URL, like tokens.indieauth.com/user.example.com/token kind of like how I have per-user webmention endpoints on webmention.io. I'm not sure I'm super happy about this though.

Thanks for the writeup!

This is a really good point. The me parameter in the request is really more of a hint, since the authorization server will ultimately return the final me value at the end of the flow. The client just has to verify that it's on the same domain that was used to discover the authorization endpoint.

I implemented an IndieAuth server into my website quite a while ago, so I checked the code there. It turns out I had some code that verified the me parameter was in the request, but it actually completely ignores that value after that. Since my site is a single-user site, it's always going to return https://aaronparecki.com/ as the profile URL at the end.

I'm inclined to make a change to the spec that says clients SHOULD include the me in the authorization request, but that the authorization server should not require the parameter. I do like that it helps IndieAuth be more in line with OAuth 2.0.

The summary property is intended to be used for fallback for when the server doesn't recognize the other properties of the request. Most Micropub servers understand content and photo, but this is a great example of an interesting content type that is likely not supported by most servers yet. In this case, summary is the correct place for this fallback content. The content property would be misleading since normally the content property contains user-entered text. For example, if the user enters a note about why they wanted to read this, that could be included in the content property.