14 ms·

Auth0 Verifiable Credentials

229 points by marcosnils 4y ago

vladcodes 4y ago
I would (and will) avoid anything like this by any cost. Rests. Survive.
thesimon 4y ago
Wanted to take a look at the schemas linked, but identity0.io isn't even registered? oO
- red_Seashell_32 4y ago
  They don’t have SSL enabled (or properly configured). But even with that in mind - it doesn’t work. http://identity0.io/contexts/v1 http://identity0.io/contexts/v1
  - remram 4y ago
    Judging by the whois it might have been created by someone who saw this post.
CleverLikeAnOx 4y ago
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).
- chetanbhasin 4y ago
  But I think it's a good use case for organization issued IDs, tickets, or even things like driver's license.
  - CleverLikeAnOx 4y ago
    Agreed! I think this is the start of something that will be big in a decade as adoption goes up.
    - tomjen3 4y ago
      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 requested a beer token.
      - Alupis 4y ago
        > 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.
        worthless-trash 4y ago
        Its funny you mention this, this -exact- thing happened with one of the delivery companies in australia.
        brabel 4y ago
        That's not how it works. You would just request a VC that states personal information about you from the government, including age (like an ID card which most countries have)... then, when you're required to prove you're a certain age, you can create a presentation object which only contains your age, nothing else. You can present that as many times as you want without the government knowing you did that (unless the receiver of the presentation decides it wants to inform the government about that! In which case there's nothing technology can do to help).
- paxys 4y ago
  It works for both use cases. The only difference between the two is the source of trust (in case 1 it is some issuing authority, in case 2 it is you). There's no reason why you can't issue a certificate for yourself. The receiving party can choose to trust your public key if they wish.
- wyc 4y ago
  Anyone with a keypair can issue verifiable credentials, and we work on making this simple[0], starting with developers. However, the ultimate challenge will be to be able to associate that keypair to the entity (or abstracted entity) who is making those statements, which is what Web of Trust tried to do, and there are some adjacent efforts to revitalize SPKI-style[1] trust models that are being discussed at RWoT[2]. [0] https://www.spruceid.dev/quickstart https://www.spruceid.dev/quickstart [1] https://en.wikipedia.org/wiki/Simple_public-key_infrastructure https://en.wikipedia.org/wiki/Simple_public-key_infrastructu... [2] https://github.com/WebOfTrustInfo/rwot11-the-hague https://github.com/WebOfTrustInfo/rwot11-the-hague
- Spooky23 4y ago
  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 their ticketing workflow.
  - ezfe 4y ago
    Massachusetts also now issues SMART cards
  - chrisweekly 4y ago
    I find it interesting that US states and a massive corporation are directly comparable entities (CA, NY, Walmart, MA) in this context.
    - Spooky23 4y ago
      Well states operate vaccine registries, but some states for political reasons chose to not really do a good job with them or not issue usable credentials beyond the CDC card. Also, rural states tended to rely more on larger entities like Walmart and pharmacies to deliver vaccinations — Walmart is often the most accessible place for healthcare, food, medicines, etc. 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.
      - chrisweekly 4y ago
        Ok sure, thanks. I was just sharing a simple observation that I found [a relevant verifiable fact] interesting. States and corporations aren't usually peers like that. I'd hoped it might trigger discussion of post-national society or Citizen's United or something else ~interesting and not just silent downvotes. Anyway, thanks for your response, it makes sense and was informative.
- dwaite 4y ago
  > 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.
- thedougd 4y ago
  I went the Cognito route for customer facing, however there were a couple of gotchas: - 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
adontz 4y ago
I did not understand if this is somehow related to https://en.wikipedia.org/wiki/Self-sovereign_identity https://en.wikipedia.org/wiki/Self-sovereign_identity or not.
- lxgr 4y ago
  This seems to me like SSI minus the blockchain – which seems like a good idea. A widely used schema for verifiable statements seems incredibly useful.
Aeolun 4y ago
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).
- deleted 4y ago
  [deleted]
