Auth0 Verifiable Credentials(verifiablecredentials.dev)
verifiablecredentials.dev
Auth0 Verifiable Credentials
https://verifiablecredentials.dev/
133 comments
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/
Funny how identity0.io (from the website example) was registered less than 24 hours ago
It’s likely that someone else registered that. When this was posted, domain was still not taken
That's a pretty egregious error from a company as large as Auth0/Okta.
Indeed! My initial thought was that they just misconfigured SSL, but other user here pointed out that it’s likely taken by someone else
What makes you believe that the fewest parties mathematically possible is meaningfully small?
For example, if the lower bound is hundreds then it's mostly superfluous since that information will eventually leak one way or another.
For example, if the lower bound is hundreds then it's mostly superfluous since that information will eventually leak one way or another.
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.
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.
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.
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.
I can also confirm that their sales org is very disappointing. The technical side is excellent.
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?
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?
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/ [1] https://supertokens.com/ [2] https://www.ory.sh/ [3] https://fusionauth.io/ [4] https://www.keycloak.org/
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/ [1] https://supertokens.com/ [2] https://www.ory.sh/ [3] https://fusionauth.io/ [4] https://www.keycloak.org/
Thanks for the mention (I work for FusionAuth).
I'm curious what solution you ended up determining best fit your needs?
I'm curious what solution you ended up determining best fit your needs?
that landing page should point to docs instead of commands for me to run on my machine.
I'm someone looking for auth/security products. you won't reel me in like that.
I'm someone looking for auth/security products. you won't reel me in like that.
Thanks for your feedback! Here are the docs: https://fusionauth.io/docs/v1/tech/
FusionAuth has a dual deployment model. You can either run it locally (or host it yourself) for free, or you can pay us to run it for you. Most devs want to kick tires and run it locally, which is why the downloads page has those commands.
There are features that do require a license, but we have plenty of people running with plenty of MAU on the free version (we call it the 'community' edition).
Sorry if it wasn't clear.
FusionAuth has a dual deployment model. You can either run it locally (or host it yourself) for free, or you can pay us to run it for you. Most devs want to kick tires and run it locally, which is why the downloads page has those commands.
There are features that do require a license, but we have plenty of people running with plenty of MAU on the free version (we call it the 'community' edition).
Sorry if it wasn't clear.
That’s been our experience as well. Auth0 seemed like a great deal and we were happy to have such a sensitive component handled by a dedicated third party, but their sales team aggressively pursues us as soon as we go over some MAU limit and it’s clear that the nickel-and-diming is only going to get worse as we grow. We need to migrate away sooner or later.
Or just use your favorite oauth / oidc library. AuthZero is for people that need SAML or AD integration or some other legacy tech.
That's a great path for many folks. I think building on a framework is far far better than rolling your own.
However, often there comes a time when you have multiple applications that all need a shared user data store. (Note, I work for FusionAuth, so I am, to some extent, talking my book here.)
You then have some choices:
* run everything off of one app (both features and user management) and have other apps oauth/oidc into that app. This means that other apps are now dependent on one main app. Within that app, user data and feature data may get entangled
* hive off the user manangement and login data from the main app to a separate one and have other apps oauth/oidc into that second app. This lets you deploy/manage them separately and still have one user data store. Congrats, you've just invented an auth server! This can be a good option, but that refactoring may be a bit painful, and you're on the hook for maintaining the auth server (dependencies, adding workflows and functionality).
* stand up a separate auth server (or use a SaaS offering) and have apps oauth/oidc into it. In this scenario the auth server vendor is responsible for updates (adding new forms of MFA such as WebAuthn, for example) and your apps get the benefits from it. The issue here is that this is a core part of your app, so any downtime or integration issues due to an upgrade can cause major headaches. (At FusionAuth, we work around this issue with a single tenant model and by allowing you to pin your version.)
It's engineering, so there's no perfect solution. The above are some of the tradeoffs I've seen.
However, often there comes a time when you have multiple applications that all need a shared user data store. (Note, I work for FusionAuth, so I am, to some extent, talking my book here.)
You then have some choices:
* run everything off of one app (both features and user management) and have other apps oauth/oidc into that app. This means that other apps are now dependent on one main app. Within that app, user data and feature data may get entangled
* hive off the user manangement and login data from the main app to a separate one and have other apps oauth/oidc into that second app. This lets you deploy/manage them separately and still have one user data store. Congrats, you've just invented an auth server! This can be a good option, but that refactoring may be a bit painful, and you're on the hook for maintaining the auth server (dependencies, adding workflows and functionality).
* stand up a separate auth server (or use a SaaS offering) and have apps oauth/oidc into it. In this scenario the auth server vendor is responsible for updates (adding new forms of MFA such as WebAuthn, for example) and your apps get the benefits from it. The issue here is that this is a core part of your app, so any downtime or integration issues due to an upgrade can cause major headaches. (At FusionAuth, we work around this issue with a single tenant model and by allowing you to pin your version.)
It's engineering, so there's no perfect solution. The above are some of the tradeoffs I've seen.
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).
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).
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
[1] https://en.wikipedia.org/wiki/Simple_public-key_infrastructu...
[2] https://github.com/WebOfTrustInfo/rwot11-the-hague
[0] https://www.spruceid.dev/quickstart
[1] https://en.wikipedia.org/wiki/Simple_public-key_infrastructu...
[2] https://github.com/WebOfTrustInfo/rwot11-the-hague
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.
But I think it's a good use case for organization issued IDs, tickets, or even things like driver's license.
Agreed! I think this is the start of something that will be big in a decade as adoption goes up.
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.
The government site doesn't have to know anything about you either, other than you requested a beer token.
> 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.
That's the 7th beer token you've requested this week, citizen. For your own good, we've denied your request.
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).
It very much can be.
Gov might require that on each sale, company re-verify identity (just like they demand you check ID on each sale).
That results in a network request to `proof.verificationMethod` on each sale, which contain a URL to the age verification for that one user.
Done. Gov now have records on how many times you bought beer. They might also request that the number/description of items be included on the verification request. but that is not necessary since credit cards are already being replaced with central bank issued payment systems (see india, brazil, etc)
Gov might require that on each sale, company re-verify identity (just like they demand you check ID on each sale).
That results in a network request to `proof.verificationMethod` on each sale, which contain a URL to the age verification for that one user.
Done. Gov now have records on how many times you bought beer. They might also request that the number/description of items be included on the verification request. but that is not necessary since credit cards are already being replaced with central bank issued payment systems (see india, brazil, etc)
No, the system just isn't designed like that, the whole point of VCs is that the system becomes decentralized. To check a credential is valid you absolutely don't need to hit the Government, you need to trust its public key, which you can easily get once (or keep updating using things like DID)... you are arguing about a different system design that just doesn't exist and has no reason to exist.
> the whole point of VCs is that the system becomes decentralized.
You say decentralized, yet that Verifiable Data Registry seems like a central component to checking whether you are you. How is that not able to see that you checked your ID?
You say decentralized, yet that Verifiable Data Registry seems like a central component to checking whether you are you. How is that not able to see that you checked your ID?
That's not a centralized registry. In fact, it's usually a distributed ledger, normally a blockchain but any distributed database of public keys and IDs will do.
Also, the ID in the VC is not something that can easily be used to identify you. It may be in basic implementations, but it shouldn't. The W3C spec recommends using DID[1]... A DID is a random ID, basically, which is stored in the "distributed ledger" where others can find your current keys and other metadata (none of which containing personal data)... you can have as many DIDs as you want, e.g. one for each usage you make of your VCs, making it impossible to track you around... you should look at the W3C spec if you really want to understand how DIDs and VCs are supposed to work, the Auth0 website is a much lighter , pre-digested and somewhat more centralized version of things that make it much easier to get started (Which is a great thing, but hopefully you shouldn't judge VCs from only what they're pushing).
[1] https://www.w3.org/TR/vc-data-model/#dfn-decentralized-ident...
Also, the ID in the VC is not something that can easily be used to identify you. It may be in basic implementations, but it shouldn't. The W3C spec recommends using DID[1]... A DID is a random ID, basically, which is stored in the "distributed ledger" where others can find your current keys and other metadata (none of which containing personal data)... you can have as many DIDs as you want, e.g. one for each usage you make of your VCs, making it impossible to track you around... you should look at the W3C spec if you really want to understand how DIDs and VCs are supposed to work, the Auth0 website is a much lighter , pre-digested and somewhat more centralized version of things that make it much easier to get started (Which is a great thing, but hopefully you shouldn't judge VCs from only what they're pushing).
[1] https://www.w3.org/TR/vc-data-model/#dfn-decentralized-ident...
Its funny you mention this, this -exact- thing happened with one of the delivery companies in australia.
> 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.
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.
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
- 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
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.
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.
I find it interesting that US states and a massive corporation are directly comparable entities (CA, NY, Walmart, MA) in this context.
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.
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.
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.
Not from me :) it’s a relevant point!
This is a little out there, but this thread is old enough at this point. I would say that COVID was something that improved my outlook in the future. Some aspects of the political landscape seem frankly, pretty dark and depressing. As someone who had a unique vantage point on aspects of the pandemic, I have to say that I saw the best of us demonstrated.
I think that ultimately the difficult adjustment from a 1970s economy to the services economy of today has created unrest and dissatisfaction that has and will change the US for years to come.
It is weird that Walmart has the same standing as a state health department. But ultimately, technology and standards like SMART allow us to trust assertions made by Walmart. I personally have issues with that, but it’s reality. Verifiable credentials are imo probably going to be one of the more powerful tools out there for lots of consumer to government or consumer to business use cases.
This is a little out there, but this thread is old enough at this point. I would say that COVID was something that improved my outlook in the future. Some aspects of the political landscape seem frankly, pretty dark and depressing. As someone who had a unique vantage point on aspects of the pandemic, I have to say that I saw the best of us demonstrated.
I think that ultimately the difficult adjustment from a 1970s economy to the services economy of today has created unrest and dissatisfaction that has and will change the US for years to come.
It is weird that Walmart has the same standing as a state health department. But ultimately, technology and standards like SMART allow us to trust assertions made by Walmart. I personally have issues with that, but it’s reality. Verifiable credentials are imo probably going to be one of the more powerful tools out there for lots of consumer to government or consumer to business use cases.
> 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.
Slight correction here - the health record is already in the SMART format, e.g. already a signed JWT enveloping a FHIR vaccination record.
The Health App is turning encoding this into a custom URL scheme and tossing that into a QR code.
The reverse also works - I can scan the QR code and import it as a vaccination record into the health app.
Slight correction here - the health record is already in the SMART format, e.g. already a signed JWT enveloping a FHIR vaccination record.
The Health App is turning encoding this into a custom URL scheme and tossing that into a QR code.
The reverse also works - I can scan the QR code and import it as a vaccination record into the health app.
Massachusetts also now issues SMART cards
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?
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
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.
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.
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.
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.
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 signed by them.
This would save you a trip to the issuer.
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 signed by them.
This would save you a trip to the issuer.
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.
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.
Right - that's the "drinker's permit" concept I'm talking about here: https://news.ycombinator.com/item?id=33430005
> 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.
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.
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:
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?
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?
Who is the "you" in this? The party that knows the truth of your personal data isn't the same party that you want to rely on your personal data.
The idea here is, say, the DMV in your state knows your age. But you don't want to show your driver's license credential which includes your home address and exact birthdate at a bar, because it's not their need-to-know.
So you can ask the DMV to issue you with a "drinker's permit" which only has your photo and ageOver=21. A bar just validates you match your picture and knows you're of legal drinking age.
The idea here is, say, the DMV in your state knows your age. But you don't want to show your driver's license credential which includes your home address and exact birthdate at a bar, because it's not their need-to-know.
So you can ask the DMV to issue you with a "drinker's permit" which only has your photo and ageOver=21. A bar just validates you match your picture and knows you're of legal drinking age.
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.
* 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.
Genuinely interested what calendar you're using where 08 represents September?
Ignoring the specific example given, JavaScript Date objects use zero-based months depending on how you construct or interact with them, so I'm assuming the OP was thinking of a zero-based example and just wrote it out using 08 in the string.
[deleted]
VCs are what a user holds. So generally with age you will be issued a credential that includes your age.
However, VCs have the concept of a 'presentation' which is what you show someone that wishes to verify something about you. The 'just show them the data and the digital signature' approach is one way to do presentations. But depending on the actual digital signature, you can also do presentations based on range proofs. Or general zero knowledge proofs.
So the issuer is not using range-proofs. Its the holder who is presenting his credentials that gets to do range proofs. That does depend on the issuer using specific kinds of signatures though.
However, VCs have the concept of a 'presentation' which is what you show someone that wishes to verify something about you. The 'just show them the data and the digital signature' approach is one way to do presentations. But depending on the actual digital signature, you can also do presentations based on range proofs. Or general zero knowledge proofs.
So the issuer is not using range-proofs. Its the holder who is presenting his credentials that gets to do range proofs. That does depend on the issuer using specific kinds of signatures though.
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.
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.
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.
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.
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
You will have all your email, postal addresses, other PII and (formerly physical) identification documents in a wallet app. Government websites AND private websites will be able to request data from that wallet for login and registration purposes. You will need to approve all requests to your wallet, in the majority of cases by using biometrics (e.g. faceId or non-apple alternatives of it).
This has the potential to eradicate several major avenues of fraud. The more of this is offered (for free) by governments the more it could majorly disrupt (=destroy) the industry around the topic.
Worldwide it seems there is a new, proprietary wallet each month, which naturally totally ruins this idea of having one wallet, but I see what is currently going on as a "storming phase" or almost "norming phase" already, that will eventually reach the "performing phase", with one or two wallets being the survivors. A big stumbling block here is that everyone involved wants a piece of the cake.
The European Union is actively (but slowly) working on this, e.g. with eIDAS. With eIDAS, you create a digital identity in your home country. If that home country DI offering supports eIDAS, you can use it to login to any other government AND private service implementing any DI offering that supports eIDAS.
> whether identity providers / VC providers are going to be 5 big firms
The big firms will provide the ecosystem (e.g. Microsoft Entra, mastercard-id-for-rp, ...), the real identity verification will happen through offerings like Onfido, Jumio and the 1000 other offerings in the space.
This has the potential to eradicate several major avenues of fraud. The more of this is offered (for free) by governments the more it could majorly disrupt (=destroy) the industry around the topic.
Worldwide it seems there is a new, proprietary wallet each month, which naturally totally ruins this idea of having one wallet, but I see what is currently going on as a "storming phase" or almost "norming phase" already, that will eventually reach the "performing phase", with one or two wallets being the survivors. A big stumbling block here is that everyone involved wants a piece of the cake.
The European Union is actively (but slowly) working on this, e.g. with eIDAS. With eIDAS, you create a digital identity in your home country. If that home country DI offering supports eIDAS, you can use it to login to any other government AND private service implementing any DI offering that supports eIDAS.
> whether identity providers / VC providers are going to be 5 big firms
The big firms will provide the ecosystem (e.g. Microsoft Entra, mastercard-id-for-rp, ...), the real identity verification will happen through offerings like Onfido, Jumio and the 1000 other offerings in the space.
Just to clarify something important, though... and I hope you agree with me on that: the VCs that matter will be issued by whoever is the authority that takes care of the subject matter... as it's always been the case in the real world.
For example:
- date of birth: issued by your government and equivalent to your birth certificate.
- Occuppational credentials: issued by the relevant, government-authorized organization, like Engineers Australia or whatever.
- Driver's License: issued by the traffic authority in your country/state.
- Proof of Vaccination: this is interesting, as COVID showed... in my country, it was private organizations issuing that, but they had to be approve by the Government.
The only credentials the big social media companies can issue for you just prove you have a certain handle with them, I guess... which could be used for a more secure "Sign in with Google/Apple/GitHub" for example. But nearly all interesting credentials would be issued by real-world authorities, IMHO.
For example:
- date of birth: issued by your government and equivalent to your birth certificate.
- Occuppational credentials: issued by the relevant, government-authorized organization, like Engineers Australia or whatever.
- Driver's License: issued by the traffic authority in your country/state.
- Proof of Vaccination: this is interesting, as COVID showed... in my country, it was private organizations issuing that, but they had to be approve by the Government.
The only credentials the big social media companies can issue for you just prove you have a certain handle with them, I guess... which could be used for a more secure "Sign in with Google/Apple/GitHub" for example. But nearly all interesting credentials would be issued by real-world authorities, IMHO.
The government issues physical ids and might even issues a digital identity / verified credentials. But there are also private, non-governmental vendors that verify your physical ids and create verified credentials for you. In that case, the private DI vendor is the issuer of the verified credentials. The government might not be involved in anything besides providing the end user with a physical id.
But yes indeed, private companies do not have much valuable credentials to offer. There just aren't that many categories of personal data you'd ever want to have in a wallet.
But yes indeed, private companies do not have much valuable credentials to offer. There just aren't that many categories of personal data you'd ever want to have in a wallet.
> But there are also private, non-governmental vendors that verify your physical ids and create verified credentials for you. In that case, the private DI vendor is the issuer of the verified credentials.
But who's going to trust those vendors? This is the job of the government IMO, one of the few things you just can't rely on the private sector for. I definitely don't want my birth certificate credential tied to, say, Google :D the Government cannot , for example, remove my credentials because I said something polemic, while Google (and infamously Twitter) most definitely can and seem quite happy to do if they can.
But who's going to trust those vendors? This is the job of the government IMO, one of the few things you just can't rely on the private sector for. I definitely don't want my birth certificate credential tied to, say, Google :D the Government cannot , for example, remove my credentials because I said something polemic, while Google (and infamously Twitter) most definitely can and seem quite happy to do if they can.
> But who's going to trust those vendors?
We will find out in the coming years...
We will find out in the coming years...
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.
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.
You might get your physical ids from the government, but private providers will verify them and create a digital-identity for you. Unless the government also wants to play the role of digital identity provider / VC provider.
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...
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...
> 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
That is most likely specific to your country and it's approach to deployment, your politics. Estonia mandated the availability of smartcard/PIV/mTLS authentication and it's now very widespread. Also really easy and free to implement.
> let alone abroad.
That is unwillingness to follow the EU standard from some EU countries and wish to reinvent the wheel (e.g. BankID and similar). I know that eIDAS-compliant PIV/smartcard implementations are cross-compliant e.g. Finland-Estonia-Latvia-Lithuania. But code-stealing Polish implementation for example isn't.
> 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.
Each country were given most of the stack required, they bypassed a lot of bullshit many countries have with software development.
> 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.
When PSD2 required 2FA for banking, we had had it for more than five years at that point. So there is hope some EU legislation smooths these things out at some point, but it's going to be quite late.
That is most likely specific to your country and it's approach to deployment, your politics. Estonia mandated the availability of smartcard/PIV/mTLS authentication and it's now very widespread. Also really easy and free to implement.
> let alone abroad.
That is unwillingness to follow the EU standard from some EU countries and wish to reinvent the wheel (e.g. BankID and similar). I know that eIDAS-compliant PIV/smartcard implementations are cross-compliant e.g. Finland-Estonia-Latvia-Lithuania. But code-stealing Polish implementation for example isn't.
> 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.
Each country were given most of the stack required, they bypassed a lot of bullshit many countries have with software development.
> 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.
When PSD2 required 2FA for banking, we had had it for more than five years at that point. So there is hope some EU legislation smooths these things out at some point, but it's going to be quite late.
The concept of a VC is orthogonal to JWTs. You can use a JWT to embed a VC:
https://www.w3.org/TR/vc-data-model/#json-web-token
The new thing about VC is that it introduces a mechanism for claims (which is what JWTs contain) to be made and presented in an interoperable way (requiring schemas for data, so multiple parties can make sense of claims without knowing each other), something JWTs cannot do by themselves.
Also, OpenID is being extended to support self-issued claims:
https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
VCs integrate with the existing specs, it doesn't compete with them.
https://www.w3.org/TR/vc-data-model/#json-web-token
The new thing about VC is that it introduces a mechanism for claims (which is what JWTs contain) to be made and presented in an interoperable way (requiring schemas for data, so multiple parties can make sense of claims without knowing each other), something JWTs cannot do by themselves.
Also, OpenID is being extended to support self-issued claims:
https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
VCs integrate with the existing specs, it doesn't compete with them.
I'm fine with a new standard if it can provide me something new that other standards doesn't. But does this do that?
Yes, you can get "partial" verification, like someone wants to know your age, and you can prove it without exposing all your other identifying information. With a centralised authority this is a pretty trivial thing. Nice to have it standardized I guess, but I don't see what's so exciting about it.
Yes, you can get "partial" verification, like someone wants to know your age, and you can prove it without exposing all your other identifying information. With a centralised authority this is a pretty trivial thing. Nice to have it standardized I guess, but I don't see what's so exciting about it.
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.
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.
The W3C?
Hah, I was not expecting that one.
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.
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.
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.
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-...
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-...
It appears to be similar to regular public/private key encryption but with a fancy name to make it seem unique.
It seems at least one layer above public/private key encryption.
[deleted]
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/
[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!
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.
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.
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.
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.
> 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...
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.
> 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.
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...
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...
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.
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.
Just to add to your excellent description, one can draw an analogy between the id_token and a VC.
But an id_token usually has an audience which is the RP, and a short expiration. A VC is issued for the user (aka holder), with long or no expiration to store in wallet.
A VC is bound to the user’s did (think pk thumbprint) and is useless without a proper presentation. A verifier does not expect just the VC but a V. Presentation signed by the user.
This is where using id_tokens as vcs will fall short. Once you give it to one verifier, you could assume is public.
The good thing about VCs is that is standard and easy to grasp. There are too many flavors though
But an id_token usually has an audience which is the RP, and a short expiration. A VC is issued for the user (aka holder), with long or no expiration to store in wallet.
A VC is bound to the user’s did (think pk thumbprint) and is useless without a proper presentation. A verifier does not expect just the VC but a V. Presentation signed by the user.
This is where using id_tokens as vcs will fall short. Once you give it to one verifier, you could assume is public.
The good thing about VCs is that is standard and easy to grasp. There are too many flavors though
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?
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?
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
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.
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.
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-..., which selectively offers pieces from that once-signed chunk of data.
This is where SD-jwt comes in - https://datatracker.ietf.org/doc/draft-fett-oauth-selective-..., which selectively offers pieces from that once-signed chunk of data.
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.
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
Note: Auth0 currently doesn't support neither issuing or verifying this type of credentials.
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
Note: Auth0 currently doesn't support neither issuing or verifying this type of credentials.
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.
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.
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/) just returns "Error code: SSL_ERROR_RX_RECORD_TOO_LONG" for me (is it just me?)
It's a nice idea. But their "Try it out!" link (https://manage.auth0lab.com/) just returns "Error code: SSL_ERROR_RX_RECORD_TOO_LONG" 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'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 https://en.wikipedia.org/wiki/Self-sovereign_identity or not.
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.
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?
> 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?
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.
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?
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?
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.
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.
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.
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.
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.
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.
The verifiable presentation is not just the credential; it should be signed by the holder, and that can include a 'domain' to specify the intended recipient and a challenge token to guard against replay.
https://www.w3.org/TR/vc-data-model/#concrete-lifecycle-exam...
It's always contingent on the recipient of an identity proof to verify that it's valid; I'm not sure I understand the criticism to be honest.
https://www.w3.org/TR/vc-data-model/#concrete-lifecycle-exam...
It's always contingent on the recipient of an identity proof to verify that it's valid; I'm not sure I understand the criticism to be honest.
There's also the possibility that cheapboozeforstudents and statestudentaid.gov are colluding - either directly or because of corrupt employees - against the ID holder. We have seen examples where banks issued loans in user's name against fake IDs/applications.
You (client) wouldn't accept a statestudentaid.gov presentation request coming from cheapboozeforstudents.com.
e.g. token binding.
https://www.w3.org/TR/vc-data-model/#token-binding
https://www.w3.org/TR/vc-data-model/#token-binding
Digitally verifiable statements are usually of the form "z attests that x is a y", not "whoever presents this statement is x".
For digital ID, such a statement could be "only person Foo Bar knows the private key that corresponds to this public key, and they use that one for verifying their age, but not for voting or opening new bank accounts".
I do see the UX concern, though: The European digital Covid certificate works in exactly this way ("Foo Bar is fully vaccinated against Covid as of April 1st"), making no claim of the form "the person showing you this QR code is Foo Bar" or "the person presenting this code is vaccinated" – yet this is how it was and is unfortunately still often used.
For digital ID, such a statement could be "only person Foo Bar knows the private key that corresponds to this public key, and they use that one for verifying their age, but not for voting or opening new bank accounts".
I do see the UX concern, though: The European digital Covid certificate works in exactly this way ("Foo Bar is fully vaccinated against Covid as of April 1st"), making no claim of the form "the person showing you this QR code is Foo Bar" or "the person presenting this code is vaccinated" – yet this is how it was and is unfortunately still often used.
VCs are typically used in conjunction with DIDs. Do they say anywhere whether they’re using DIDs and, if so, which methods?
This labs project appears to currently use did:web for the issuer, and did:ethr for the subject.
- 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/ supports did:key, did:ion and did:ethr
Thanks (both) for the info!
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't even registered? oO
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
Judging by the whois it might have been created by someone who saw this post.
And not a blockchain in site.
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
For everyone feeling the kneejerk urge to downvote: https://www.bbc.com/news/world-asia-63456107
Is this another KYC?
I would (and will) avoid anything like this by any cost.
Rests. Survive.
Rests. Survive.
Ugh. The use cases listed. Sounds like a perfect match for the Chinese government.
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.