Closed darrikonn closed 1 week ago
Hi @darrikonn
I thought I knew everything about kennitölur by now so this is a surprise. What type of nationalId are foreigners getting? Do you know how they differ from native nationalIds?
One of the problems with this package has been finding a definitive answer to a lot of questions about nationalIds.
This sounds like a nice break for a major release/refactor then since I want the package to be all inclusive.
Lets keep the issue open, I created a kanban board for the refactor with a short wishlist for the refactor. I have been wanting to do slight API changes that I haven't been able to without a major bump.
PS: meanwhile you could npm-patch
and modify the package locally in your project until an official release is available. I've had good experience doing this while waiting on official changes from packages.
https://www.skra.is/folk/eg-i-thjodskra/um-kennitolur/um-kerfiskennitolur/
Seems that the new standard for kerfiskennitölur will be taken up on the 1st of November this year. So approximately 4 months for the refactor and beta testing the new package. Would be good to finish within two months and have a month for beta testing.
What type of nationalId are foreigners getting? Do you know how they differ from native nationalIds?
Yeah, foreign nationalIds are invalid nationalIds. I don't know the exact structure of them.
Looked at this a bit, the new system will be a 10 digit number like before, starting with either 8 or 9 means it's a temporary id, the rest of the number are random and not checksummed, and you need a network request to an API to get further info.
I'm wondering if it makes sense to include some optional network logic in the package now provided the user supplies an API key?
Yeah, that'd be cool!
@darrikonn check out yarn add kennitala@2.0.0-beta.0
. I believe @eirikurn already has a pull request on island-is with the v2 beta but that solves for foreign id's and a few other new stricter validation features.
Available in V2.0.2 now non-beta.
Foreigners get an "invalid" nationalId once registered, which this library will mark as invalid.
It might be better to validate the nationalId, but specify the origin as foreign. So
isPerson(<foreign_national_id>)
would returnand
isPerson(<native_national_id>)
would returnWhat's your thought on this?
(This would require a major release bump)