@aaronpk are you aware of any OAuth implementations using unregistered clients (RFC 6749 section 2.4) in the wild? It seems to me that requiring client registration discourages self hosting OAuth servers. For example, I'm working on a storage service where each user will 1/

have their own custom domain for their instance, hosting an auth server. If someone wants to develop an app to talk to my service, they would have to register it with the instance of every user, which is impossible. Am I missing something? 2/2

You're not wrong. You may want to give this a read, which addresses that exact problem: aaronparecki.com/2018/07/07/… We use this a lot for the case you're talking about, where app developers have no relationship with the OAuth service the app is talking to.

Ahhh that's what IndieAuth is. I was reading up on it, but didn't see any information about the spec on the website. I think my main hesitance towards it is the use of domains. I just don't see the average user buying their own domain. Emails seems more realistic for unique IDs.

Doesn't have to be a top level domain, just a URL. Both users and apps are identified by URLs. I do think there's value in just client IDs being URLs in some cases, demonstrated by the fact that Home Assistant picked out just that part of the spec for their OAuth API.

I'm imagining a world where email servers handle identity, and authorization servers handle delegation, after confirmation ownership over the email identity.