Comment by drdaeman
8 months ago
Of course, I understand the appreciation for an open standard, especially one less messy than SAML. :-) And I can see valid use cases for OIDC when it's all first-party, all in the same system. Maybe if it would use different language, I would have less or no issues with it. I need to think about it... Thanks for giving me some food for thought!
Self-hosting is not a solution, though, unless we're talking about system like yours where - if I understood you correctly - there's no third party. I used to love "classical" OpenID back in mid-'00s (I haven't really thought about it back then, and it was convenient) and self-hosted an OpenID provider. I stopped doing so when OpenID went out of fashion; and later I learned the fact that one cannot own a domain name, merely lease it from authority (despite whatever anyone says, it's just how it is in practice), so tying an identity to that is a bad idea. I-names/i-numbers are also dead. And that's how started to think about it and eventually came to understanding that identity provisioning is a fundamentally broken idea.
OIDC as a machine-to-machine protocol is fine, save for the associated language. But how it works in, what I suspect, the majority of real-world implementations is just conceptually wrong (and practically harmful).
There's a balance to strike between convenience and robustness. Even a legal identity can be stolen, and countries have broad authority to regulate national TLDs and could make owning one just as robust as owning property. The core of an OIDC token is "iss" (issuer e.g. https://accounts.google.com) and "sub" (subject i.e. unique immutable ID e.g. 1234567890). Is that really different from a passport which has at it's core a nation ("iss") and number ("sub")? Sure there's other stuff like names and pictures, but OIDC tokens can have those too.
Having backups is key. The only difference is legal ID's can be backed up without registering the backups with each service ahead of time. Perhaps this could be engineered into OIDC too: a backup field with hashes of other OIDC tokens or something.