License to --

Walther H Diechmann -

Danes will be getting a new drivers license - at some time in the future, as Netcompany has just won a tender for building and managing just that: a drivers license system. Which made me contemplate how such a system would actually be designed.

[ I will use "he" when in fact acknowledging the non-masculine, non-binary he/she/it/they
– but for simplicity restraining from using all, some, intermittently. ]

Abstraction

A legal body [ a driver, case in question ] will a some point in time be required to document a certain set of attested competencies (his ability to command a vehicle).
This requirement presents 2 problems.

Authentication & authorization

Solving both, the driver could (always) travel with the attester or he could 'facetime' the attester when required to document and hand the phone to the requesting body. This would redirect the authorization (and authentication) to the attester, and not further the case!

Digital sovereignty

Under EU 2016/679 any system to control and/or process personal data is required to be designed for privacy - with the legislative intent being sovereignty as a matter of fact.

Some licenses are more sensitive than others. A license to operate (read 00- like in 007) within the borders of another country will be rather sensitive. A drivers license lesser so but still quite sensitive depending upon the driver's demonstrated abilities - ie if he manages to compile a long list of "likes" the license will possibly be quite sensitive at least in other situations: applying for a job as a chauffeur eg.

Autonomy

So far I am pretty sure you have considered legal bodies to be biological ones only! An extremely edge case as of writing, I concede, would be one in which an autonomous vehicle (AV) gets "pulled over" by another AV.

The example most likely will be reality – albeit in an unforeseeable future, but suffice to say a requirement for automaticity is obvious.

Design

Authentication

The legal body (autonomous entities no doubt will become legal bodies, eventually) should present something he knows, something he has, and something he is – and at least 2 of the 3 artifacts should be 'on record'.

  1. the "knows" part could be a pin code, one that makes sense to the body in question, like a date, height, or other set of digits,
  2. the "has" thing could be a public/private key – when asked to encrypt a given word the result can be diff'ed and hence validated,
  3. finally the "is" issue could be biometric (robots could offer their MAC address of sorts),
  4. and adding a one-time-password SMS/Text sent on request would further increase confidence in the authenticity of the legal body

Why not use MitID (current authentication solution currently deployed by danish public offices and private enterprises alike)? One word: automation
The sketched solution can be automated and kept on one device, and integrated with other apps.

Frontend
Users could download an app with the authentication process being the main feature (or the authentication process could be integrated into other apps like fx a driver's license app). The pin-code will open the app (and send a request for the one-time-password) and allow the user to process the encryption of a data package provided by the requesting body (to accomplish item 2), further allowing the user to present either fingerprint or face to camera (accomplish item 3), and finally once the SMS arrives, the user will have a QR code to present to either a robot or another legal body to scan.

Backend
Each user will have his own event journal/witnessed ledger and safe keep his data 'on device'. Public systems will keep whatever data points they require in a similar construct. The essentiel (core) table will hold the user's pigeon, public key and the phone number to forward one-time-passwords to (the system should have a semi-self-service system allowing users to switch phone number when necessary), and possibly autonomous system's MAC address. Initial authentication could/should be required to perform at municipal or notary offices.

In countries that keep a uniq ID on each citizen (in Denmark it is labeled CPR) any attempts to keeping this ID with the authentication core table should be avoided at all costs as this ID probably is spread across a huge number of systems and thus will be violating the user privacy severely!

At initial authentication at a municipal office, presenting the officer with the ID would be acceptable but persisting the ID with the authentication not!

Authorization

Demonstrating attested competencies is easily added to this 'app' as a "plugin" and adding a plugin for a driver license is no different.

Frontend
Any user of a smartphone could download a "driver license reader" and should be able to read the token of a driver license, and to submit a "traffic incident ticket" with his personal (and geo location) information attached, possibly some attachments like audio/video too.

Any further reading/writing below will follow this (happy path) workflow:

  1. requesting body will submit a request attaching the (pigeon) token - WD1CKM4NN
  2. the user with the token receives a notification requesting his accept
  3. the user accepts the action/request
  4. the requesting body receives the information

In some use cases (like if the user does not accept the action/request) the requesting body will have to elevate the request to a police office, and if not solved with the police as requester, elevate the request to the legal system - and eventually the user will lose his license.

Insurance companies should be able to read attested competencies as well as registered "likes" when submitting a token. They should be able to write insurance information.

Attesters should be able to read token and address information, and write competencies attested, and his token.

Police offices should be able to read and write all information.

Judicial offices should be able to read and write all information.

Backend
The core table holds the license number and the token attached to it, and the competencies attested, when and where attestation was given, and a token of the attester. A supporting (like) table holds the token of the user and a token of the body offering the "like", when it was inserted and any consequences, possibly a time range for deactivation of the license, more. A further supporting table holds the token of the user, a vehicle ID, a token of the insurance company, and the time range where the insurance is valid, and insurance specifics.

Infrastructure and budget

What amount of infrastructure are we looking at?
Building on Erlang/Elixir for a 'telecommunications kind of app' (I am aware that the initial use cases does not prescribe any tele communications per se, but a number of use cases down the road may prove it to be a fitting decision) will allow for upwards of 2mio connections per server, which when considering the danish scope, would ask for 3-4 servers – if all danish citizens were to be 'online' at the same time.

What budget will that ask for?
Building out the infrastructure in 2-3 small clusters located in the north, the south, and the east, with a primary and a secondary/fallback server will set the budget to a mere 3-400.000/yr on hosting and maintenance.

Using Phoenix with Erlang/Elixir will afford a single source stack building backend and frontend in one project with extremely high availability and modest requirements on deployment. The client application could easily be deployed as a progressive web application.

Developing/building the 2 applications (authentication & authorization) and the driver license plugin could be a 2-3man task for 6-12months and see costs top at 3.000.000DKK, and probably in the 250-400.000/yr for continues development.