I know this can be confusing, so bear with me: on one hand, you have the identity provider, where you enter your login/password, and on the other, you have the Solid-OIDC Providers, which makes it so that applications may know your WebID and access your data on your Pod. These two may be one and the same, as they are in CSS/NSS, but they also can very well be separate services, which is the case for ESS.
What @ThisIsMissEm is saying is that both http://broker.pod.inrupt.com/ and http://login.inrupt.com/, which are two different Solid-OIDC Providers, communicate with the same underlying Identity Provider, which means you will successfully log in with the same username/password for both Solid-OIDC Providers (because the username/password is managed by the underlying Identity Provider, which is unique in this case).
However, each Solid-OIDC Provider ties in a different set of services, which explains the discrepancies you’re observing:
- login.inrupt.com will associate your user account to a WebID hosted on id.inrupt.com, and to a Pod hosted on storage.inrupt.com. That’s the latest version of ESS, which is still in early access.
- broker.pod.inrupt.com will associate your user account to a WebID hosted on your Pod, under pod.inrupt.com. That’s the stable deployment of Pod Spaces, based on a legacy version of ESS.
So to summarize, if you want to work with your pre-existing Pod at https://pod.inrupt.com/<username>/, using your WebID looking like https://pod.inrupt.com/<username>/profile/card#me, you’ll want to log in to broker.pod.inrupt.com, and to register your static client at Application Registration.
Does that help?