2D Barcode URL Prefix Proposal

[SZoerner]

2D Barcode: URL Prefix Proposal

The current design of the 2D barcode ensures efficient data transmission, however, remains obscure to the uninformed end-user. Citizens will likely scan their received barcode with their own smartphone, not necessarily using dedicated wallet apps.

Scanning the 2D barcode with the OS camera as of now has no defined way of dealing with the barcode content. This could even result in a data leakage towards the app chosen to display the content.

Proposal

Add a URL prefix of the form https://server/path# in front of the base45-encoded JSON object. The path could be a subpage of the Secretariat's master URL or the national stable URL for bilateral exchange.

Scanning a barcode with a URL prefix always opens the default web browser loading the webpage, without sending content to the server. A web app could then display a user-friendly information page of the barcode content, or even verify the content while ensuring data privacy.

Pros:

• increased transparency/usability of the 2D barcode for the citizen
• avoidance of unintended data leakage

Cons:

• bigger size of the total payload
• additional prefix that dedicated verifying apps would need to strip - analogous to the current HC1 prefix for schema versioning.

[asitplus-pteufl]

While agreeing that showing an information page (e.g. on available apps, or displaying general information about this type of data) could be helpful and would not lead to unintended referrals to mobile search engines (or other apps), we should avoid to display information on the data itself or do anything related to verification. If such a method would be available and let's say accepted by the validators/citizens then it is quite easy for me - as an attacker - to just place "my url" in front of the bar code and fake the original page. It would depend on the reader to see whether the URL is correct/incorrect, which is probably not going to work. So, while I think it is a good point for certain scenarios, I think we should all avoid to provide any functionality (except for infos) on such a page. This would enforce the validators to use their correct validation apps.

[SZoerner]

If such a method would be available and let's say accepted by the validators/citizens then it is quite easy for me - as an attacker - to just place "my url" in front of the bar code and fake the original page. It would depend on the reader to see whether the URL is correct/incorrect, which is probably not going to work.

Wouldn't the URL prefix be part of the signed content? This would prevent modifications after issuance. Consequently, the choice of the specific URL would have to be made by the issuer at certificate creation time.

So, while I think it is a good point for certain scenarios, I think we should all avoid to provide any functionality (except for infos) on such a page.

I agree: less is better. Could be a static page explaining the DGC and the citizens' rights about their data.

This would enforce the validators to use their correct validation apps.

I expect the validators (as personas, e.g. the airport personnel) will get trained to use the dedicated verifier app anyways. The citizens that just got vaccinated and received their DGC printout, however, might have heard about the wallet app, but still think: "Oh, a barcode... why don't I scan it?" without having such a wallet app already installed.

[jschlyter]

Wouldn't the URL prefix be part of the signed content? This would prevent modifications after issuance. Consequently, the choice of the specific URL would have to be made by the issuer at certificate creation time.

No, it would not - the signed content in inside the base45-encoded compressed data.

[asitplus-pteufl]

I expect the validators (as personas, e.g. the airport personnel) will get trained to use the dedicated verifier app anyways. The citizens that just got vaccinated and received their DGC printout, however, might have heard about the wallet app, but still think: "Oh, a barcode... why don't I scan it?" without having such a wallet app already installed.

in the ideal world, yes, but the question remains on how the use cases and scenarios turn out and which implementations etc. will be available. So, not sure if we can definitely rule out such scenarios.

[SZoerner]

No, it would not - the signed content in inside the base45-encoded compressed data.

@jschlyter You are right, thank you for clarifying. That is a shame though :)

in the ideal world, yes, but the question remains on how the use cases and scenarios turn out and which implementations etc. will be available. So, not sure if we can definitely rule out such scenarios.

True.

[thinkberg]

Optimally, the URL prefix (with the fragment encoding) acts as data leakage prevention to citizens accidentally or actively scanning the 2D barcode. The landing page can then be designed in a way to provide some information but not all, but at least showing information, which is good from a usability context.

In this special context, the landing page should not act as a replacement of an official verification application.

[olaf-b]

ISO/EC 20248 address these issues, but also have the uri prefix with possible leakage problem. It went a different path on data description by putting metadata in the signer certificate. This has the benefit of reducing payload and thus make QR size significantly smaller.

[jschlyter]

ISO/EC 20248 address these issues, but also have the uri prefix with possible leakage problem. It went a different path on data description by putting metadata in the signer certificate. This has the benefit of reducing payload and thus make QR size significantly smaller.

We have a requirement that all data must be stored inside the barcode and be verified offline, without any server components involved.

[jschlyter]

One should also note that adding a URL would have leaked data as well, but as part of the request URI. If one encode https://www.example.com/ foo HC1xyzzyfoobar in a QR code and scans the result, HC1xyzzyfoobar will be part for the request towards https://www.example.com/. Why major mobile platforms offers to "search the web" for any scanned QR is beyond my comprehension, but the prefix approach would not solve this.

[olaf-b]

ISO/EC 20248 does exactly this. No online requirement. You anyhow need the certificate to validate. Having metadata in an OID in the signer certificate enables the payload and QR of to be significantly smaller (from ~540 to ~180 chars for this usage).

[thinkberg]

@jschlyter did you include a # in your URL? The important part of the idea is to use https://example.com/path#HC1xyzzyfoobar which keeps the data at least on the scanning device's browser and does not send it to the server. HC1xyzzyfoobar is not sent towards example.com as part of the request. Encoding it like this would exactly solve that problem.

[thinkberg]

See https://www.w3.org/TR/webarch/#media-type-fragid

Interpretation of the fragment identifier is performed solely by the agent that dereferences a URI; the fragment identifier is not passed to other systems during the process of retrieval. This means that some intermediaries in Web architecture (such as proxies) have no interaction with fragment identifiers and that redirection (in HTTP [RFC2616], for example) does not account for fragments.

[jschlyter]

@jschlyter did you include a # in your URL?

No, I did not, but you are correct that the fragment is stripped. I'll discuss this with my co-authors, we have to evaluate if it still possible to URL-based prefixes at this point in the standardisation process.

[thinkberg]

Thank you, nothing more was expected. I discussed this with @SZoerner and also mentioned it to @asitplus-pteufl shortly.

At UBIRCH have been using this in Corona Test certificates for almost a year now. The fragment encoding is different, but the general idea is the same.

[jschlyter]

I've filed a PR to use HC1: as preamble. This does not address the citizen information, but fixes the leakage issue with a single byte as well as allows for (local) URI registrations.

[dirkx]

In the spec now.