- Alupis 4y ago
  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.
  - woodruffw 4y ago
    Hmm, I don't know if it's consider JWT to be "just a data format". It's an envelope format (dotted base64'd JSON), combined with a schema for each component in the envelope. That scheme isn't particularly strict when it comes to the payload component, but that doesn't mean it isn't a schema. 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-connect-discovery/ https://swagger.io/docs/specification/authentication/openid-...
  - dwaite 4y ago
    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.
- encryptluks2 4y ago
  It appears to be similar to regular public/private key encryption but with a fancy name to make it seem unique.
paxys 4y ago
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.
- bdcravens 4y ago
  https://xkcd.com/927/ https://xkcd.com/927/
- Traubenfuchs 4y ago
  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.
  - Avamander 4y ago
    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.
    - lxgr 4y ago
      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...
woodruffw 4y ago
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/ https://openid.net/connect/
- Alupis 4y ago
  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! 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.
  - woodruffw 4y ago
    I agree completely about OIDC's discovery limitations! If this standard can improve along that axis, then that alone will make it a valuable contribution to the identity space. 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.
  - PeeMcGee 4y ago
    > 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/dd2d4dfc86f7d13045ad715377b6a48f https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a...
NovemberWhiskey 4y ago
Pretty sure this is the same technology as used for e.g. IBM Digital Health Pass, which underlies things like NY's Excelsior Covid pass.
cassonmars 4y ago
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?
- NovemberWhiskey 4y ago
  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 https://www.w3.org/TR/vc-data-model/#favor-abstract-claims
  - ShakataGaNai 4y ago
    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.
    - NovemberWhiskey 4y ago
      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.
etchalon 4y ago
And not a blockchain in site.
dudebod 4y ago
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?
- hirsin 4y ago
  It's tricky when the whole chunk of data is only signed over once by your issuer - you can't go back to the government for a new token every time you want to give out your first name instead of first and last name. This is where SD-jwt comes in - https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/ https://datatracker.ietf.org/doc/draft-fett-oauth-selective-..., which selectively offers pieces from that once-signed chunk of data.
- dwaite 4y ago
  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.
jameshart 4y ago
Can't immediately grasp how this avoids a MITM attack at the 'verifiable presentation' stage. Am I missing something?
- NovemberWhiskey 4y ago
  That's a transport problem - you would use TLS.
  - jameshart 4y ago
    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 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?
    - hirsin 4y ago
      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 validating said assertion, of course, but that's only like... The second most common screw up with JWTs and related tokens.
      - jameshart 4y ago
        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.
pfraze 4y ago
VCs are typically used in conjunction with DIDs. Do they say anywhere whether they’re using DIDs and, if so, which methods?
- dwaite 4y ago
  This labs project appears to currently use did:web for the issuer, and did:ethr for the subject.
  - jfroma 4y ago
    - When auth0 act as an issuer, it issue credentials with did:web - when auth0 act as a verifier it can verify credentials and presentations issued with: did:web, did:key, did:ethr and did:ion - The provided demo wallet at https://wallet.verifiablecredentials.dev/ https://wallet.verifiablecredentials.dev/ supports did:key, did:ion and did:ethr
    - pfraze 4y ago
      Thanks (both) for the info!
siliconc0w 4y ago
It'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 > $x/mo or a savings account with at least $y. Not like financial institutions will actually adopt this unless they're forced to by regulation but I basically want to give people exactly enough to provide the service requested and no more.
- coolestguy 4y ago
  https://blockheadtechnologies.com/zero-knowledge-proofs-a-powerful-addition-to-blockchain/ https://blockheadtechnologies.com/zero-knowledge-proofs-a-po...
- jfroma 4y ago
  This is possible currently with zero knowledge proofs. 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 https://github.com/mattrglobal/jsonld-signatures-bbs Note: Auth0 currently doesn't support neither issuing or verifying this type of credentials.
