Comment by lolinder
8 months ago
Is there a practical consequence to this distinction between attestation and provisioning, or is it purely philosophical?
8 months ago
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).
1 reply →