Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Auth0 Verifiable Credentials

verifiablecredentials.dev

Post reply on HN
Print view View original

71–80 of 134 posts

Re: Auth0 Verifiable Credentials

#71

Post by dane-pgp »

PeeMcGee wrote: post #38
Alupis wrote: post #20

Earlier quoted context omitted.

The biggest problem with OIDC is how non-standard every implementation is. 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! Cla…

> The biggest problem with OIDC is how non-standard every implementation is. 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...

The most relevant section is perhaps this:

> 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.

Re: Auth0 Verifiable Credentials

#72

Post by dwaite »

probablypat wrote: post #39
paxys wrote: post #12

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.

Who determines the standards for Authentication? Is there a main working group?

It is somewhat split.

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.

Re: Auth0 Verifiable Credentials

#74

Post by dwaite »

lifeisstillgood wrote: post #37
Traubenfuchs wrote: post #18

Earlier quoted context omitted.

Offerings in the SSI/VD space are currently exploding -some even government backed. Microsoft, MasterCard, Auth0, the European Union are the biggest players that come to my mind. This will turn the whole billion dollar kyc/identity verification space upside down. I work in that space.

Would you mind expanding on the how ? I am trying to get a handle on whether identity providers / VC providers are going to be 5 big firms or if everyone will do it like everyone used to have a office stamp for banging a red inked logo onto documents

I would expect the VC providers will be the issuing authorities - you won't get a digital driving license from Facebook, you'll get it from the DMV.

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.

Re: Auth0 Verifiable Credentials

#75

Post by dwaite »

woodruffw wrote: post #17

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/

As someone else pointed out, there is work in OpenID Connect to support this model.

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.

Re: Auth0 Verifiable Credentials

#76

Post by dwaite »

Alupis wrote: post #10
Aeolun wrote: post #8

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.

JWT is a way to express claims. JWS is the underlying data format.

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.

Re: Auth0 Verifiable Credentials

#78

Post by dwaite »

jameshart wrote: post #43
NovemberWhiskey wrote: post #31

Earlier quoted context omitted.

That's a transport problem - you would use TLS.

So, I go to cheapboozeforstudents.com, to buy some cheap booze, and they ask me to show my student ID to qualify for the cheap booze. 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 f…

Presentation is typically signed with a proof, e.g. of possession of the private key.

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.

Re: Auth0 Verifiable Credentials

#79

Post by dwaite »

dudebod wrote: post #28

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?

There are experiments using ZKPs and pairing based schemes, going all the way back to Anonymous Credentials work.

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.

Re: Auth0 Verifiable Credentials

#80

Post by dwaite »

CleverLikeAnOx wrote: post #2

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).

> 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 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.

Post reply on HN