Introduction
Physical credentials, such as driver's licenses, passports, and travel credentials often include machine-readable data that can be used to quickly read the information from the document. This information is encoded in formats such as PDF417 [[ISO15438-2015]], machine-readable zone (MRZ) [[ICAO9303-3]], and other optically scannable codes that are formatted in one-dimensional or two-dimensional "bars"; thus the term "barcode". This information is often not protected from tampering and the readily available barcode generation and scanning libraries mean that it is fairly trivial for anyone to generate these barcodes.
It is, therefore, useful for an issuer of these barcodes to protect the information contained within the barcode as well as the entity that generated the barcode.
The [[[VC-DATA-MODEL-2.0]]] specification provides a global standard for expressing credential information, such as those in a driver's license or travel document. The [[[VC-DATA-INTEGRITY]]] specification provides a global standard for securing credential information. These two specifications, when combined, provide a means of protecting credentials from tampering, expressing authorship of the credential, and providing the current status of a credential in a privacy-protecting manner. These data formats, however, tend to be too large to express in an optical barcode.
The [[[CBOR-LD]]] specification provides a means of compressing secured verifiable credentials to the point at which it becomes feasible to express the information as an optical barcode, or embedded within an optical barcode.
This specification describes a mechanism to protect optical barcodes, such as those found on driver's licenses (PDF417) and travel documents (MRZ), by using a verifiable credential [[VC-DATA-MODEL-2.0]] to express information about the barcode, which is then secured using Data Integrity [[VC-DATA-INTEGRITY]], and then compressed using CBOR-LD [[CBOR-LD]]. The resulting verifiable credential representations are compact enough such that they fit in under 140 bytes and can thus be integrated with traditional two-dimensional barcodes that are printed on physical cards using standard printing processes. This adds tamper resistance to the barcode while optionally enhancing the barcode to provide information related to whether or not the physical document has been revoked or suspended by the issuer.
Driver's License Example
This section provides an example on how the technology in this specification can be utilized to secure the optical barcode on a driver's license that uses a PDF417 barcode. We start off with an example driver's license:
The back of the driver's license contains a PDF417 barcode:
The PDF417 data contains information that is secured using the algorithms described in this specification. Namely, the PDF417 barcode contains a verifiable credential of the following form.
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/vdl/v2",
"https://w3id.org/vdl/utopia/v1"
],
"type": [
"VerifiableCredential",
"OpticalBarcodeCredential"
],
// the issuer value below is defined as a URL in the 'utopia/v1' context above
"issuer": "did:web:dmv.utopia.example",
"credentialStatus": {
"type": "TerseBitstringStatusListEntry",
"terseStatusListBaseUrl": "https://dmv.utopia.gov/statuses/12345/status-lists"
"terseStatusListIndex": 123567890
},
"credentialSubject": {
"type": "AamvaDriversLicenseScannableInformation",
"protectedComponentIndex": "uP_BA"
},
"proof": {
"type": "DataIntegrity",
"cryptosuite": "ecdsa-xi-2023",
// the public key below is defined as a URL in the 'utopia/v1' context above
"verificationMethod": "did:web:dmv.utopia.example#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "z4peo48uwK2EF4Fta8P...HzQMDYJ34r9gL"
}
}
The verifiable credential above is then compressed using [[CBOR-LD]] to the following output (in CBOR Diagnostic Notation):
1281{
1 => [ 32768, 32769, 32770], // @context
155 => [ 116, 164 ], // type
192 => 174, // issuer
186 => { 154 => 166, 206 => 178, 208 => 1234567890 }, // credentialStatus
188 => { 154 => 172, 180 => h'753FF040 }, // credentialSubject
194 => { // proof
154 => 108, // type
214 => 4, // cryptosuite
224 => 230 // verificationMethod
228 => 176, // proofPurpose
210 => Uint8Array(65) [ ... ], // proofValue
}
}
Employment Authorization Example
This section provides an example on how the technology in this specification can be utilized to secure the machine-readable zone on an employment authorization document that uses a machine-readable zone (MRZ) on the back of the card. We start off with an example employment authorization document:
The back of the employment authorization document contains a machine-readable zone (MRZ) containing information designed to be read through optical character recognition:
The MRZ data contains information that is secured using the algorithms described in this specification. Namely, the QR Code on the front of the card contains a verifiable credential of the following form, which secures the information on the back of the card.
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/citizenship/v2",
"https://w3id.org/citizenship/utopia/v1"
],
"type": [
"VerifiableCredential",
"OpticalBarcodeCredential"
],
// the value below is defined as a URL in the 'utopia/v1' context above
"issuer": "did:web:immigration.utopia.example",
"credentialSubject": {
"type": "MachineReadableZone",
},
"proof": {
"type": "DataIntegrity",
"cryptosuite": "ecdsa-xi-2023",
// the value below is defined as a URL in the 'utopia/v1' context above
"verificationMethod": "did:web:immigration.utopia.example#key-4"
"proofPurpose": "assertionMethod",
"proofValue": "z4peo48uwK2EF4Fta8P...HzQMDYJ34r9gL"
}
}
Readers might note that the credential above does not contain the optional `credentialStatus` property. Not every optical barcode credential issuer will have the requirement to have revocable optical barcode credentials.
The verifiable credential above is then compressed using [[CBOR-LD]] to the following output (in CBOR Diagnostic Notation):
{
1 => [ 32768, 32769, 32770], // @context
155 => [ 116, 176 ], // type
208 => 194, // issuer
204 => { 154 => 192 }, // credentialSubject
210 => { // proof
154 => 108, // type
226 => 4, // cryptosuite
236 => 242 // verificationMethod
240 => 196, // proofPurpose
210 => Uint8Array(65) [ ... ], // proofValue
}
}
Terminology
Terms defined by cited specifications
- Unicode code point order
- This refers to determining the order of two Unicode strings (`A` and `B`), using Unicode Codepoint Collation, as defined in [[XPATH-FUNCTIONS]], which defines a total ordering of strings comparing code points. Note that for UTF-8 encoded strings, comparing the byte sequences gives the same result as code point order.
A conforming document is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Sections and of this document MUST be enforced.
A conforming processor is any algorithm realized as software and/or hardware that generates or consumes a conforming document. Conforming processors MUST produce errors when non-conforming documents are consumed.
This document contains examples of JSON and JSON-LD data. Some of these examples are invalid JSON, as they include features such as inline comments (`//`) explaining certain portions and ellipses (`...`) indicating the omission of information that is irrelevant to the example. Such parts need to be removed if implementers want to treat the examples as valid JSON or JSON-LD.
Design Goals
The following are the design goals of the technology in this specification:
- Authenticity: a Verifiable Credential Barcode that succesfully verifies is guaranteed to have originated from the claimed issuing authority.
- Integrity: data on a document with a Verifiable Credential Barcode that succesfully verifies is guaranteed to not have been modified as long as that data is secured by the barcode.
- Real-time Status: verification of a Verifiable Credential Barcode proves that the document has not been revoked or suspended, and this is done without a privacy-invasive "phone home" to a source-of-truth database.
- Simplicity: Verifiable Credential Barcodes reuse existing optical barcodes on documents (e.g. PDF417s on the back of AAMVA compliant Driver's Licenses) or add a new barcode in an easily consumable form (e.g. a QR code).
- Conformance: the Verifiable Credential Barcodes technology stack is aligned with global standards and standards-track technologies.
