Auth0 Verifiable Credentials
verifiablecredentials.dev
verifiablecredentials.dev
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.
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/
I'm curious what solution you ended up determining best fit your needs?
I'm someone looking for auth/security products. you won't reel me in like that.
FusionAuth has a dual deployment model. You can either run it locally (or host it yourself) for free, or you can pay us to run it for you. Most devs want to kick tires and run it locally, which is why the downloads page has those commands.
There are features that do require a license, but we have plenty of people running with plenty of MAU on the free version (we call it the 'community' edition).
Sorry if it wasn't clear.
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.
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 government site doesn't have to know anything about you either, other than you requested a beer token.
That's the 7th beer token you've requested this week, citizen. For your own good, we've denied your request.
Gov might require that on each sale, company re-verify identity (just like they demand you check ID on each sale).
That results in a network request to `proof.verificationMethod` on each sale, which contain a URL to the age verification for that one user.
Done. Gov now have records on how many times you bought beer. They might also request that the number/description of items be included on the verification request. but that is not necessary since credit cards are already being replaced with central bank issued payment systems (see india, brazil, etc)
You say decentralized, yet that Verifiable Data Registry seems like a central component to checking whether you are you. How is that not able to see that you checked your ID?
Also, the ID in the VC is not something that can easily be used to identify you. It may be in basic implementations, but it shouldn't. The W3C spec recommends using DID[1]... A DID is a random ID, basically, which is stored in the "distributed ledger" where others can find your current keys and other metadata (none of which containing personal data)... you can have as many DIDs as you want, e.g. one for each usage you make of your VCs, making it impossible to track you around... you should look at the W3C spec if you really want to understand how DIDs and VCs are supposed to work, the Auth0 website is a much lighter , pre-digested and somewhat more centralized version of things that make it much easier to get started (Which is a great thing, but hopefully you shouldn't judge VCs from only what they're pushing).
[1] https://www.w3.org/TR/vc-data-model/#dfn-decentralized-ident...
[0] https://www.spruceid.dev/quickstart
[1] https://en.wikipedia.org/wiki/Simple_public-key_infrastructu...
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.
When entities like Apple got in the mix the process got smoother. If your doctor uses Epic, the Health app can usually create a SMART credential directly from your medical records instead of downloading a state app.
It is cool that different entities were able to self organize and deliver a valuable service. It sucks that the Federal government backed away from any leadership role. People in Florida who had to travel abroad often got re-vaccinated at Walmart or in another state, because the Governor wanted to own the libs or whatever.
This is a little out there, but this thread is old enough at this point. I would say that COVID was something that improved my outlook in the future. Some aspects of the political landscape seem frankly, pretty dark and depressing. As someone who had a unique vantage point on aspects of the pandemic, I have to say that I saw the best of us demonstrated.
I think that ultimately the difficult adjustment from a 1970s economy to the services economy of today has created unrest and dissatisfaction that has and will change the US for years to come.
It is weird that Walmart has the same standing as a state health department. But ultimately, technology and standards like SMART allow us to trust assertions made by Walmart. I personally have issues with that, but it’s reality. Verifiable credentials are imo probably going to be one of the more powerful tools out there for lots of consumer to government or consumer to business use cases.
Slight correction here - the health record is already in the SMART format, e.g. already a signed JWT enveloping a FHIR vaccination record.
The Health App is turning encoding this into a custom URL scheme and tossing that into a QR code.
The reverse also works - I can scan the QR code and import it as a vaccination record into the health app.
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
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.
In the US, 21 is the "prove you can buy liquor" age and there's seldom a need to prove anything higher, outside of some unusual cases like becoming a member of Congress or President or something. No-one cares if you're 22 or 24 or 43.
You provide a document stating that "Mr. Foo Bar is depicted on this photo and was born on 1990-04-01" signed by them, and get one that just says "the person depicted on this photo is over 18/21", also signed by them.
This would save you a trip to the issuer.
You can disclose your full name and your birth date, or just the boolean value that you are over 21, depending on the use case.
Of course, many of these scenarios would be more logically served with a digital version of a national ID card or passport, but some countries use driving licenses in lieu of such concepts.
Depends on the relationship between the person and the issuer, which really means it depends on the use case.
For a credential that has to be usable independent from the issuer, such as wanting to be able to use a transcript even if the school goes bankrupt, you would generally want something long lived. The issuer might maintain a revocation mechanism, which might even be on a shared ledger so that it stays available even if the business entity goes away. It might be difficult to take the approach of precomputed predicate attributes, so you would be more inclined to use techniques like range proofs. You might also want to use cryptographic techniques to anonymize the signatures, so that the underlying crypto of the signed message doesn't become a correlation vector.
For a credential that is actively maintained as part of a relationship between two entities (which could include many things like citizenship, proof of driving and medical services/insurance proof), you can just have a short lived timespan for which the person has to fetch a new version. You don't necessarily need revocation except in the cases where you _need_ to have the information invalidated before it would naturally expire. You can also vend a 'stack' of credentials so that they can be used in multiple places without being linkable.
For this second case, you can just say 'age_over_21' as a statement which will be true for the day/week/month that that credential is valid to be presented. They would set the credential to become stale the day of your birthday, and your wallet would just fetch a new batch indicating the 'true' value.
This is the approach taken for instance by the ISO digital driving license spec.
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?
The idea here is, say, the DMV in your state knows your age. But you don't want to show your driver's license credential which includes your home address and exact birthdate at a bar, because it's not their need-to-know.
So you can ask the DMV to issue you with a "drinker's permit" which only has your photo and ageOver=21. A bar just validates you match your picture and knows you're of legal drinking age.
* Can only guess at the day, month, and/or year of their own birth.
* Cannot currently tell you their date of birth (e.g. incapacitated, incommunicado, unconscious, absent, or forgot. what year is it?)
* Cannot prove their date of birth (e.g. records destroyed)
* Mix up their relatives date of birth (the probability of this approaches 1 asymptotically as the family size increases)
* Use a different date format to you, with consequently ambiguous interpretation
Similar impedance mismatches between information and permission exist in almost all authorization domains. Consequently, the only credentials with general applicability are those capable of asserting a right or validating a claim, not those that merely sign data.
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.
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.
My country of citizenship has been issuing PIV(?)-based smartcards for more than a decade now, yet almost nobody could (and still can) verify them within the country, let alone abroad.
On the other hand, the EU digital Covid certificate project managed to get pretty widespread adoption in a short timeframe – with a vastly simpler technology stack backing it.
I'm really hoping the eIDAS project or a similar private initiative manages to use that momentum and bring (hopefully private) ID verification to the web. Whenever I "verify my identity" for a request to my bank by attaching a photo of my driver's license to an email, something in me dies...
That is most likely specific to your country and it's approach to deployment, your politics. Estonia mandated the availability of smartcard/PIV/mTLS authentication and it's now very widespread. Also really easy and free to implement.
> let alone abroad.
That is unwillingness to follow the EU standard from some EU countries and wish to reinvent the wheel (e.g. BankID and similar). I know that eIDAS-compliant PIV/smartcard implementations are cross-compliant e.g. Finland-Estonia-Latvia-Lithuania. But code-stealing Polish implementation for example isn't.
> On the other hand, the EU digital Covid certificate project managed to get pretty widespread adoption in a short timeframe – with a vastly simpler technology stack backing it.
Each country were given most of the stack required, they bypassed a lot of bullshit many countries have with software development.
> I'm really hoping the eIDAS project or a similar private initiative manages to use that momentum and bring (hopefully private) ID verification to the web.
When PSD2 required 2FA for banking, we had had it for more than five years at that point. So there is hope some EU legislation smooths these things out at some point, but it's going to be quite late.
Now they might not be running their own infrastructure, but they still have to be the one who authorized the credential to be minted. A faux digital National ID card issued from a random social network will likely not let you get access to government services or let you open a bank account, even if the data itself is all correct.
It is more likely that you'll have "trust frameworks" describing technical and logistical interoperability, and verifiers will accept any issuer that falls under that umbrella. In the US with driving licenses and state identification cards for example, that would likely be AAMVA.
This has the potential to eradicate several major avenues of fraud. The more of this is offered (for free) by governments the more it could majorly disrupt (=destroy) the industry around the topic.
Worldwide it seems there is a new, proprietary wallet each month, which naturally totally ruins this idea of having one wallet, but I see what is currently going on as a "storming phase" or almost "norming phase" already, that will eventually reach the "performing phase", with one or two wallets being the survivors. A big stumbling block here is that everyone involved wants a piece of the cake.
The European Union is actively (but slowly) working on this, e.g. with eIDAS. With eIDAS, you create a digital identity in your home country. If that home country DI offering supports eIDAS, you can use it to login to any other government AND private service implementing any DI offering that supports eIDAS.
> whether identity providers / VC providers are going to be 5 big firms
The big firms will provide the ecosystem (e.g. Microsoft Entra, mastercard-id-for-rp, ...), the real identity verification will happen through offerings like Onfido, Jumio and the 1000 other offerings in the space.
For example:
- date of birth: issued by your government and equivalent to your birth certificate.
- Occuppational credentials: issued by the relevant, government-authorized organization, like Engineers Australia or whatever.
- Driver's License: issued by the traffic authority in your country/state.
- Proof of Vaccination: this is interesting, as COVID showed... in my country, it was private organizations issuing that, but they had to be approve by the Government.
The only credentials the big social media companies can issue for you just prove you have a certain handle with them, I guess... which could be used for a more secure "Sign in with Google/Apple/GitHub" for example. But nearly all interesting credentials would be issued by real-world authorities, IMHO.
But yes indeed, private companies do not have much valuable credentials to offer. There just aren't that many categories of personal data you'd ever want to have in a wallet.
But who's going to trust those vendors? This is the job of the government IMO, one of the few things you just can't rely on the private sector for. I definitely don't want my birth certificate credential tied to, say, Google :D the Government cannot , for example, remove my credentials because I said something polemic, while Google (and infamously Twitter) most definitely can and seem quite happy to do if they can.
We will find out in the coming years...
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.
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.
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.
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-...
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.
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
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?
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.
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.
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.
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?
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?
It does rely on statestudentaid.gov actually validating said assertion, of course, but that's only like... The second most common screw up with JWTs and related tokens.
But yeah, the issue here is that when you present your student ID to anyone, you are relying to some extent on every single other service that accepts student ID to be validating the audience assertion. That's not a great trust model.
https://www.w3.org/TR/vc-data-model/#concrete-lifecycle-exam...
It's always contingent on the recipient of an identity proof to verify that it's valid; I'm not sure I understand the criticism to be honest.
For digital ID, such a statement could be "only person Foo Bar knows the private key that corresponds to this public key, and they use that one for verifying their age, but not for voting or opening new bank accounts".
I do see the UX concern, though: The European digital Covid certificate works in exactly this way ("Foo Bar is fully vaccinated against Covid as of April 1st"), making no claim of the form "the person showing you this QR code is Foo Bar" or "the person presenting this code is vaccinated" – yet this is how it was and is unfortunately still often used.
It also includes elements in the request for a presentation - a non-repeating nonce and the domain to make it an interactive challenge.
The ability to prevent MITM depends on how well the wallet/protocol does web domain binding.
For everyone feeling the kneejerk urge to downvote: https://www.bbc.com/news/world-asia-63456107
Rests. Survive.