> That library is exactly the kind of thing I have been looking for.
Ah, that's great to hear! You can message its author if you have any specific questions regarding it, he's a friendly and very competent fella.
> I'm curious, my UK passport didn't scan correctly with NFC. Do you only support EU docs for NFC validation? I expected the NFC scanning to work with any ICAO 9303 document.
Ah, one day I'll write a post / video / book / series of morbid novels on NFC in eMRTDs...
Long story short: we support NFC worldwide (NFC prompt is disabled for certain documents, e.g. Germany has a peculiar interpretation of ICAO 9303 where they require a type of Active Auth (vs Passive Auth which is what happens when you scan it with our app or with many other apps))).
However.
1. Sometimes the chip simply does not scan correctly. It takes a bit of time, there's a handshake involved, we send in a sort of hash of the MRZ so that the chip can give some (not all) of the NFC Data Groups (if you're familiar with the 9303 - e.g. we don't get (as part of Passive Auth) biometrics info such as your iris info). You have to hold it tight for a while. You have to hold it against the right spot on your mobile device (varies per model as you're likely aware). Chip has to be in good shape (confirmed from personal experience).
2. Countries interpret PKI (incl. the underlying x509 spec)... differently. One good recent example: the DSC (Document Signing Certificate embedded in your chip) has to have the same trust root as the corresponding CRL (cert revocation list where we check if the cert which signed the DSC - the so-called CSCA - has not been revoked). In practice... sometimes they differ. We handle exceptions and keep working on them, but it's a slow process.
So TL;DR sometimes it's just the physical process which gets in the way (and you then get the video pattern upload screen); sometimes we fetch the NFC data but cannot ensure its authenticity (cannot verify chain of signed certs up to a trusted root - UK like other countries has issued a few CSCAs; these are included in ICAO's PKD which we download, verify and then use). And sometimes all of this is well, but we conclude that the revocation status of the parent cert (the CSCA) is unknown.
If revocation information is included in the cert (e.g. through a so-called distribution point - which usually points to a URL (sometimes broken...), sometimes to a file (...), etc.), we have to make revocation checks and conclude that the cert inside the chip (DSC) and the parent cert(s) have not been revoked. Sometimes the latter process fails.
Sometimes the same document model (same country, doc type, same issue year, same physical security features etc.) embeds a different DSC which leads us to discover that some country has again introduced some non-conforming (against x509 spec, to be precise; e.g. in terms of validation path building) cert chain. We learn to handle them, but it's an ongoing process. Some docs for some countries still prove troublesome.
I don't know the particular onboarding attempt at hand, so it could be something from #1 or #2 above, or perhaps something else.
What can I say, it's fun... (I especially love how ICAO 9303 requires explicit unnamed elliptic curves (as the key algorithm for the keypair underneath the NFC's DSC).
If you want to chat more, shoot me an email :)