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.
VCs can be represented as JWTs (read the spec), issued with X.509-based PKI issuers, extended with JSON-LD, and further ride on top of exchange protocols defined at OpenID for issuance/presentation. So, indeed it is a combination that best fits your use case, this is just another tool in the belt.
This will turn the whole billion dollar kyc/identity verification space upside down.
I work in that space.
https://www.w3.org/TR/vc-data-model/#json-web-token
The new thing about VC is that it introduces a mechanism for claims (which is what JWTs contain) to be made and presented in an interoperable way (requiring schemas for data, so multiple parties can make sense of claims without knowing each other), something JWTs cannot do by themselves.
Also, OpenID is being extended to support self-issued claims:
https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
VCs integrate with the existing specs, it doesn't compete with them.
Yes, you can get "partial" verification, like someone wants to know your age, and you can prove it without exposing all your other identifying information. With a centralised authority this is a pretty trivial thing. Nice to have it standardized I guess, but I don't see what's so exciting about it.
Cryptographic protocols are often defined in IETF/IRTF. You'll see things like Kerberos (authentication and attributes), OAuth (delegated authorization), and privacypass (anonymized authorization).
Many of these also have wire protocols too, such as OAuth describing HTTP API to get access tokens.
W3C has also defined some Web API for these concepts, for instance they have Web Crypto APIs as well as Web Authentication. But these concepts typically have split responsibility, such as Web Crypto being based on algorithms standardized in the IETF JOSE group, or Web Authentication being based on transports standardized under the FIDO Alliance.
So things tend to happen where they will be most successful, which means sometimes going to the place where all the right people are already participating.
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).
[0] https://www.spruceid.dev/quickstart
[1] https://en.wikipedia.org/wiki/Simple_public-key_infrastructu...
The challenge is knowing who 'I' is and why you should trust their statements.
Once a verifier knows who you are, you should be able to self-issue statements to them about yourself. Present back self-signed financial instructions in response to a request to confirm a money transfer, for example.
However, I've seen enough people to incorrectly assert who they voted for that I doubt such a self-assertion to have significant utility. Likewise, a self-asserted email address for contact could very well not meet the verifier's business/regulatory requirements without going through a more traditional email address verification.
- There's no turn key method for multi-region availability.
- It has a limited number of 2FA/MFA options.
- It does not offer a SAML idp. We ended up writing a Lambda to issue SAML claims, put it behind an API gateway with Cognito/OIDC authorization. It works, but we'll need to maintian it.
- It's AWS, so you'll need a half dozen other services to build a complete solution
If you lived in a crazy state like Florida, vaccinating at Walmart was the best way to get a credential for international travel. In the absence of federal action, countries like Israel recognized these credentials and airlines incorporated them into their ticketing workflow.
It’s not designed as a business for that use case, and you’ll be paying for a lot of premium features that you’ll never use.
If something like Firebase Auth suits your use case, use that instead.
We never hit 10k MAU, but according to their sales people you can't have multiple tenants without an enterprise license, even though that is not mentioned anywhere in the docs. We have been using them in good faith, however they will not shy away from aggressive sales tactics and threatening to 'de-provision' you if you do not commit to a very expensive license.
We had to roll our own auth solution because they couldn’t make the pricing even remotely viable.
I’d like to write „stay away from Auth0”, but is there any comparable alternative?
If you need mostly B2C features I would have a look at Clerk [0] and Supertokens [1]
If you are more interested in B2B features we found Ory [2], FusionAuth [3], and good old Keycloak [4].
None of them are fully comparable yet however, which might be the reason why they might get away with their current behaviour.
[0] https://clerk.dev/ [1] https://supertokens.com/ [2] https://www.ory.sh/ [3] https://fusionauth.io/ [4] https://www.keycloak.org/
However, often there comes a time when you have multiple applications that all need a shared user data store. (Note, I work for FusionAuth, so I am, to some extent, talking my book here.)
You then have some choices:
* run everything off of one app (both features and user management) and have other apps oauth/oidc into that app. This means that other apps are now dependent on one main app. Within that app, user data and feature data may get entangled
* hive off the user manangement and login data from the main app to a separate one and have other apps oauth/oidc into that second app. This lets you deploy/manage them separately and still have one user data store. Congrats, you've just invented an auth server! This can be a good option, but that refactoring may be a bit painful, and you're on the hook for maintaining the auth server (dependencies, adding workflows and functionality).
* stand up a separate auth server (or use a SaaS offering) and have apps oauth/oidc into it. In this scenario the auth server vendor is responsible for updates (adding new forms of MFA such as WebAuthn, for example) and your apps get the benefits from it. The issue here is that this is a core part of your app, so any downtime or integration issues due to an upgrade can cause major headaches. (At FusionAuth, we work around this issue with a single tenant model and by allowing you to pin your version.)
It's engineering, so there's no perfect solution. The above are some of the tradeoffs I've seen.
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...
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
This VC thing seems to take ID Tokens from OIDC providers a little further and also standardizes what claims you can expect.
JWTs are still profiled for their usage - the JWT you use under ACMEv2 is going to be different than the ID Tokens you get from OpenID Connect, or some bespoke cookie format by a product/site.
A VC-JWT is a profile JWTs for use with Verifiable Credentials. Part of this is adding new claims to hold JSON-LD formatted credential / presentation data.
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-...
In the theoretical use case of drinking, I couldn't just goto the bar on my 21st birthday, provide my ID, and buy a drink. I'd have make sure that I did whatever process was required to update my Verifiable Credential first?
I get the abstraction is great from a PII standpoint, and that likely this wouldn't be a big roadblock since this is all digital anyways. One assumes that the user could just press a big ol "refresh" button and be done in a few seconds. But still curious.
let birthday = "1998-08" # This value is taken from the user's verified credentials, in my case September 1998.
let ageRestriction = 21
let legalDate = new Date(new Date().setFullYear(new Date().getFullYear() - ageRestriction))
let birthdayDate = new Date(birthday)
if (legalDate > birthdayDate) console.log("Is that cash or card?")
else console.log("Sorry, you're not old enough.")
e2: Reading through the article after commenting (I know, I'm terrible and you can all violently detest me if you wish), there is an "ID card" example which clearly states the user's date of birth. Surely this is a prime use-case for OOP?
However, VCs have the concept of a 'presentation' which is what you show someone that wishes to verify something about you. The 'just show them the data and the digital signature' approach is one way to do presentations. But depending on the actual digital signature, you can also do presentations based on range proofs. Or general zero knowledge proofs.
So the issuer is not using range-proofs. Its the holder who is presenting his credentials that gets to do range proofs. That does depend on the issuer using specific kinds of signatures though.
Verifiable credentials is a terrible name. We have had verifiable cryptographic credentials for more than 40 years.
What I want, is a practical protocol to prove to a third party
1. That I am a real person (e.g, has a unique credential issued by my government)
2. That I'm the only one currently "logged in" with them, with that credential.
3. Without the third party, (and with as few parties as mathematically possible) knowing which of the people with a credential issued by my government I am.
In short, to prove that I'm a real person, that I'm not running an army of sockpuppets, and yet preserve my privacy.
For example, if the lower bound is hundreds then it's mostly superfluous since that information will eventually leak one way or another.
However, the availability and acceptability of even more widely acknowledged curves like Ed25519 and secp256k isn't there - neither is yet NIST certified for government usage, most HSMs (including phone secure enclaves) don't understand and thus can't protect or accelerate private key usage.
There are performance, complexity, security and general distrust issues with newer techniques, so you have to be a bit more selective on when you rely on them.
My expectation is that it will depend on use cases - credentials backed by an active relationship between the subject of the credential and the issuer can use a protocol to get batches of credentials, and salted hash trees can be used to allow for selective disclosure where needed, including providing precomputed predicate values. With simpler crypto, you could generate batches of short-lived credentials so that use is not linkable by the signature randomness.
For credentials which are meant to be long lived or which need to be maintained without backing hosted infrastructure, you'll see need for more advanced cryptographic techniques to prevent multiple disclosure of the same information to be correlated by the signature, or to allow predicates to be recomputed at presentation time.
This is where SD-jwt comes in - https://datatracker.ietf.org/doc/draft-fett-oauth-selective-..., which selectively offers pieces from that once-signed chunk of data.
There are mainly two different types one is "selective disclosure", where the verifier require some fields but it is up to the Holder to select which one to disclose.
The other one allows the Holder to create proofs about claims, like "I am over 18" without disclosing the birthday. The cryptography for this seems sound, but to be honest it is hard to grasp.
For a working example you could have a look at this:
https://github.com/mattrglobal/jsonld-signatures-bbs
Note: Auth0 currently doesn't support neither issuing or verifying this type of credentials.
I'm using TLS to ensure that I share the 'verifiable presentation' of my ID securely with, as I expected, cheapboozeforstudents.com.
But what's to stop that website from taking my student ID and showing it to statestudentaid.gov as proof that they're a student, allowing them to apply for a tuition grant in my name?
Is there a part where I put into my verifiable presentation that I am signing it because I believe I'm showing it to cheapboozeforstudents.com? So that if they try to pass that VP on to statestudentaid.gov the ID will be rejected?
i.e. you have to check imperial.ac.uk/.well-known/auth0-vc.pub or whatever, and if that matches, still all you know is that I have the key (or device, whatever), not necessarily that it was truly me. And if you don't check the issuer (or don't trust it's claim - impeerial.ac.uk says that the bearer has a degree from imperial.ac.uk for example) then it doesn't tell you anything.
Of course that's not really avoidable... but I can't think of a use case for this that doesn't just reduce to 'the issuer may as well just publish the contents' - it's useful when you want to only selectively share a credential from party A with party B, and it's something that B has reason to doubt/verify... but I can't think of an example?
It's a nice idea. But their "Try it out!" link (https://manage.auth0lab.com/) just returns "Error code: SSL_ERROR_RX_RECORD_TOO_LONG" for me (is it just me?)
> No proof mechanism is standardized but the data model is flexible enough to support various existing cryptographic mechanisms, such as digital signatures.
So why even have a standard at all? It is impossible to verify the proof using this standard, which is the main point of verifiable credentials, no?
The cryptographer in me's eye is twitching, as I consider all the completely different cryptosystems that will get shoved into "proof" that one would have to support, none of which seem to be spec'd out.
I guess I just don't get it. What does this actually help with?
For everyone feeling the kneejerk urge to downvote: https://www.bbc.com/news/world-asia-63456107
Rests. Survive.