11–20 of 134 posts
Wanted to take a look at the schemas linked, but identity0.io isn't even registered? oO
They don’t have SSL enabled (or properly configured). But even with that in mind - it doesn’t work. http://identity0.io/contexts/v1
JWT is already a thing, as is X.509, OAuth/OpenID, WebAuthn... Just use a combination of these that best fits your use case.
"But this new standard will be the true unifying one". Nope, it will not. The most it will do is get some share of usage and add to the chaos.
Isn’t this just Json Web Tokens with a different name? (and an extra step to create a VP, presumably so the expiry on the VC can be longer).
This places all the trust in the institution that mints verifiable credentials. (or the institution + Auth0 if they use Auth0). This is good for use cases where you want to assert that an organization says something about you (e.g., you have a degree). It is not good for use cases where you want to assert that you say something (e.g., I voted for Blah, or I authorized this transfer).
The only thing the web identity ecosystem needs is another independent standard – said no one ever. JWT is already a thing, as is X.509, OAuth/OpenID, WebAuthn... Just use a combination of these that best fits your use case. "But this new standard will be the true unifying one". Nope, it will not. The most it will do is get some share of usage and add to the chaos.
Isn’t this just Json Web Tokens with a different name? (and an extra step to create a VP, presumably so the expiry on the VC can be longer).
The only thing the web identity ecosystem needs is another independent standard – said no one ever. JWT is already a thing, as is X.509, OAuth/OpenID, WebAuthn... Just use a combination of these that best fits your use case. "But this new standard will be the true unifying one". Nope, it will not. The most it will do is get some share of usage and add to the chaos.
This will turn the whole billion dollar kyc/identity verification space upside down.
I work in that space.
Isn’t this just Json Web Tokens with a different name? (and an extra step to create a VP, presumably so the expiry on the VC can be longer).
It is a JWT, but a JWT is just a data format, not a schema. This VC thing seems to take ID Tokens from OIDC providers a little further and also standardizes what claims you can expect.
OIDC's well-known discovery[1] also does this kind of claim standardization/expectation setting already. But maybe it goes beyond that, and actually normalizes between different IdPs? I'm not sure what that would entail.
[1]: https://swagger.io/docs/specification/authentication/openid-...
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/
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.