3 ms·

The biggest problem with OIDC is how non-standard every implementation is. I mean, there is a standard, but then there's what everyone actually does. Even with

by Alupis 4y ago

The biggest problem with OIDC is how non-standard every implementation is. I mean, there is a standard, but then there's what everyone actually does. Even within the standard, there is a very surprising amount of it that is... optional. Even discovery endpoints are non-standard... basics like `/.well-known/openid-configuration` is recommended but not required... and don't even try to guess where /userinfo lives! Claims are willy-nilly, and even some IDP's provide duplicate-in-intent but different-in-name claims, like `phone_verified` vs. `phone_number_verified`. It's just a complete wild west out there! Anyone bringing some level of standards to the delegated authentication arena would be very welcome in my opinion.

woodruffw 4y ago
I agree completely about OIDC's discovery limitations! If this standard can improve along that axis, then that alone will make it a valuable contribution to the identity space. I also agree about standardized claim names, although I'll point out that standardizing something like `phone_verified` just pushed the identity/claim value question one level deeper: what does it mean for IdP A to have `phone_verified` versus IdP B? Do they have the same ontological value? That's part of why (IMO) "generalized" identity management has never succeeded: you can make everybody generate the same claims, but you can't assert that they've done a uniform or sufficient degree of diligence for those claims. The only way you can do the latter is to select "high quality" IdPs, at which point the consistency of the claim names no longer matters.
PeeMcGee 4y ago
> The biggest problem with OIDC is how non-standard every implementation is. I'm sure you've read it but I have to mention it for good measure. OAuth 2.0 and the Road to Hell: https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a48f https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a...
- dane-pgp 4y ago
  The most relevant section is perhaps this: > That community [at the IETF] is all about enterprise use cases and if you look at their other efforts like OpenID Connect (which too was a super simple proposal turned into almost a dozen complex specifications), they are not capable of simple.

by Alupis 4y ago

woodruffw 4y ago

I agree completely about OIDC's discovery limitations! If this standard can improve along that axis, then that alone will make it a valuable contribution to the identity space. I also agree about standardized claim names, although I'll point out that standardizing something like `phone_verified` just pushed the identity/claim value question one level deeper: what does it mean for IdP A to have `phone_verified` versus IdP B? Do they have the same ontological value? That's part of why (IMO) "generalized" identity management has never succeeded: you can make everybody generate the same claims, but you can't assert that they've done a uniform or sufficient degree of diligence for those claims. The only way you can do the latter is to select "high quality" IdPs, at which point the consistency of the claim names no longer matters.

PeeMcGee 4y ago

> The biggest problem with OIDC is how non-standard every implementation is. I'm sure you've read it but I have to mention it for good measure. OAuth 2.0 and the Road to Hell: https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a48f https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a...

dane-pgp 4y ago
The most relevant section is perhaps this: > That community [at the IETF] is all about enterprise use cases and if you look at their other efforts like OpenID Connect (which too was a super simple proposal turned into almost a dozen complex specifications), they are not capable of simple.