One of the challenges we’ll face as the World re-opens is that, without an effective cure or widely adopted vaccine, we run the risk of infection spikes simply because we have no way to accurately check who is, and who is not, ‘clean’.
Estonia have recently announced an app they are launching, called Back to Work, which attempts to provide a way for users to verify their status regarding vaccination and testing. I’d be thinking about basically the same thing, as I’m sure many people have, over the last month or two, and now there’s something ‘out in the open’, I thought I might as well share what I was thinking.
It’s far from complete – I’d really only got as far as working out the basic flow, and how it could be secure and, as much as possible, anonymous, without losing the usefulness of the data it would produce. A key consideration in my flow is that it could be used to validate anyone, at any point…just not those who had explicitly registered, using a photo…whilst still remaining otherwise anonymous (and making access to that photo temporary and secure, too).
I was calling it ‘Certified’, though it was only a working title. I never even registered the domain name, which probably says a lot about how far I would have continued with it!
Here’s the flow:
The system has three user types, and a centralised server.
Testers – these are official people, who run the tests and effectively pass or fail a User. Where additional information is required, such as a photo, they are responsible for taking that photo and adding it to the User’s profile.
Users – Joe Public. They are the ones who need testing and who need to validate their status when entering buildings. They get assigned a unique ID when they first register the app with the service. Registration can be automatic and anonymous, or require personal details as required by the implementation.
Gatekeepers – These are the people who need to validate the status of a User, for example the security team when a User wants to enter a venue. Fundamentally they are just Users, but the process is different. Any User can be a Gatekeeper if required, or the implementation may dictate a login or even a different app.
There are then two main processes in play – getting tested, and getting validated.
Getting tested
This is highly adaptable depending on the implementation requirements, and in the flow above it simply involves a user being tested and that test result being updated on their profile. The result will either be negative – they do not have the virus, or positive – they DO have the virus. Actions can be taken as required depending on this outcome.
Getting validated
With a user knowing they have a negative result, they will want to continue with their daily lives and access their work place and other public venues. At the entrance to each, a Gatekeeper user will ask that they scan the User’s app, which will generate a unique QR code. When a Gatekeeper scans this code, it will give them temporary and one-time access to the User’s verified status.
If that status is that they are negative, they can access the building.
The optional elements are just that, and could be added to make deeper use of the process, for example in a corporate environment where users are more likely to be OK handing over their personal details, and for use outside of controlled environments, where it may be required to validate the person themselves (using a photo which could only be added at a testing station, by the testing team).
For example, if a test result is returned as POSITIVE, it would be possible not only to inform the User, but also check other User accounts that have been scanned in at a specific location, effectively acting as a contact tracing tool, whilst still retaining the anonymity of the application. These contact-traced Users could then be informed as to a potential problem, optionally have their own statuses updated accordingly, and even book them in for retesting immediately.
For security, all requests require both a unique user ID, which is essentially public for an individual user, and their 2FA code, meaning that any access any party would have to your validation information would be temporary – once the 2FA code has refreshed, they would no longer have access to it, even if they retained your public ID. The 2FA code would be hashed to stop brute force attacks on what are otherwise simple to force 6 digit numerical codes. Each code use would also be one-time, meaning any subsequent rescans, even if immediate, would require a refresh of the QR code.
I’m sure it’s actually full of holes, I never really finished the thinking beyond basic anonymity and security considerations (and even they weren’t complete). I’m putting here it so it can leave my brain, now there’s a similar app in the wild.
