W3C home > Mailing lists > Public > public-credentials@w3.org > February 2020

QR Codes & DIDs

From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Fri, 14 Feb 2020 12:21:38 -0800
Message-ID: <CACrqygCK-wtQATKRaFMxWo0wWPXJmWoP3k=LPHEbGmbS_v12Bw@mail.gmail.com>
To: W3C DID Working Group <public-did-wg@w3.org>, Credentials Community Group <public-credentials@w3.org>
Cc: Wolf McNally <wolf@wolfmcnally.com>, Ryan Grant <rgrant@rgrant.org>
(To the DID and CCG lists. Please keep the cc: to Wolf if you want him to
reply to any questions)

Blockchain Commons has a goal to be able to DID documents and VCs
leveraging airgap QR Codes, and asked Wolf do to some research for me.

This research came from a comment by Ryan Grant <rgrant@rgrant.org>:

> The reason I ask about side of diddoc is that the brace characters are
not in the qrcode alphanumeric  alphabet. The iphone qrcode will only
reliably read 2953 binary bytes. I think the most interoperabe qrcode
encoding of the diddoc will be base64, which means the limit on an iphone
reader is 2214 bytes.

The result from Wolf McNally <wolf@wolfmcnally.com> is:

> I conclude from these experiments that there is unlikely to be any great
benefit from first transcoding a JSON document to a less dense character
set in order to activate a more dense QR encoding.

I hope you find this helpful.

Some longer-term questions we have are to do with what to do when we do
exceed the limits of a single QR code. For instance, we've considering
proposing something like this wrapper in QR codes that are multipart and
need to be animated. We have seen a business-card-sized device (the SafePal
bitcoin wallet https://safepal.io/ ) with a camera and small screen that
can do animated QR codes, so we know this is feasible on low-powered

    "header": {
        "format": "Airgap",
        "version": 1
    "multiPart": {
    "uid": "449C40FE-E207-4AC9-B552-51B007B68D50",
    "part": 0,
    "count": 1,
    "data": "VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4K"

We have also found that QR code size limits are smaller when using a camera
on a laptop because of lack of closeup focus. Does anyone have any
experience with this?

Any other thoughts, advice, questions on using QR codes with DIDs and VCs?

— Christopher Allen

---------- Forwarded message ---------
From: Wolf McNally <wolf@wolfmcnally.com>
Date: Fri, Feb 14, 2020 at 1:15 AM
Subject: QR Code Density Comparison
To: Christopher Allen <christophera@lifewithalacrity.com>

*QR Code Density Comparison*

This is a comparison of various encodings of a piece of JSON text, with the
goal of determining whether the QR Code generation algorithm in iOS selects
an encoding mode (binary vs. alphanumeric) automatically, and whether it
makes sense to pre-encode the JSON in some other format that will be more
efficiently encoded by the QR Code generator.

All QR encodings in the document use the Low Error Correction option.

Text 1 below is a default DID document. When QR encoded, the resulting
image is 91x91 modules (8,281 modules total)

Text 1 (639 characters):

{ "@context": "https://w3id.org/did/v0.11",
  "id": "did:btcr:xsdv-zrtp-qe4h-vga",
  "publicKey": [ {
      "id": "did:btcr:xsdv-zrtp-qe4h-vga#satoshi",
      "controller": "did:btcr:xsdv-zrtp-qe4h-vga",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "publicKeyBase58": "22zj7sFEsYQXcvLFV55Z4oA6yQZwwKGPa893D8V3EnipS"
    }, {
      "id": "did:btcr:xsdv-zrtp-qe4h-vga#vckey-0",
      "controller": "did:btcr:xsdv-zrtp-qe4h-vga",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "publicKeyBase58": "22zj7sFEsYQXcvLFV55Z4oA6yQZwwKGPa893D8V3EnipS"
  } ],
  "authentication": ["#satoshi"],
  "assertionMethod": ["#vckey-0"] }

Text 1 encoded (91x91 modules):


Text 2 consists of the same number of characters as Text 1, but drawn from
the QR Code alphanumeric set, excluding space. This consists of the 43


Table of Alphanumeric Values - QR Code Tutorial

The result of QR encoding this text is an image that consists of only 75x75
modules = 5,625 modules, which is about 30% smaller than Text 1. From this
we conclude that the QR code generator is auto-detecting whether the input
string can be encoded using the alphanumeric mode and switching to it if

Text 2 (639 random characters in A...Z):


Text 2 encoded (75x75 modules):


To begin to test alternate encodings, we encode Text 1 using Base-64 and
then QR encode that. The result is an image that is 103x103 modules =
10,609 modules, whch is almost 30% *larger* than the encoded form of Text
1. Obviously Base-64 uses characters not in the QR code's alphanumeric set,
so the encoding must take place in binary mode.

Text 3 (Text 1 base 64 encoded, 852 characters):


Text 3 encoded (103x103 modules):


Next we encode Text 1 using Base-32. The resulting QR code is 91x91 modules
= 8,281 modules. This is the same size QR code generated for the original
Text 1, thus in this case we gain no advantage from the extra encoding step.

Text 4 (Text 1 base 32 encoded RFC 4648, 1024 characters):


Text 4 encoded (91x91 modules):


A hypothetical Base43 converter would fully utilize the bandwidth available
in the QR code alphanumeric character set. We can estimate the number of
characters needed for the 639 characters of text 1:

639 characters * 8 bits/character = 5,112 bits
Number of bits encoded in a single QR code alphanumeric encoder:
Solve[2^n == 43, n, Reals] // N
{{n → 5.42626}}
5,112 bits / 5.42626 bits/character = 942 characters

Generating another random 942 characters from the QR code character set to
simulate the output of the hypothetical Base54 converter, we get Text 5. QR
encoding text 5 again gives us a QR code that is 91x91 modules— the same
size as the Base32 encoded Text 4.

Text 5


Text 5 encoded (91x91 modules):

[image: QR Code 5.png]


I conclude from these experiments that there is unlikely to be any great
benefit from first transcoding a JSON document to a less dense character
set in order to activate a more dense QR encoding. The alphanumeric mode of
QR codes is clearly suited to text that can be expressed in its original
form in the particular alphanumeric character set. JSON requires characters
that are not in the QR code alphanumeric set, like the curly braces, and
even its alphabetical components (key names and values) are case sensitive.
If an encoding other than JSON were designed that only used characters from
the QR code alphanumeric set, then it is possible that greater efficiency
could be achieved. But a general scheme would still need to encode
case-preserving strings such as user-entered data, and this data would
still have to be transcoded field by field before the whole data structure
could be QR encoded.

My recommendation is that further attempts to use only the QR code
alphanumeric mode be set aside as premature optimization requiring
considerable work for uncertain gain.


(image/png attachment: QR_Code_1.png)

(image/png attachment: QR_Code_2.png)

(image/png attachment: QR_Code_3.png)

(image/png attachment: QR_Code_4.png)

(image/png attachment: QR_Code_5.png)

Received on Friday, 14 February 2020 20:22:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 14 February 2020 20:22:31 UTC