Usually you'll create a new set of client credentials that represents the resource server, since the OAuth client shouldn't be introspecting tokens. There isn't really any other form of authentication for the API so it's kind of an overloading of the term "client credentials"
Thanks! I haven't actually used any of my own because they're just so expensive. I've used some when doing gigs at a venue that has them installed. The picture off them leaves something to be desired too, but maybe they've gotten better now.
take a look at my activitypub conference talk, starting at 11:50, I address the UX aspect of it here: aaronparecki.com/2020/09/22/…
also happy to set up a time to chat about this instead! I think we have a lot of similar goals!
Email addresses *are* domain-based auth. I think you’re conflating two different parts of the system. In IndieAuth, the canonical user identifier doesn’t have to be the thing the user enters in a login prompt. This is also true for almost every other authentication system.
I’ll admit it’s a bit of a “hack”. The trick is “aaron@parecki.com” is a URL because if you assume the http scheme then you get http://aaron@parecki.com which is a username but no password with HTTP basic auth. The server can switch what it returns based on that username.
This one I’m really confused on, and we should probably chat about it to clear things up. IMO OIDC is more of a barrier here because the default is that clients need to register. With IndieAuth there is no expectation of client registration at all.
There is no obligation that you have to register your own domain for IndieAuth to work. I’ve talked about this at ActivityPub Conference showing how they can use IndieAuth to enable a standards-based app ecosystem for ActivityPub/Mastodon apps. That of course uses shared domains.