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

Specify that VCs that are not signed are not VCs #64

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

Specify that VCs that are not signed are not VCs #64

msporny opened this issue May 25, 2022 · 2 comments

Comments

@msporny
Copy link
Member

msporny commented May 25, 2022

Based on this security compromise:

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

One of the issues in the compromise described by the article above is that there are no digital signatures on any of the data transmitted by the mobile driver's license app. Verifiable Credentials would've prevented this first error because VCs have to be digitally signed to be trusted. At least, we hope that's what people out there are doing. The takeaway for us is to clearly outline this in the implementation guide -- it's not a VC if it's not signed by an issuer, there is no security if it is not signed.

It's important for us to provide guidance to implementers that VCs that are not signed are not VCs and are not safe to use for any critical task. An unsigned VC is effectively self-asserted information.

@peacekeeper
Copy link

I thought that was clear from the definition of "credential" and "verifiable credential" as well as the first paragraph in the "Credentials" section in the specification.

But I agree it can't hurt to also elaborate on that a bit in the implementation guide.

@msporny
Copy link
Member Author

msporny commented May 26, 2022

I thought that was clear from the definition of "credential" and "verifiable credential" as well as the first paragraph in the "Credentials" section in the specification.

Yes, agreed that it's clear in the spec... but that presumes that the first place people will look might be the spec. I am also on the fence about putting this in the implementation guide... because we're supposed to not repeat ourselves (as a best practice).

But I agree it can't hurt to also elaborate on that a bit in the implementation guide.

Perhaps the part in the implementation guide can be a checklist -- "Did you implement VCs correctly -- go down this list -- did you sign your VC? If you are transmitting via QR Code, is the QR Code digitally signed, or some part of the exchange digitally signed in a secure protocol? You are not depending on "digital holograms" or other visual watermarks, are you -- 'cause that's not a thing with digital information? The verifier is actually verifying the digital signature, right? If you have a long-lived credential, you really should have a way of revoking it."... and so on.

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

2 participants