-
Notifications
You must be signed in to change notification settings - Fork 6
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
[PROPOSED WORK ITEM] Verifiable Credential Barcodes #248
Comments
I have a real problem with the title of this effort. Not the effort itself, but the title, which gives an entirely false sense of security. Within the world of barcodes and RFID tags (Automatic Identification and Data Capture, AIDC), verification means verifying that the data carrier meets the standard (the PDF417 standard, the QR Code standard, the RFID Gen 2 spec etc.). That means that the bars/modules are the right relative size, there's the correct white space around it and so on. That's not what you mean by "Verifiable Barcodes" (in AIDC terms, all barcodes are verifiable). Barcodes and RFID tags contain simple data. They are neither secure nor insecure. They're as secure as a Post-It Note. The security and the verification of the data, comes in the software that reads and processes the data. A bad actor can create an application that reads a 2D barcode that contains a VC and then present the user with false information. That is, it deliberately ignores or misrepresents the data it has read. It just recognizes that it has scanned something and then it acts in whatever way it wants. Finally, there's nothing in the 2D barcode that confirms that the code is an electronic version of the other info printed on the physical item. That's the world of secure printing, holograms, special inks and all that. Without secure printing, you can have a genuine PDF417 code on a fake driver's license. In the sense of the proposed work item, it's not the barcode that is verifiable. It is simply that a VC is encoded within a 2D barcode and therefore its payload can be verified with the appropriate software. There are good reasons for doing this. But please don't call it a Verifiable Barcode. It's a VC in a barcode. Therefore, I would strongly urge you to rename this to something much closer to "Encoding Verifiable Credentials in 2D Barcodes". |
We are not wed to the name; it's a working title, and will, of course, change it given your concern with the title.
Hmm, I get what you're saying but wonder if there is one detail that's missing. The VC that's embedded in the 2D barcodes (PDF417 or QR Code covering an MRZ), does cover information that is contained on the printed card. For PDF417, the PDF417 fields are secured via the digital signature in the VC. For MRZ, the QR Code covers the entirety of the printed MRZ information. In both cases, the VC embedded in the barcode secures both information in the barcode as well as information that is printed on the physical document. I don't know if that's evident from the proposal?
It goes a bit beyond that title, as described above. Given the further detail I've provided above, would you provide another suggestion for the title of the document? To be clear, given your reaction (and your background), I expect others to have the reaction that you had AND we don't want that, so we do need to rename. Some alternates:
Do any of those resonate? |
Thank you.
That makes sense, yes, but there's an unwritten assumption in what you say that the 2D code is printed as part of the card itself. That's a good security feature and something that a relying party should check. The alternative scenario is someone saying "oh yeah, we're in the middle of upgrading the system which is why we've stuck this updated 2D code on top". In other words, as part of this, it should be explicit that the 2D code must be printed as part of the card and not stuck on afterwards. We have a draft standard, that conforms with an ISO/IEC standard (20248), that defines a flow like:
No such thing - see original post :-)
OK but it's not what you mean. You're not securing the barcode.
That one's good yes.
Sounds like your verifying the barcode. I am probably too close to all this as I live and breathe barcodes (I have colleagues who can read a 1D barcode by eye) so, not keen on this proposed title.
Thank you for taking my comments on board Manu - much appreciated. |
+1 to Verifiable Credential Barcodes, VCBs. |
Sounds interesting let me know if I can be of help editorially or technically (cryptography, test vectors, demo code). Cheers Greg B. |
Ok, let's go with that for now, then. Fixed in: |
Hello everyone, a general reflection of the Threat Model Background: The birth of the MRZ (as well as that of Barcodes) is to have a machine (laser reader or camera) quickly read an identifier or do basic data entry, then to contain an item identifier. So what is the use-case and, if so, what security and privacy issues does it mitigate and what does it introduce? As also is already indicated here https://digitalbazaar.github.io/vc-barcodes/#optical-data-duplication
Or for example my mobile driver's license does yes show a QR-Code from the app, but it changes each time and is single-use as far as I read from the specs (ok for that I think call home that's not good). Simone |
@msporny — re: #248 (comment) Noting for tracking purposes — w3c-ccg/vc-barcodes@cbb9e9c As does https://github.com/digitalbazaar/vc-barcodes/ |
@simoneonofri Good questions. Largely, VCBs mitigate the security issue surrounding an arbitrary person's ability to:
As you mentioned, barcodes can be duplicated - however, a valid barcode is guaranteed to be "authentic" in that it originally came from the issuer. To mitigate the attack where valid barcodes are duplicated, for validation as well as verification a verifier needs to ensure that the data in the barcode for which a digital signature was verified matches the data on the card as well as the person presenting the card. We will be adding more thorough security and privacy analyses to the spec soon, and I agree that we need to be explicit about what the VCB tech addresses and does not address. Does that answer your questions? |
@TallTed wrote:
None of those 404 for me... perhaps Github had a hiccup? |
Whatever the cause, it's ongoing. Maybe permissions on the repo aren't set correctly? |
Hi @wes-smith, Thank you for getting back to me. Surely, it's important to document in the appropriate section the threats (Security and Privacy Considerations) the technology wants to mitigate (if I understand it, it makes it harder to copy the QR Code, but it would be to test with a camera phone for example) and its intrinsical limitations. The main issue is that the human eye does not see whether the barcode is counterfeit, which creates a limitation,, to see if there are any solutions. Offhand I can't think of any. Unfortunately, it's one of the things I've seen done, as well as with COVID-19 Pass, on-watch warranties (normal QR Code, but same method). Simone |
@simoneonofri Thank you for the feedback. Looking forward to continuing this discussion. |
I also get a 404 FYI |
We will discuss this work item proposal next CCG meeting with the aim of accepting it. However, I note that currently all work item owners are from DB. Is anyone else from a different company willing to be a owner of this work? |
Hii @wip-abramson : My team and I from Credence ID would like to volunteer as co-editors of this specification. |
+1 to that choice, Verifiable Credential Barcodes. The issue raised about the barcode not being secure, "Barcodes and RFID tags contain simple data. They are neither secure nor insecure. They're as secure as a Post-It Note." is similar to the original single assertion badge intentionally designed to be public and readable by anyone possessing it. And that's why Kerri, Dmitri and I wrote the proposal to transform it into a VC compatible, and therefore secure, data model ;-) |
Nice and useful application of VC technology, Danube Tech supports this. |
This work items meets the CCG requirements and I see no objections. The CCG adopts this Work Item. Looking forward to seeing this work move forward. |
Repository transfer is now complete: https://github.com/w3c-ccg/vc-barcodes/ |
New Work Item Proposal
Verifiable Credential Barcodes
Include Link to Abstract or Draft
https://digitalbazaar.github.io/vc-barcodes/#abstract
This specification describes a mechanism to protect legacy optical barcodes, such as those found on driver's licenses (PDF417) and travel documents (MRZ), using W3C Verifiable Credentials. The Verifiable Credential representations are compact enough such that they fit in under 150 bytes and can thus be integrated with traditional two-dimensional barcodes that are printed on physical cards using legacy printing processes.
List Owners
Work Item Questions
We are securing the 2D barcodes found on physical documents such as Driver's Licenses, employment authorization documents, and permanent resident cards using W3C Verifiable Credential technology.
Most 2D barcodes found on physical documents today, such as driver's licenses, are not secured using cryptography. This means that anyone can generate a fraudulent barcode using commonly available technology and no mechanism exists to verify the data encoded on most identification documents.
We protect the information in the 2D barcode with a digital signature that can be verified using a commodity smartphone or other broadly available hardware and software. This enables valid documents to be identified far more easily than what is possible today.
We have involved the retail industry, as well as federal and state governments in the work. This includes policy analysis, technical analysis, privacy analysis, and accessibility analysis. We continue to seek engagement in these areas by making this a W3C CCG work item, which has many people, across many industries and countries, involved in the vetting of the work items. We do also plan to take this standards track to ensure further analysis before the technology becomes broadly available to global society.
We are providing websites that individuals can use to try out the technology and provide feedback. We are presenting the work at in-person conferences and teleconferences.
The text was updated successfully, but these errors were encountered: