North Idaho is practically a different state.

Spent a year in the Palouse. Beautiful area. Everything turns green in the summer, gold in the fall before harvest, white during the winter, and brown in the spring after plowing.

There are definitely tradeoffs, but I think the key point is that did:web is the only way today to have an atproto identifier that wouldn't die with Bluesky. Moving plc.directory to an org would be a great step but it could take a very long time for it to achieve the same level of trust as DNS.

In addition to reusing existing libraries, there's also avoiding fracturing the ecosystem, just when OIDC is starting to get some traction in the decentralized world. To be clear, I don't necessarily think this is vital, I'm just trying to advocate for existing standards as much as possible.

I envision it as a 3-step process with OIDC in the middle:
1. You get some sort of handle/identifier from the user and look up their OP
2. Do OIDC
3. Verify the OP is authoritative for the handle

I've been thinking about this a lot lately, because I'd like a system that doesn't require different logins. Do you already have thoughts on how this could look?

And I'm not sure how much protection your current approach adds. Definitely a lot for devs using your libraries, but anyone making their own implementation (as I did) can just skip the checks.

I would ask you to not give up on OIDC too easily. See for example the way Tailscale implements custom OIDC providers. You give them an email address, and they use WebFinger to look up the OIDC provider. I've found this to be an excellent way of doing things.

I asked @bnewbold.net about this here: github.com/bluesky-soci...

The main issue isn't that it returns extra data, it's that `sub` is a DID, and you need to resolve that DID before you can trust that AS as authoritative for it. The protocol also requires use of the `atproto` scope. But I don't think either of these necessarily make it non-OIDC compatible.