I can definitely agree that this is a big part of it.
I admit that I’m not 100% sure what I’m looking for in it’s most focused form and that I may have conflated my user story with an incomplete implementation idea.
I think fundamentally I want to be able to take my web ID with me into various different apps freely, without forcing those apps to provide infrastructure they don’t need.
I feel like I should “in a perfect world” be able to log into Roomy and Mastodon with the same DID that I log into ATProto with, and as I log into new apps, if they require services that I don’t have yet, there should be an easy way for me to register for those services from some provider, and this process should be easy to understand for the user.
My universal ID should allow apps like Bluesky and Roomy to do essentially an OAuth scope request that says, “Roomy would like to register a Leaf service provider for your account” or “Bluesky would like to register an ATProto service provider for your account”, and those services will then be added to my DID. At that point, other Leaf and ATProto apps will use those registered services.
Coming back to this:
It seems OK to me to need to explicitly register with a PDS provider like Bluesky, if the app you are using doesn’t want to be responsible for PDS hosting, but the app should be able to create a DID, or use whatever DID the user provided, without it having to have a PDS service endpoint first, and then go register for a Bluesky PDS with it.
I think maybe this doesn’t require having a specific auth server like I initially thought. Different services can have their own auth server, and the PDS can continue to be it’s own auth server.
For instance, what if you logged into an app for composing and sending emails. It might require you to have an SMTP service registered. That SMTP service would probably have it’s own auth server completely different from your other services. That’s OK, and when you try to log into the email composer app, it will lookup the OAuth metadata and redirect to whatever auth server that your particular SMTP service uses.
I think maybe the only missing component to making that possible is a standardized API / flow for managing the services registered on your DID.
Technically we can use ATProto for this today if your DID is managed by a PDS, but I think it could warrant its own standard so that a whole PDS isn’t required.
Honestly, though, being that things work pretty well right now, it might not be worth the effort.