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. -
- -Introductory Examples
- --The following sections provide a few introductory examples of the ways this -specification can be used to enhance existing physical credentials with -digital signatures via [=verifiable credentials=]. -
- -Driver's License
- --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
- --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
- }
-}
-
-
- Birth Certificate
- --This section provides an example on how the technology in this specification can -be utilized to secure a birth certificate as a [=verifiable credential=], which -is then expressed as a QR Code on the printed paper document: -
- -
- -The QR Code encodes the following [=verifiable credential=]. The details of -the encoding are available as separate tabs below: -
- -
-{
- "@context": [
- "https://www.w3.org/ns/credentials/v2",
- "https://w3id.org/vital-records/v1rc1"
- ],
- "type": [
- "VerifiableCredential",
- "BirthCertificateCredential"
- ],
- "issuer": "https://hospital.example/issuer",
- "validFrom": "2023-09-30T11:30:00Z",
- "credentialSubject": {
- "type": "BirthCertificate",
- "certificationDate": "2023-09-30T13:44:52Z",
- "newborn": {
- "type": "Newborn",
- "name": "Tim Doe",
- "gender": "Male",
- "birthDate": "2023-10-05T14:29:00Z",
- "birthPlace": {
- "type": "PostalAddress",
- "streetAddress": "123 Hospital Rd",
- "addressLocality": "Utopia Town",
- "addressRegion": "Utopolis",
- "postalCode": "12345",
- "addressCountry": "Utopia"
- },
- "parent": [{
- "type": "Mother",
- "name": "Jane Doe",
- "namePriorToMarriage": "Jane Smith"
- }, {
- "type": "Father",
- "name": "John Doe"
- }]
- }
- }
-}
-
-
- Design Goals
--The following are the design goals of the technology in this specification: -
--
-
- -Authenticity: a Verifiable Credential Barcode that successfully verifies is -guaranteed to have originated from the claimed issuing authority. - -
- -Integrity: data on a document with a Verifiable Credential Barcode that -successfully 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. - -
Terminology
- --Terminology used throughout this document is defined in the -Terminology section of the -[[[VC-DATA-MODEL-2.0]]] specification as well as the [[[VC-DATA-INTEGRITY]]] -specification. -
- --
-
- 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. -
-
- 
- 
- 
- 
- 
-