Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verifiers MUST NOT trust visual indicators on apps they do not control #66

Open
msporny opened this issue May 25, 2022 · 8 comments
Open

Comments

@msporny
Copy link
Member

msporny commented May 25, 2022

From this article:

https://arstechnica.com/information-technology/2022/05/digital-drivers-license-used-by-4m-australians-is-a-snap-to-forge/

There is this misguided notion that I've heard many times now... that the Holder App itself has a visual watermark that let's the verifier visually inspect that the app is a legitimate mDL app. I've heard government representatives from US states as well as some sales people from vendors in the space say this. We all know that digital images that you visually inspect are NOT a trustworthy security feature... even if you use the phone's tilt sensor to turn it into a "digital hologram".

We should state that Verifiers MUST NOT trust visual indicators on apps they do not control and ideally any visual indicator on their app is driven by some sort of cryptographic security process.

@RieksJ
Copy link

RieksJ commented May 31, 2022

For the current situation, I wholeheartedly agree with @msporny.

However, in the near future verifiers SHOULD be enabled to accept (wallet) apps that they do not control. The decisive use-case is provided by the EU, that is actively considering

  • to require its member states to provide their citizens with at least one kind of "EU Digital Identity" (EUDI) wallet, and
  • to require (large) organizations to accept every such wallet (which they obviously do not control), regardless of verification is done by a human or a machine.
    I expect that over time, every of the 27 member states will notify a specific EUDI wallet, perhaps even more, e.g. to provide citizens that have particular needs with wallets that provide for those.

I would not be surprised if (consortia of) organizations would not only request the user to present (identification) credentials, but also to present credentials that pertain to the app/agent that they are actually using (and the verifying actor of the organization is connected/communicating with). Such a credential would be required to contain a certificate that states that the app satisfies the criteria set forth in an 'app security/trust framework', and is issued by a party that is an accredited auditor in that framework. It's a lot of work to get this done, but similar things have been done before. And it would incentivize wallet manufacturers to acquire such certificates as they enable these wallets to be used in the contexts that require them.

Having said that, the issue is out of scope for VCDM.

@chongkan
Copy link

chongkan commented Jun 6, 2022

It is unclear to me when you say "Visual Indicators" and "Digital Images" then Tilt Sensor. Correct me if I am wrong:

1- user is asked to verify FaceID? -- perhaps video and you have to move a bit to confirm in 3d?
2- Present ID Doc. ?
3- Present App Credential ( QR/BARCODE/ ) ?

OR

3- It is connected to international AML/KYC and Anti-Fraud monitoring systems? as external 3rd party validation.

@OR13
Copy link

OR13 commented Feb 7, 2023

Trust me, this is valid credential XD...

demo

@agropper
Copy link

agropper commented Feb 7, 2023 via email

@OR13
Copy link

OR13 commented Feb 7, 2023

@agropper I think this issue is basically, don't trust UI by itself.... the credential above is valid, but unless you are intending to trust that web origin and the entire software supply chain that goes into it... you should not believe the "green checkmark".... similarly, you should not supply "credentials"to websites you don't trust to verify them...

@TallTed
Copy link
Member

TallTed commented Feb 7, 2023

@OR13 — I think you misspelled

<sarcasm>Trust me, this is valid credential XD...</sarcasm>

@agropper
Copy link

agropper commented Feb 7, 2023 via email

@iherman
Copy link
Member

iherman commented Feb 8, 2023

The issue was discussed in a meeting on 2023-02-07

  • no resolutions were taken
View the transcript

2.2. Verifiers MUST NOT trust visual indicators on apps they do not control (issue vc-imp-guide#66)

See github issue vc-imp-guide#66.

Kristina Yasuda: verifier must not trust indicators on apps they do not control.

Manu Sporny: people were being trained to look for visual indicators that the proper app was being used..
… it's fairly easy to throw an app together that looks right..
… we should say - do not look for indicators in the application that the proper app is being used. This should be used in conjunction with other checks..

Juan Caballero: @orie i think you mixed up your [] and () in that demo link.

Manu Sporny: digital signatures really should always be checked..

Kristina Yasuda: what are the visual indicators?.

Manu Sporny: those could be a tilt sensor that produces a hologram. but given enough time and money you can recreate that..
… we want people to think that as long as the biometric is being checked you need to make sure you received that portrait inside of a secured mechanism.
… can't just receive the payload..

Kristina Yasuda: what is the line between vc data model security considerations and this?.

Manu Sporny: this is at the application layer. the data model should support these mechanisms, but this is many layers above..
… physical systems that protect the interaction is what moves it into the implementation guide..

Kristina Yasuda: there is disputes section in the imp-guide btw.. https://www.w3.org/TR/vc-imp-guide/#disputes.

Manu Sporny: it is a but of a gray area..

Kristina Yasuda: would be good to have a security section in the implementation guide.

Manu Sporny: +1.

Phillip Long: +1 security implications in the implementation guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants