If you want to contact me, I'm shell@alterednarrative.net on email and XMPP. I'll try and find whether I still have the design notes, but doubt it; I've been through a couple of laptops since and lost a lot.
One of my goals was that the flow could start from a service provider - you type in the domain name you want the service to be bound to on the service provider's website, and it goes from there. If you were to use OAuth2 at this point, there's no existing client ID/password, and allowing public dynamic client registration leads to DoS potential as someone could easily register a practically infinite amount of clients and fill up disk space. So you want a custom flow which winds up, at the end, with the consent of the domain owner, returning OAuth2 credentials to the service provider. This flow is fairly complex to spec out in a way that doesn't have subtle security issues (e.g. this initial flow can't trust much info from the service provider which could be something akin to a phishing scam, returning to the service provider on error has to be done carefully because of risk of being used in an open redirect chain, etc).
After that it's mostly a case of supplying auth keys for RFC2136 so the service can manage its delegated domain, handling credential rotation, and properly handling edge cases like either the service provider or the domain management system losing track of state, or the domain being lost/transferred to another entity.
Honestly I'd like to build something like this for my own projects, and might do so as a weekend project soon, esp since it's just been validated as something useful. :D
I'll shoot you an email, and we can talk more if you do end up working on this.
I'm not a big fan of pre-registered clients in the first place. Ideally any client should be able to talk to any OAuth2 server that speaks the same profile, ie endpoints and scopes. Aaron Parecki describes a way to allow "anonymous" clients here[0]. As I understand that's how IndieAuth is implemented. But I'm still relatively new to OAuth, and I don't doubt there could be subtle security issues. Do you have any thoughts on that?
One of my goals was that the flow could start from a service provider - you type in the domain name you want the service to be bound to on the service provider's website, and it goes from there. If you were to use OAuth2 at this point, there's no existing client ID/password, and allowing public dynamic client registration leads to DoS potential as someone could easily register a practically infinite amount of clients and fill up disk space. So you want a custom flow which winds up, at the end, with the consent of the domain owner, returning OAuth2 credentials to the service provider. This flow is fairly complex to spec out in a way that doesn't have subtle security issues (e.g. this initial flow can't trust much info from the service provider which could be something akin to a phishing scam, returning to the service provider on error has to be done carefully because of risk of being used in an open redirect chain, etc).
After that it's mostly a case of supplying auth keys for RFC2136 so the service can manage its delegated domain, handling credential rotation, and properly handling edge cases like either the service provider or the domain management system losing track of state, or the domain being lost/transferred to another entity.
Honestly I'd like to build something like this for my own projects, and might do so as a weekend project soon, esp since it's just been validated as something useful. :D