[PROPOSED WORK ITEM] Verifiable Credential Barcodes

[msporny]

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

• @wes-smith @yashns @msporny @dlongley

Work Item Questions

1. Explain what you are trying to do using no jargon or acronyms.

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.

2. How is it done today, and what are the limits of the current practice?

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.

3. What is new in your approach and why do you think it will be successful?

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.

5. How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: the Americas, APAC, Europe, Middle East.)

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.

6. What actions are you taking to make this work item accessible to a non-technical audience?

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.

[philarcher]

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".

[msporny]

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.

We are not wed to the name; it's a working title, and will, of course, change it given your concern with the title.

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.

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?

Therefore, I would strongly urge you to rename this to something much closer to "Encoding Verifiable Credentials in 2D Barcodes".

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:

• Secure Barcodes
• Securing Barcodes using Verifiable Credentials
• Verifiable Credential Barcodes
• Barcode Credentials

Do any of those resonate?

[philarcher]

We are not wed to the name; it's a working title, and will, of course, change it given your concern with the title.

Thank you.

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.

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?

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:

1. Scan the code - get an initial something. This includes an instruction to look for a printed feature. This might be something printed in UV ink, or some other secure feature.
2. Whatever method is used, get that second identifier.
3. The combination of the original scanned data plus the extra string is what can then be checked against the signature. This provides some surety that the barcode is for the thing it's attached to/part of.

Therefore, I would strongly urge you to rename this to something much closer to "Encoding Verifiable Credentials in 2D Barcodes".

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:

• Secure Barcodes

No such thing - see original post :-)

• Securing Barcodes using Verifiable Credentials

OK but it's not what you mean. You're not securing the barcode.

• Verifiable Credential Barcodes

That one's good yes.

• Barcode Credentials

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.

Do any of those resonate?

Thank you for taking my comments on board Manu - much appreciated.

[dlongley]

+1 to Verifiable Credential Barcodes, VCBs.

[Wind4Greg]

Sounds interesting let me know if I can be of help editorially or technically (cryptography, test vectors, demo code). Cheers Greg B.

[msporny]

Verifiable Credential Barcodes
@philarcher wrote:
That one's good yes.
@dlongley wrote:
+1 to Verifiable Credential Barcodes, VCBs.
+1'd by @aniltj and @Wind4Greg

Ok, let's go with that for now, then. Fixed in:

w3c-ccg/vc-barcodes@cbb9e9c

[simoneonofri]

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

• For example with COVID-Pass often the thing was to show the printed QR Code and the verifier would see if it was valid valid or not (green or red verification application or beep or fart) or this use-case for Fraud with mDL from DHS.
• This I've also seen this with QR Codes in goods and warranty certificates where often the boolean output is evaluated then self-referenced, without having the matching. And a QR Code is as convenient for a machine to read as it is inconvenient for a human to read.
• This makes me think of The Bad Lock Example (pg. 26): is it safer to have a bad lock or not to have a lock? Of course, I'm not saying it's not secure to sign, but that I can take that QR code and paste it on other documents

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

[TallTed]

@msporny — re: #248 (comment)

Noting for tracking purposes —

w3c-ccg/vc-barcodes@cbb9e9c
gets a 404

As does https://github.com/digitalbazaar/vc-barcodes/
which is the repo linked from https://digitalbazaar.github.io/vc-barcodes/

[wes-smith]

@simoneonofri Good questions. Largely, VCBs mitigate the security issue surrounding an arbitrary person's ability to:

• use high-quality printing services to print fraudulent IDs with arbitrary data on them. As you mentioned, a valid barcode can be duplicated onto one of these IDs, but then the data on the card must match the data in the barcode, as verification will display what information was signed.
• use AI tools to generate images of fake credentials (current generative AI tools cannot forge a digital signature)
• use open-source PDF417 (or other barcode) generation tools to generate barcodes with arbitrary data in them that cannot be differentiated from issuer-generated PDF417s by verifiers

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?

[msporny]

@TallTed wrote:

gets a 404

None of those 404 for me... perhaps Github had a hiccup?

[TallTed]

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?

[simoneonofri]

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

[wes-smith]

@simoneonofri
Agreed that the inability for a human to visually detect a fake QR code/PDF417 (and the resulting need for a smartphone camera) is a limitation that we need to explicitly address, but a major motivation of this technology is to move away from that sort of "eye test" validity checking and towards cryptographic verification. AI tools and professional grade printing services are making "eye test" checks less and less useful, and for such checks the existence of the barcode does not impact the usefulness of the existing card security measures.

Thank you for the feedback. Looking forward to continuing this discussion.

[wip-abramson]

@TallTed wrote:

gets a 404

None of those 404 for me... perhaps Github had a hiccup?

I also get a 404 FYI

[wip-abramson]

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?

[yashns]

Hii @wip-abramson : My team and I from Credence ID would like to volunteer as co-editors of this specification.

[longpd]

• Verifiable Credential Barcodes

That one's good yes.

+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 ;-)

[peacekeeper]

Nice and useful application of VC technology, Danube Tech supports this.

[wip-abramson]

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.

[msporny]

Repository transfer is now complete: https://github.com/w3c-ccg/vc-barcodes/