justsomeadvice0 4y ago
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?
6510 4y ago
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/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'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/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/app/user combination and it previously validated a few of them including an "over 21" 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/countryside offline mode may be taken away from you.
transfire 4y ago
Ugh. The use cases listed. Sounds like a perfect match for the Chinese government.
throwaway892238 4y ago
As a "we authenticate everything" company, it'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/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're really you, and you get the thing you want. It's a nice idea. But their "Try it out!" link (https://manage.auth0lab.com/ https://manage.auth0lab.com/) just returns "Error code: SSL_ERROR_RX_RECORD_TOO_LONG" for me (is it just me?)
vintermann 4y ago
Like anything OAuth2-related, it's frustratingly vague and jargony. 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.
- enricotal 4y ago
  Verifiable credentials (VC) It's a name that comes from: https://www.w3.org/TR/vc-data-model/ https://www.w3.org/TR/vc-data-model/
  - vdfs 4y ago
    Funny how identity0.io (from the website example) was registered less than 24 hours ago
    - red_Seashell_32 4y ago
      It’s likely that someone else registered that. When this was posted, domain was still not taken
      - jaywalk 4y ago
        That's a pretty egregious error from a company as large as Auth0/Okta.
        red_Seashell_32 4y ago
        Indeed! My initial thought was that they just misconfigured SSL, but other user here pointed out that it’s likely taken by someone else
robbie-c 4y ago
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. 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.
- webloem 4y ago
  Can confirm, also very dissapointed with Auth0. We have been happily using Auth0 for years within their self-service license tier. Unfortunately we are now in the process of migrating away from Auth0 on short notice. 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.
  - robertlagrant 4y ago
    I can also confirm that their sales org is very disappointing. The technical side is excellent.
- methyl 4y ago
  Can confirm, it got downhill once they got acquired by Okta. 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?
  - webloem 4y ago
    We did quite a bit of research into this. 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/ https://clerk.dev/ [1] https://supertokens.com/ https://supertokens.com/ [2] https://www.ory.sh/ https://www.ory.sh/ [3] https://fusionauth.io/ https://fusionauth.io/ [4] https://www.keycloak.org/ https://www.keycloak.org/
leovander 4y ago
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's overload all those optional fields inside of credentialSubject instead of making separate entities or objects.
egorfine 4y ago
Is this another KYC?
OJFord 4y ago
Call me a cynic but all this proves is that someone vouched for the stated credential being associated with a key I currently hold? 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?
- vdfs 4y ago
  Right, and to better illustrate this problem, they have a link in "verificationMethod" pointing to identity0.io domain, it was registered by just yesterday, could be just someone snatching that domain
ccbccccbbcccbb 4y ago
Next step: "Unfortunately, Chrome can'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." For everyone feeling the kneejerk urge to downvote: https://www.bbc.com/news/world-asia-63456107 https://www.bbc.com/news/world-asia-63456107
tristor 4y ago
How is this fundamentally different than something like KeyBase other than the aspect of centralizing issuance control into the hands of large entities?

229 points by marcosnils 4y ago

vladcodes 4y ago

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

thesimon 4y ago

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

red_Seashell_32 4y ago
They don’t have SSL enabled (or properly configured). But even with that in mind - it doesn’t work. http://identity0.io/contexts/v1 http://identity0.io/contexts/v1
- remram 4y ago
  Judging by the whois it might have been created by someone who saw this post.

CleverLikeAnOx 4y ago

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

chetanbhasin 4y ago
But I think it's a good use case for organization issued IDs, tickets, or even things like driver's license.
- CleverLikeAnOx 4y ago
  Agreed! I think this is the start of something that will be big in a decade as adoption goes up.
  - tomjen3 4y ago
    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 requested a beer token.
    - Alupis 4y ago
      > 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.
      - worthless-trash 4y ago
        Its funny you mention this, this -exact- thing happened with one of the delivery companies in australia.
      - brabel 4y ago
        That's not how it works. You would just request a VC that states personal information about you from the government, including age (like an ID card which most countries have)... then, when you're required to prove you're a certain age, you can create a presentation object which only contains your age, nothing else. You can present that as many times as you want without the government knowing you did that (unless the receiver of the presentation decides it wants to inform the government about that! In which case there's nothing technology can do to help).
paxys 4y ago
It works for both use cases. The only difference between the two is the source of trust (in case 1 it is some issuing authority, in case 2 it is you). There's no reason why you can't issue a certificate for yourself. The receiving party can choose to trust your public key if they wish.
wyc 4y ago
Anyone with a keypair can issue verifiable credentials, and we work on making this simple[0], starting with developers. However, the ultimate challenge will be to be able to associate that keypair to the entity (or abstracted entity) who is making those statements, which is what Web of Trust tried to do, and there are some adjacent efforts to revitalize SPKI-style[1] trust models that are being discussed at RWoT[2]. [0] https://www.spruceid.dev/quickstart https://www.spruceid.dev/quickstart [1] https://en.wikipedia.org/wiki/Simple_public-key_infrastructure https://en.wikipedia.org/wiki/Simple_public-key_infrastructu... [2] https://github.com/WebOfTrustInfo/rwot11-the-hague https://github.com/WebOfTrustInfo/rwot11-the-hague
Spooky23 4y ago
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 their ticketing workflow.
- ezfe 4y ago
  Massachusetts also now issues SMART cards
- chrisweekly 4y ago
  I find it interesting that US states and a massive corporation are directly comparable entities (CA, NY, Walmart, MA) in this context.
  - Spooky23 4y ago
    Well states operate vaccine registries, but some states for political reasons chose to not really do a good job with them or not issue usable credentials beyond the CDC card. Also, rural states tended to rely more on larger entities like Walmart and pharmacies to deliver vaccinations — Walmart is often the most accessible place for healthcare, food, medicines, etc. 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.
    - chrisweekly 4y ago
      Ok sure, thanks. I was just sharing a simple observation that I found [a relevant verifiable fact] interesting. States and corporations aren't usually peers like that. I'd hoped it might trigger discussion of post-national society or Citizen's United or something else ~interesting and not just silent downvotes. Anyway, thanks for your response, it makes sense and was informative.
dwaite 4y ago
> 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.
thedougd 4y ago
I went the Cognito route for customer facing, however there were a couple of gotchas: - 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

adontz 4y ago

I did not understand if this is somehow related to https://en.wikipedia.org/wiki/Self-sovereign_identity https://en.wikipedia.org/wiki/Self-sovereign_identity or not.

lxgr 4y ago
This seems to me like SSI minus the blockchain – which seems like a good idea. A widely used schema for verifiable statements seems incredibly useful.

Aeolun 4y ago

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

deleted 4y ago
[deleted]
Alupis 4y ago
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.
- woodruffw 4y ago
  Hmm, I don't know if it's consider JWT to be "just a data format". It's an envelope format (dotted base64'd JSON), combined with a schema for each component in the envelope. That scheme isn't particularly strict when it comes to the payload component, but that doesn't mean it isn't a schema. 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-connect-discovery/ https://swagger.io/docs/specification/authentication/openid-...
- dwaite 4y ago
  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.
encryptluks2 4y ago
It appears to be similar to regular public/private key encryption but with a fancy name to make it seem unique.

paxys 4y ago

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.

bdcravens 4y ago
https://xkcd.com/927/ https://xkcd.com/927/
Traubenfuchs 4y ago
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.
- Avamander 4y ago
  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.
  - lxgr 4y ago
    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...

woodruffw 4y ago

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/ https://openid.net/connect/

Alupis 4y ago
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! 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.
- woodruffw 4y ago
  I agree completely about OIDC's discovery limitations! If this standard can improve along that axis, then that alone will make it a valuable contribution to the identity space. 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.
- PeeMcGee 4y ago
  > 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/dd2d4dfc86f7d13045ad715377b6a48f https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a...

NovemberWhiskey 4y ago

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

cassonmars 4y ago

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?

NovemberWhiskey 4y ago
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 https://www.w3.org/TR/vc-data-model/#favor-abstract-claims
- ShakataGaNai 4y ago
  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.
  - NovemberWhiskey 4y ago
    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.

etchalon 4y ago

And not a blockchain in site.

dudebod 4y ago

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?

hirsin 4y ago
It's tricky when the whole chunk of data is only signed over once by your issuer - you can't go back to the government for a new token every time you want to give out your first name instead of first and last name. This is where SD-jwt comes in - https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/ https://datatracker.ietf.org/doc/draft-fett-oauth-selective-..., which selectively offers pieces from that once-signed chunk of data.
dwaite 4y ago
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.

jameshart 4y ago

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

