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.
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.
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/dd2d4dfc86f7d13045ad715377b6a...
> 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.
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-credent...
[1] https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
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.
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