¶ Physical data carrier
Data carrier options:
- QR-Code
- Basic NFC tag
- Advanced NFC tag
¶ Basic Data Carrier
The simplest solution to provide the end-user with a user-friendly data carrier serving as an entry point to the DPP is to provide a QR-Code or NFC tag.
In both cases, there exist common consumer interfaces that will convert either into a URL and open the appropriate service or application.
It's also possible on most mobile devices to intercept specific URL templates to prevent opening the default browser when a dedicated application is available.
Both solutions can be fitted onto an actual physical object, or embedded into extra physical documentation such as a user guide, some form of "authenticity certificate", or even on the packaging.
¶ Advanced NFC
NFC are presented as an alternative to QR-Code data carriers, in part because they can provide additional features.
The NFC Forum[1] is involved in such future usages.
Using advanced NFC tags that allow a higher level of interaction with a dedicated application (or, in the future, a standardized application) can provide advanced features to the DPP.
A data carrier like a QR-Code can be easily duplicated.
As long as the physical solution is entirely passive and relies on generic tools for parsing (such as a regular phone camera), it's not possible to prevent the duplication of the data carrier.
While solutions exist to create harder-to-duplicate passive physical solutions, they require either specific reading hardware, expensive tags, or both, and are sometimes not compatible with all devices.
These solutions can also degrade over time and become unreadable.
As such, they are not ideal solutions for many use cases, where physical products may have a long life and their authenticity needs to be verified regularly throughout their entire lifecycle.
An option for an advanced NFC tag is the use of digital signatures provided by the tags themselves.
While this solution does require a dedicated application to fully exploit it, it remains compatible with the regular NFC tag behavior of providing a standard URL.
It also allows the tag to be extremely difficult to duplicate as the digital signature it can produce are based on a built-in private key that cannot be extracted from the tag.
This feature alone is enough to prevent the duplication of the tag, as any DPP entries for the tag's physical object would be associated with the correct private key.
With this level of functionality, providing a tamper-proof, non-reproducible tag, and the ability to verify its authenticity, would provide a strong level of security for the DPP.
It can further be used to authenticate ownership of a product, repair operations, end-of-life processing, etc. by linking both the tag's signature and a user's private signature in each DPP entries.
In addition to preventing counterfeit products from being registered as "real" ones, those tags would also actively participate in serving as the physical “twin” of the DPP associated with the product they're on.
¶ Standard availability
The requirement of a dedicated application to take advantage of any advanced NFC features is a major drawback of this solution.
The expected user experience takes this aspect into consideration.
Users who have no knowledge of the dedicated application are handled using the regular URL scheme and webpage without any special action from the user.
Said webpage can then be used to provide the user with the option to install the dedicated application.
Users who already have the dedicated application available are directly redirected to it.
Both paths of execution are seamless as far as the user's experience is concerned.
¶ URI schema
There are multiple options for creating an URI[2] that match a unique DPP.
The best option in this case is to design an URL that will provide both the details of the product and the entry point (matching service) to connect to.
¶ Reminder about URI/URL
First, as a reminder, an URI is composed of these parts:
To design a suitable URL for our use case, we can simplify it by removing the user, port, and limiting the scheme, since these URL are expected to be handled by their lowest common denominator, that is, the end-user device.
We have to consider the potentially limited space of data carriers.
A perfectly legible QR-Code at reasonable distances from the camera can be read by most smartphones, but legibility decreases with an increasing payload.
This problem may also arise with NFC, where the NDEF space can be limited, sometimes as low as 250 bytes.
An additional constraint is that URLs should only contain ASCII characters to improve compatibility, further reducing available space for custom data.
To tackle these issues, we encode any non-ASCII data using either URL encoding or Base64 (using base64url[3]) for binary data.
Including information in a URL can be done through the path, query, or fragment.
Using the path is least flexible, as it requires an additional way to identify path elements, or a hard-coded pattern, but can help encode more data with a smaller fingerprint.
Utilizing the query is standardized for providing named values; however, the names embedded in the URL take more space.
Making use of the fragment is less standardized but offers the interesting side effect of not being sent to servers when loaded in a browser.
This option provides a way to embed data that would be usable client-side (in the browser or dedicated application), but not propagated to the server.
¶ KeeeX's Proposal
KeeeX's approach to DPP identification utilizes a 32-byte identifier (referred to as an IDX), which is embedded in the data carrier.
This reserves at least 43 bytes for the identifier (encoded in base64url[3:1]).
Since we adhere to regular URL patterns, this identifier can be placed either within the path or the query.
There is no technical difference between the first two options; however, any data placed as a fragment will be invisible from the server and thus cannot be utilized by the matching service.
A sample URL utilizing KeeeX technology could be as short as this:
https://dpp.keeex.it/M4SFJQcjKVonQ5208nFccu_Z5mocooBUs5FWplQ9jMw
That is 64 ASCII characters.
It would work well in both a QR-Code and a reasonable contrained NFC tag, and can communicate the minimum information needed for identifying the associated DPP.
¶ Compatibility with GS1
The GS1 Digital Link[4] provides a standard for putting various product information in a URL.
It is mostly focused on industry requirements, such as product numbers, serial numbers, and so on.
The general structure of a GS1 Digital Link is as follows:
- The scheme ("http" or "https", usually)
- The server address, which exposes a suitable service to answer the GS1 request
- The path is roughly a sequence of two elements: a "key" identifier and its value.
In the case of the DPP, identifying a product by its product number and serial number would be acceptable; so an URL as follows could also be used:
https://dpp.keeex.it/01/12345678901234/21/ABCDE12345ABCDE12345/414/9876543210987
This URL indicates an item whose GTIN is 12345678901234, with the SER ABCDE12345ABCDE12345, and a GLN code of 9876543210987.
While it contains extra data, the GTIN and the SER are usually enough to identify a single item.
As such, the matching service can match these data with an associated DPP, while other services that require GS1 compatibility can still handle the URL.
Note that the above URL is 80 characters long.
Although GS1 URLs can have more fields, they remain regular URLs, and it's possible to add extra data in the fragment part without breaking compatibility.
This would allow a KeeeX-aware dedicated application to retrieve more information from the URL.
For example, mixing this GS1 URL with the above KeeeX-only URL would result in the following URL:
https://dpp.keeex.it/01/12345678901234/21/ABCDE12345ABCDE12345/414/9876543210987#idx=M4SFJQcjKVonQ5208nFccu_Z5mocooBUs5FWplQ9jMw
That's still only 128 characters, leaving room for additional data, even in the most constrained of data carriers.