3 ms·

I wonder what the benefits of this versus e.g. OpenID Connect[1] are: OIDC is already semi-widely adopted, reuses a popular underlying envelope scheme (JWTs), a

I wonder what the benefits of this versus e.g. OpenID Connect[1] are: OIDC is already semi-widely adopted, reuses a popular underlying envelope scheme (JWTs), and performs a similar type of proof (that some identity provider claims something about an identity). [1]: https://openid.net/connect/ https://openid.net/connect/

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.
dane-pgp 4y ago
For extra context, there is currently work ongoing in the OIDC standards community to support Verifiable Credential Issuance[0] as well. Even better, this verifiable credentials work is intended to integrate well with self-issued identities, which they are also working on[1], under the name Self-Issued OpenID Provider v2 (SIOPv2). [0] https://openid.net/specs/openid-connect-4-verifiable-credential-issuance-1_0-05.html https://openid.net/specs/openid-connect-4-verifiable-credent... [1] https://openid.net/specs/openid-connect-self-issued-v2-1_0.html https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
dwaite 4y ago
As someone else pointed out, there is work in OpenID Connect to support this model. The difference is that traditional Connect is typically a two party model - an OpenID Provider which gives claims which can be used for registration/authentication, and a Relying Party willing to accept them. This is an active dance back and forth, with the OpenID Provider deciding how to implement privacy, what records to keep on usage, prompting for user consent, etc. Verifiable Credentials have Issuers and Verifiers which map reasonably well into these roles, but also an end user agent in the middle which acquires credentials, holds onto them and presents them with user consent. While the verifier needs to still know who the issuer is to know if it should trust the data, the issuer no longer needs any relationship whatsoever with the verifier. The issuer does not see where credentials are being used, or (for credentials with selective disclosure) which information is being disclosed.
- jfroma 4y ago
  Just to add to your excellent description, one can draw an analogy between the id_token and a VC. But an id_token usually has an audience which is the RP, and a short expiration. A VC is issued for the user (aka holder), with long or no expiration to store in wallet. A VC is bound to the user’s did (think pk thumbprint) and is useless without a proper presentation. A verifier does not expect just the VC but a V. Presentation signed by the user. This is where using id_tokens as vcs will fall short. Once you give it to one verifier, you could assume is public. The good thing about VCs is that is standard and easy to grasp. There are too many flavors though

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.

dane-pgp 4y ago

For extra context, there is currently work ongoing in the OIDC standards community to support Verifiable Credential Issuance[0] as well. Even better, this verifiable credentials work is intended to integrate well with self-issued identities, which they are also working on[1], under the name Self-Issued OpenID Provider v2 (SIOPv2). [0] https://openid.net/specs/openid-connect-4-verifiable-credential-issuance-1_0-05.html https://openid.net/specs/openid-connect-4-verifiable-credent... [1] https://openid.net/specs/openid-connect-self-issued-v2-1_0.html https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...

dwaite 4y ago

As someone else pointed out, there is work in OpenID Connect to support this model. The difference is that traditional Connect is typically a two party model - an OpenID Provider which gives claims which can be used for registration/authentication, and a Relying Party willing to accept them. This is an active dance back and forth, with the OpenID Provider deciding how to implement privacy, what records to keep on usage, prompting for user consent, etc. Verifiable Credentials have Issuers and Verifiers which map reasonably well into these roles, but also an end user agent in the middle which acquires credentials, holds onto them and presents them with user consent. While the verifier needs to still know who the issuer is to know if it should trust the data, the issuer no longer needs any relationship whatsoever with the verifier. The issuer does not see where credentials are being used, or (for credentials with selective disclosure) which information is being disclosed.

jfroma 4y ago
Just to add to your excellent description, one can draw an analogy between the id_token and a VC. But an id_token usually has an audience which is the RP, and a short expiration. A VC is issued for the user (aka holder), with long or no expiration to store in wallet. A VC is bound to the user’s did (think pk thumbprint) and is useless without a proper presentation. A verifier does not expect just the VC but a V. Presentation signed by the user. This is where using id_tokens as vcs will fall short. Once you give it to one verifier, you could assume is public. The good thing about VCs is that is standard and easy to grasp. There are too many flavors though