Hacker News Reader

Comment by jameshart | Hacker News Reader

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?

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.

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.

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.

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

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.

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.

Reply on news.ycombinator.com