Possibilities for verification

Aim of this document

List the design choices that need to be made in order to provide verification of waardepapieren.

Aspects to consider:

Human security (i.e. matching the key to an organization)
Cryptographic security
Distributional security
Self-sovereignty
Ease of use

The primary aim of the solution should be that in the end, a validator is confident that the waardepapier has been issued by an organization which they trust to correctly do so.

Choice: Delivery of validation application

Aspect	Website	App
Human	:heavy_check_mark:	:heavy_check_mark:
Crypto	:heavy_check_mark:	:heavy_check_mark:
Distribution	:white_check_mark: Dependent on CAs to be secure	:heavy_check_mark:
Self-sovereign	:grey_question: Dependent on website host	:heavy_check_mark:
Ease of use	:white_check_mark: Requires computer with webcam to scan code	:white_check_mark: Requires installing application on smartphone
Development	:heavy_check_mark:	:grey_question: Developing with Expo should be doable, but does rise issues with native integration of crypto code

In the case of website, there are two flavours: Providing components and requesting issuers to integrate it in their website or providing a central Discipl-run website.

Choice: PKI vs specific infrastructure

The key problem is matching an organization to a public key that matches them, in a way that sufficiently inspires confidence to the validator. This problem is traditionally solved using Public Key Infrastructure. The alternative is to use a system specific to waardepapieren.

Aspect	PKI	Specific infrastructure
Human	:heavy_check_mark: This is currently how people trust digital presences of organizations	:grey_question: Waardepapieren would need enough uptake for whatever process we would introduce to be familiar
Crypto	:heavy_check_mark:	:white_check_mark: Fine, if properly designed
Distribution	:heavy_check_mark: Distribution can easily be verified by validating the certificate chain	:white_check_mark: Fine, if properly designed
Self-sovereign	:white_check_mark: Dependent on CAs	:white_check_mark: Likely dependent on DNS
Ease of use	:grey_question: Actually obtaining the certificate could pose issues. Embedding it in the claims would inflate the size of QR codes generated	:white_check_mark: Could be tailor-made to keep QR-size down

Choice: Current PKI or NLX PKI

When relying on PKI, this could either use existing certificates, or specifically the certificates issued in NLX. In the case that the NLX root is considered a valid certificate under roots included by default in browsers/operating systems, there are no fundamental differences between these options, and it doesn't impact the delivery of the waardepapieren solution.

Choice: Certificate delivery system

Option	Pros	Cons
Embedding the certificate in the claim	Truly self-sovereign, easy to implement.	QR code size will grow a lot
Embedding the certificate in a second QR code	Truly self-sovereign, easy to implement.	Two QR codes
Embedding minimal data to reconstruct certificate in the claim	Truly self-sovereign	QR code grow a decent amount, could be tricky to implement
Identify certs with fingerprint, provide certificate import in validation app, provide url to certificate on rendered document, human-readable	Small QR size	Cannot be validated if certificate cannot be obtained
Identify certs with fingerprint, provide certificate import in validation app, include url to obtain certificate in QR code	Small QR size (slightly bigger than above)	Cannot be validated if certificate cannot be obtained
Identify certs with fingerprint, host certificates on decentralized platform	Small QR size	Depends on stability and availability of said platform
Identify certs with fingerprint, host certificates on centralized platform	Small QR size	Depends on stability and availability of said platform, not really self-sovereign

Instead of identifying with a fingerprint, we can also identify with the public key. This yields a slightly bigger QR code, with the benefit of allow cryptographic validation even if the certificate cannot be found. We still cannot verify which organization issued it if the certificate cannot be found.

bkaptijn commented 5 years ago

Note that finally expo v33 will contain unimodule that would add a cryptographically secure random generator without having to resort to eject the expo project because of dependency to native code. It is very likely to be released in May 2019.

Note that Commission Decision 2011/130/EU (https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32011D0130) indicates the certificate should be included ("The ds:KeyInfo element MUST include the signer’s X.509 v3 digital certificate (i.e. its value and not only a reference to it).") ... of course a user can obtain the certificate and generate a document compliant with this themselves when given apropiate tools, though not in the case the user does not have means to do so. The aforementioned directive does allow for alternatives though when thinking of offline cross border validation of X.509 signed proofs, it is preferrable to make sure holders also get to hold the certificates that are not the commonly distributed (country) root certificates.

I propose at first we work towards the situation a validator/wallet smartphone app already contains or downloads (NLX) root certificates (we still expect to fall under pkioverheid) and automatically retrieves NLX certificates of specific municipalities from their sources (implicitly) referenced from the main QR. The app should allow for distributing these certificates to other instances of the app in case there's no internet temporarily available (this otherwise is going to be an issue in certain cases). For people without smartphones, this means they should get a second A4 sheet with a (quite big) QR holding the certificate which can be scanned by aforementioned app in a similar way. It should mention that it should be kept together with the signed data sheet though that it is probably only needed in rare cases when asked for. Also holders and validators should be able to print out these documents themselves too from the app though then probably without the municipality branding. They should be aware of the information contained in these documents. People could omit the certificate bundling when the proof validness is only needed for a short time I guess though.

For this to work: the ephemeral connector should allow for distributing the X.509 certificates that were used for signing when given a DID that links to a X.509 certificate referring to a public key fingerprint. In the end this is where DID resolvers can come into play. Alternatively, users should be able to get the NLX certificate from the municipalities website (for the App in the form of a QR that holds a link to the certificate). So the DID of the issuer in this case contains the X.509 public key fingerprint and the link the signature which keeps the QR small. The paper wallet and wallet app retrieves certificates (signed by root certificates that are bundled in the apps (though should be checked for validity)) and stores/exports them separately. When validating a proof, the app will find out to what root certificate the proof can be validated to and can show info on the whole certificate chain. It will show a green checkmark if the whole chain (to any official root certificate installed and validated at a certain time deemed recent enough) can be validated.

Am i missing something?

bkaptijn commented 5 years ago

Decision is :

Identify certs with fingerprint, provide certificate import in validation app, provide url to certificate on rendered document, human-readable | Small QR size | Cannot be validated if certificate cannot be obtained

discipl / waardepapieren

As Product Owner I want an overview of solution avenues for verification... #54