Open smarek opened 2 years ago
I guess stripping spaces is a good idea, but I'm more skeptical about the other change. I don't think what you write about other barcodes is true, there's an open issue about someone with an NL1 cert and it decodes to something that isn't base45 at all. Can you point me to example certs for these different prefixes that would be decodable with this change?
Yes, I assumed that the EU certificates concept gets adopted nationally, and certificates might be issued with local jurisdiction and localized prefix, which has to follow the 2D Code Versioning outlined in specs, but I assumed that all national certificates will follow the data structure outlined in EU specs.
This is indeed mistake, see these https://github.com/minvws/base45-go/issues/1#issuecomment-875354543 https://github.com/StefH/Dutch-CoronaCheck-QR-Code-Decoder-and-Verifier#overview
So i'll leave that up to you, it won't solve the NL2 incompatibility (and we can specifically point out if the version is not HC1, that the data might not get decoded at all), but if HC2 will be (and i don't see why it should't be) compatible with HC1 (ie. base45 of zlib of CBOR document), then it could be long-term efficient solution
Per specs https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_v3_en.pdf
This might result in trying to parse unsupported data (newer version of certificate) but the basics (b45+zlib) won't ever imho change, cbor will only contain different document
This should fix at least #15