Auth0 Verifiable Credentials

I imagined one time a system a bit like a chat protocol where parties exchange many messages over a long time where the geolocation, the computer and the application are parties too. The parties each have many different kinds of credentials, one for each purpose. It would start with requesting verification for the application, it can ask step/level 1 from any party, device or application with sufficient authentication for level 1 verification of applications. (The fridge can reject the task if it doesn't feel like participating.) Level 2 is done after a few hours at a party that can do level 2 verification. The toaster like the fridge may forward the request to a different party with sufficient trust level to record, process and forward the auth request (if it feels like it) The initial party is kept in the dark on how wide spread their app auth request has been processed. Processing auth requests that enjoyed some further validation also gradually improves the trust level of the processing party. Countless handshakes take place over many years with countless other parties of increasing trust that may or may not preserve the exchange and/or geolocation. Eventually the sum of the computer, app and user credentials allows the generation of a qr code or a link that expires after 5 min or single use, which ever comes first but it will grow towards 7 days and 100 uses at security level 1. So the local pub has some potentially off-line semi-usable hand shakes from a machine/app/user combination and it previously validated a few of them including an "over 21" with a car in the neighborhood and a vending machine. Those can confirm the toaster indeed forwarded an auth request to them. Neither party needs internet, everything just works. Persecution may start long before you get to buy booze or rent a bicycle or it will catch up with you eventually. Post apocalyptic/countryside offline mode may be taken away from you.

I would (and will) avoid anything like this by any cost.

Rests. Survive.

That's not how it works. You would just request a VC that states personal information about you from the government, including age (like an ID card which most countries have)... then, when you're required to prove you're a certain age, you can create a presentation object which only contains your age, nothing else. You can present that as many times as you want without the government knowing you did that (unless the receiver of the presentation decides it wants to inform the government about that! In which case there's nothing technology can do to help).

The concept of a VC is orthogonal to JWTs. You can use a JWT to embed a VC:

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.

Tangentially, if you’re a B2C startup like an app, avoid using auth0. Their pricing starts out cheap but once you hit 10k MAU, it’ll go from $X00 a month to a 3 year contract for $X00000.

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.