Hacker News Reader

Comment by drdaeman | Hacker News Reader

Identity provisioning is an abomination that shouldn't have been invented. I used to be a fan back in mid-'00s, self-hosting an OpenID server, without realizing how the whole concept is so fundamentally flawed.

Identity is an innate and inalienable property of individual, not something that anyone else (another person, company/website, government or whoever else) can "provide". They can merely attest by providing a credential, by e.g. issuing a passport.

At least Webauthn got this right.

View on HN

But does this not make the assumption that the Identity being provisioned is exactly you and only you? I've always seen these identities as my pseudonym on some identity provider and use them in that manner.

I suppose I've used some identities in enough places that it would be hard to deny to certain entities that the identity was mine, but even in that case it's a small subset of entities which have seen the identity that could prove that it's me.

Is there a practical consequence to this distinction between attestation and provisioning, or is it purely philosophical?

For me personally, it's primarily philosophical - I don't want to be defined by someone else, only confirmed that it's, indeed, me.

However, there are practical consequences. There are plenty of stories how people got their Google/Facebook/Apple/... accounts blocked; or domain name lapsed, for self-hosting folks - and thus lost "their" "identity" (quotes for a lack of better words).

One can back up their credentials and attestations - losing a password (or a keypair) is preventable, since it's all first-party. One cannot back up a third-party service.

This is fair, but I appreciate having an interoperable standard nonetheless. I'm currently designing an auth system based on oidc where the first party service is itself an IDP, but you could also use a third party IDP like Google. So if you're worried about losing access to your Google account, you can use the first party IDP and set up an account, and if you'd rather not set up a new account, verify email, set up 2fa etc, you can just reuse your Google ID. Since they're both standard OIDC flows, it's not hard to support both (and many more)

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.

Reply on news.ycombinator.com