Auth0 Verifiable Credentials

Like anything OAuth2-related, it&#x27;s frustratingly vague and jargony.<p>Verifiable credentials is a terrible name. We have had verifiable cryptographic credentials for more than 40 years.<p>What I want, is a practical protocol to prove to a third party<p>1. That I am a real person (e.g, has a unique credential issued by my government)<p>2. That I&#x27;m the only one currently &quot;logged in&quot; with them, with that credential.<p>3. Without the third party, (and with as few parties as mathematically possible) knowing <i>which</i> of the people with a credential issued by my government I am.<p>In short, to prove that I&#x27;m a real person, that I&#x27;m not running an army of sockpuppets, and yet preserve my privacy.

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.<p>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.<p>If something like Firebase Auth suits your use case, use that instead.

This places all the trust in the institution that mints verifiable credentials. (or the institution + Auth0 if they use Auth0).<p>This is good for use cases where you want to assert that an organization says something about you (e.g., you have a degree).<p>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).

I love that verifiable credentials are starting to make mainstream, but one thing I couldn’t glean from this page: is this purely VC from a perspective of “here’s the attributes I care to see”, or “here’s the characteristics I care to see”? To clarify: say I’m an alcohol vendor and wish to confirm that a user is 21 or older. Does the VC issuance provide a range proof that does not reveal the age, or does the VC issuance explicitly reveal the age?

The only thing the web identity ecosystem needs is another independent standard – said no one ever.<p>JWT is already a thing, as is X.509, OAuth&#x2F;OpenID, WebAuthn... Just use a combination of these that best fits your use case.<p>&quot;But this new standard will be the true unifying one&quot;. 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).

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).<p>[1]: <a href="https:&#x2F;&#x2F;openid.net&#x2F;connect&#x2F;" rel="nofollow">https:&#x2F;&#x2F;openid.net&#x2F;connect&#x2F;</a>

Call me a cynic but all this proves is that someone vouched for the stated credential being associated with a key I currently hold?<p>i.e. you have to check imperial.ac.uk&#x2F;.well-known&#x2F;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&#x27;t check the issuer (or don&#x27;t trust it&#x27;s claim - impeerial.ac.uk says that the bearer has a degree from imperial.ac.uk for example) then it doesn&#x27;t tell you anything.<p>Of course that&#x27;s not really avoidable... but I can&#x27;t think of a use case for this that doesn&#x27;t just reduce to &#x27;the issuer may as well just publish the contents&#x27; - it&#x27;s useful when you want to only selectively share a credential from party A with party B, <i>and</i> it&#x27;s something that B has reason to doubt&#x2F;verify... but I can&#x27;t think of an example?

Im interested to know why opt for basic asymmetric cryptography (is this like a ECDSA scheme?) when there are so many advances in zero knowledge proofs to allow for queryable data?

It&#x27;d be nice if you could just assert facts on a verifiable credential without giving over all the information, like I want to request from my bank that they assert I have regular income &gt; $x&#x2F;mo or a savings account with at least $y. Not like financial institutions will actually adopt this unless they&#x27;re forced to by regulation but I basically want to give people exactly enough to provide the service requested and no more.

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&#x2F;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&#x27;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&#x2F;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&#x2F;app&#x2F;user combination and it previously validated a few of them including an &quot;over 21&quot; 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&#x2F;countryside offline mode may be taken away from you.

Pretty sure this is the same technology as used for e.g. IBM Digital Health Pass, which underlies things like NY&#x27;s Excelsior Covid pass.

As a &quot;we authenticate everything&quot; company, it&#x27;s important for Auth0 to make it deadass simple for somebody to pay Auth0 (or Okta) to manage VCs. I think the idea is some company like CLEAR provides the authentication, and Auth0&#x2F;Okta provides the authorization. You go to buy a beer or check into a hotel, Auth0 contacts your Issuer for verification of your CredentialType, validates the credential, returns to the vendor that you&#x27;re really you, and you get the thing you want.<p>It&#x27;s a nice idea. But their &quot;Try it out!&quot; link (<a href="https:&#x2F;&#x2F;manage.auth0lab.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;manage.auth0lab.com&#x2F;</a>) just returns &quot;Error code: SSL_ERROR_RX_RECORD_TOO_LONG&quot; for me (is it just me?)

Looking at the credentialSubject and the rest of the format all I see is our friend SAML coming back to the limelight. Assertions, issuer, type, along with let&#x27;s overload all those optional fields inside of credentialSubject instead of making separate entities or objects.

I did not understand if this is somehow related to <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Self-sovereign_identity" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Self-sovereign_identity</a> or not.

What is the point here? Wikipedia tells me:<p>&gt; No proof mechanism is standardized but the data model is flexible enough to support various existing cryptographic mechanisms, such as digital signatures.<p>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?<p>The cryptographer in me&#x27;s eye is twitching, as I consider all the completely different cryptosystems that will get shoved into &quot;proof&quot; that one would have to support, none of which seem to be spec&#x27;d out.<p>I guess I just don&#x27;t get it. What does this actually help with?

Can&#x27;t immediately grasp how this avoids a MITM attack at the &#x27;verifiable presentation&#x27; stage. Am I missing something?

VCs are typically used in conjunction with DIDs. Do they say anywhere whether they’re using DIDs and, if so, which methods?

How is this fundamentally different than something like KeyBase other than the aspect of centralizing issuance control into the hands of large entities?

Wanted to take a look at the schemas linked, but identity0.io isn&#x27;t even registered? oO

And not a blockchain in site.

Next step: &quot;Unfortunately, Chrome can&#x27;t connect to the Internet right now. We at Google strive for a healthier, more responsible society. Please fill your vaccination details in the form below.&quot;<p>For everyone feeling the kneejerk urge to downvote: <a href="https:&#x2F;&#x2F;www.bbc.com&#x2F;news&#x2F;world-asia-63456107" rel="nofollow">https:&#x2F;&#x2F;www.bbc.com&#x2F;news&#x2F;world-asia-63456107</a>

Is this another KYC?

I would (and will) avoid anything like this by any cost.<p>Rests. Survive.

Ugh. The use cases listed. Sounds like a perfect match for the Chinese government.