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

61–70 of 134 posts

Re: Auth0 Verifiable Credentials

#61

Post by lxgr »

Avamander wrote: post #26
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.

Feels like reinventing the past, looking at what people have done with just x509/PKI in multiple European countries. Though that's not to say there aren't a few fun ideas in there, it just seems much less mature with many mistakes repeated.

Federation and acceptance are key.

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

Re: Auth0 Verifiable Credentials

#62

Post by worthless-trash »

Alupis wrote: post #30
tomjen3 wrote: post #9

Earlier quoted context omitted.

Anonymous verification of age is a nice one: Site a generates a bit of bytes, you then take that to a government portal, login and get it signed, then you return with the signature and now the site knows nothing whatsoever about you, other than that you could get a government site to assert that you are old enough to order beer online. The government site doesn't have to know anything about you either, other than you…

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

Its funny you mention this, this -exact- thing happened with one of the delivery companies in australia.

Re: Auth0 Verifiable Credentials

#63

Post by ezfe »

Spooky23 wrote: post #51
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).

You can do that by having consortiums of trusted parties. California, New York and Walmart were pioneers in this space for vaccination credentials. (SMART health cards) 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…

Massachusetts also now issues SMART cards

Re: Auth0 Verifiable Credentials

#64

Post by inopinatus »

Natfan wrote: post #40
NovemberWhiskey wrote: post #27

Earlier quoted context omitted.

You could issue the credential with an "ageOver" property set to 21; use of abstract claims like that is actually a non-normative preference in the W3C standard. https://www.w3.org/TR/vc-data-model/#favor-abstract-claims

Surely you'd store their birthdate (or maybe birth year and month for privacy reasons). Then you only allow people who you know are older than 21, those born before (not in) 2001-11 (based on currentYear of 2022). With the magic of modern JavaScript, this shouldn't be too hard: let birthday = "1998-08" # This value is taken from the user's verified credentials, in my case September 1998. let ageRestriction = 21 let l…

Heck, I can't remember how old I am. Pretty sure I'm over 21 though, and most authorities would agree after a cursory visual inspection. There are also folks who:

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

Re: Auth0 Verifiable Credentials

#65

Post by mastazi »

naikrovek wrote: post #45
boosteri wrote: post #42

Earlier quoted context omitted.

Genuinely interested what calendar you're using where 08 represents September?

months sometimes start at zero in programming languages. days of the week, as well, often.

there is also the problem that in some locales the first day of the week is thought to be Sunday rather than Monday, so regardless of 0-indexing or not, we can't even agree on that IRL :-D

Re: Auth0 Verifiable Credentials

#66

Post by yazzku »

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?

The W3C?

Re: Auth0 Verifiable Credentials

#67

Post by yazzku »

jameshart wrote: post #49
hirsin wrote: post #46

Earlier quoted context omitted.

Yep,proof of possession - the ID contains a public key, you own the matching private key. You send them the ID with a matching assertion ("This is meant for cheapboozeforstudents.com"), signed by your private key. The website can't in turn generate an assertion for statestudentaid.gov because the whole envelope (ID, assertion, signature) is uniquely tied to them. It does rely on statestudentaid.gov actually validatin…

And... cheapboozeforstudents can't fool me into generating an assertion for statestudentaid.gov by showing me statestudentaid.gov's presentation request? 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.

You (client) wouldn't accept a statestudentaid.gov presentation request coming from cheapboozeforstudents.com.

Re: Auth0 Verifiable Credentials

#68

Post by justsomeadvice0 »

What is the point here? Wikipedia tells 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?

Re: Auth0 Verifiable Credentials

#69

Post by dwaite »

ShakataGaNai wrote: post #35
NovemberWhiskey wrote: post #27

Earlier quoted context omitted.

You could issue the credential with an "ageOver" property set to 21; use of abstract claims like that is actually a non-normative preference in the W3C standard. https://www.w3.org/TR/vc-data-model/#favor-abstract-claims

Maybe this is a silly question. But wouldn't this just mean that the ID would need to be updated very regularly? Like at least every year if not more frequently? 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 fr…

> Maybe this is a silly question. But wouldn't this just mean that the ID would need to be updated very regularly? Like at least every year if not more frequently?

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.

Re: Auth0 Verifiable Credentials

#70

Post by dwaite »

lxgr wrote: post #58
NovemberWhiskey wrote: post #36

Earlier quoted context omitted.

You don't update that property unless there would be a need to prove the age was above some other number. Otherwise I think you're on the right track. As you said, you'd update it when you turned 18 or 21 etc. 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 i…

The DMV (or whoever issues widely accepted identity documents in your country) could also provide a service that can exchange precise assertions to more private ones, i.e. one that allows the following transaction: 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 sig…

For mobile drivers licenses in ISO 18013-5, the credential is a signed list of salted hashes, each representing a distinct named attribute. You release the credential as well as whatever attributes which were requested.

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.

Post reply on HN