Can't immediately grasp how this avoids a MITM attack at the 'verifiable presentation' stage. Am I missing something?
That's a transport problem - you would use TLS.
Auth0 Verifiable Credentials
31–40 of 134 posts
Re: Auth0 Verifiable Credentials
#32VCs are typically used in conjunction with DIDs. Do they say anywhere whether they’re using DIDs and, if so, which methods?
Re: Auth0 Verifiable Credentials
#33I 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/
For extra context, there is currently work ongoing in the OIDC standards community to support Verifiable Credential Issuance[0] as well.
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...
Re: Auth0 Verifiable Credentials
#34The 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.
I'm not sure that anyone seriously implementing verifiable credentials has claimed that it's the "true unifying one [standard]", as it's just a data model represented as JSON. So, unfortunately this comment reads to me as an uninformed strawman argument.
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.
Re: Auth0 Verifiable Credentials
#35I 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 issua…
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 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.
Re: Auth0 Verifiable Credentials
#36Earlier 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…
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 if you're 22 or 24 or 43.
Re: Auth0 Verifiable Credentials
#37The 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.
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
Re: Auth0 Verifiable Credentials
#38I 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/
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...
Re: Auth0 Verifiable Credentials
#39The 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?
Re: Auth0 Verifiable Credentials
#40I 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 issua…
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 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?