Legacy documentation, 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 Verifiable Credentials Data Model v2.0 specification provides a global standard for expressing credential information, such as those in a driver's license or travel document. The Verifiable Credential Data Integrity 1.0 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 Compact Binary Object Representation for Linked Data v0.7 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 legacy 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 legacy 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 .
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
}
}
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
}
}
The following terms are used to describe concepts in this specification.
- claim
- An assertion made about a subject .
- credential
-
A
set
of
one
or
more
claims
made
by
an
issuer
.
The
claims
in
a
credential
can
be
about
different
subjects
.
Our definition of credential differs from, NIST's definitions of credential .
- data minimization
- The act of limiting the amount of shared data strictly to the minimum necessary to successfully accomplish a task or goal.
- decentralized identifier
-
A
portable
URL-based
identifier,
also
known
as
a
DID
,
associated
with
an
entity
.
These
identifiers
are
most
often
used
in
a
verifiable
credential
and
are
associated
with
subjects
such
that
a
verifiable
credential
itself
can
be
easily
ported
from
one
credential
repository
to
another
without
the
need
to
reissue
the
credential
.
An
example
of
a
DID
is
did:example:123456abcdef. - default graph
- The graph containing all claims that are not explicitly part of a named graph .
- entity
- Anything that can be referenced in statements as an abstract or concrete noun. Entities include but are not limited to people, organizations, physical things, documents, abstract concepts, fictional characters, and arbitrary text. Any entity might perform roles in the ecosystem, if it is capable of doing so. Note that some entities fundamentally cannot take actions, e.g., the string "abc" cannot issue credentials.
- graph
- A set of claims, forming a network of information composed of subjects and their relationship to other subjects or data. Each claim is part of a graph; this is either explicit in the case of named graphs , or implicit for the default graph .
- holder
- A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. A holder is often, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories .
- identity provider
- An identity provider, sometimes abbreviated as IdP , is a system for creating, maintaining, and managing identity information for holders , while providing authentication services to relying party applications within a federation or distributed network. In this case the holder is always the subject . Even if the verifiable credentials are bearer credentials , it is assumed the verifiable credentials remain with the subject , and if they are not, they were stolen by an attacker. This specification does not use this term unless comparing or mapping the concepts in this document to other specifications. This specification decouples the identity provider concept into two distinct concepts: the issuer and the holder .
- issuer
- A role an entity can perform by asserting claims about one or more subjects , creating a verifiable credential from these claims , and transmitting the verifiable credential to a holder .
- named graph
-
A
graph
associated
with
specific
properties,
such
as
verifiableCredential. These properties result in separate graphs that contain all claims defined in the corresponding JSON objects. - credential repository
- A program, such as a storage vault or personal verifiable credential wallet, that stores and protects access to holders' verifiable credentials .
- subject
- A thing about which claims are made.
- verifiable credential
- A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations , which can also be cryptographically verified.
- verifiable data registry
- A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable credentials . Some configurations might require correlatable identifiers for subjects . Some registries, such as ones for UUIDs and public keys, might just act as namespaces for identifiers.
- verifiable presentation
- A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs).
- verification
- The evaluation of whether a verifiable credential or verifiable presentation is an authentic and current statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds. Verification of a credential does not imply evaluation of the truth of claims encoded in the credential.
- verifier
- A role an entity performs by receiving one or more verifiable credentials , optionally inside a verifiable presentation for processing. Other specifications might refer to this concept as a relying party .
- Unicode code point order
-
This
refers
to
determining
the
order
of
two
Unicode
strings
(
AandB), 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 .
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MUST , RECOMMENDED , REQUIRED , and SHOULD in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here.
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 2. Data Model and 3. Algorithms 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.
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.
