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.

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.

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.