NovemberWhiskey 4y ago
That's a transport problem - you would use TLS.
- jameshart 4y ago
  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 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?
  - hirsin 4y ago
    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 validating said assertion, of course, but that's only like... The second most common screw up with JWTs and related tokens.
    - jameshart 4y ago
      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.

pfraze 4y ago

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

dwaite 4y ago
This labs project appears to currently use did:web for the issuer, and did:ethr for the subject.
- jfroma 4y ago
  - When auth0 act as an issuer, it issue credentials with did:web - when auth0 act as a verifier it can verify credentials and presentations issued with: did:web, did:key, did:ethr and did:ion - The provided demo wallet at https://wallet.verifiablecredentials.dev/ https://wallet.verifiablecredentials.dev/ supports did:key, did:ion and did:ethr
  - pfraze 4y ago
    Thanks (both) for the info!

siliconc0w 4y ago

It'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 > $x/mo or a savings account with at least $y. Not like financial institutions will actually adopt this unless they're forced to by regulation but I basically want to give people exactly enough to provide the service requested and no more.

coolestguy 4y ago
https://blockheadtechnologies.com/zero-knowledge-proofs-a-powerful-addition-to-blockchain/ https://blockheadtechnologies.com/zero-knowledge-proofs-a-po...
jfroma 4y ago
This is possible currently with zero knowledge proofs. 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 https://github.com/mattrglobal/jsonld-signatures-bbs Note: Auth0 currently doesn't support neither issuing or verifying this type of credentials.

justsomeadvice0 4y ago

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?

6510 4y ago

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/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'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/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/app/user combination and it previously validated a few of them including an "over 21" 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/countryside offline mode may be taken away from you.

transfire 4y ago

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

throwaway892238 4y ago

As a "we authenticate everything" company, it'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/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're really you, and you get the thing you want. It's a nice idea. But their "Try it out!" link (https://manage.auth0lab.com/ https://manage.auth0lab.com/) just returns "Error code: SSL_ERROR_RX_RECORD_TOO_LONG" for me (is it just me?)

vintermann 4y ago

Like anything OAuth2-related, it's frustratingly vague and jargony. 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.

enricotal 4y ago
Verifiable credentials (VC) It's a name that comes from: https://www.w3.org/TR/vc-data-model/ https://www.w3.org/TR/vc-data-model/
- vdfs 4y ago
  Funny how identity0.io (from the website example) was registered less than 24 hours ago
  - red_Seashell_32 4y ago
    It’s likely that someone else registered that. When this was posted, domain was still not taken
    - jaywalk 4y ago
      That's a pretty egregious error from a company as large as Auth0/Okta.
      - red_Seashell_32 4y ago
        Indeed! My initial thought was that they just misconfigured SSL, but other user here pointed out that it’s likely taken by someone else

robbie-c 4y ago

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

webloem 4y ago
Can confirm, also very dissapointed with Auth0. We have been happily using Auth0 for years within their self-service license tier. Unfortunately we are now in the process of migrating away from Auth0 on short notice. 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.
- robertlagrant 4y ago
  I can also confirm that their sales org is very disappointing. The technical side is excellent.
methyl 4y ago
Can confirm, it got downhill once they got acquired by Okta. 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?
- webloem 4y ago
  We did quite a bit of research into this. 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/ https://clerk.dev/ [1] https://supertokens.com/ https://supertokens.com/ [2] https://www.ory.sh/ https://www.ory.sh/ [3] https://fusionauth.io/ https://fusionauth.io/ [4] https://www.keycloak.org/ https://www.keycloak.org/

leovander 4y ago

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's overload all those optional fields inside of credentialSubject instead of making separate entities or objects.

egorfine 4y ago

Is this another KYC?

OJFord 4y ago

Call me a cynic but all this proves is that someone vouched for the stated credential being associated with a key I currently hold? 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?

vdfs 4y ago
Right, and to better illustrate this problem, they have a link in "verificationMethod" pointing to identity0.io domain, it was registered by just yesterday, could be just someone snatching that domain

ccbccccbbcccbb 4y ago

Next step: "Unfortunately, Chrome can'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." For everyone feeling the kneejerk urge to downvote: https://www.bbc.com/news/world-asia-63456107 https://www.bbc.com/news/world-asia-63456107

tristor 4y ago

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