Hacker News new | ask | show | jobs
by CleverLikeAnOx 1327 days 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).

6 comments

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

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.

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)

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.

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

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.

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.

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.

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

Massachusetts also now issues SMART cards