3 ms·
Onboard users remotely, or verify a user's real identity, by letting them tap their passport to their phone. Kind of like tapping a card to pay
by vertical-ally 6y ago
Onboard users remotely, or verify a user's real identity, by letting them tap their passport to their phone. Kind of like tapping a card to pay
- geoah 6y agoThis looks interesting but I’m struggling to understand why the user’s data are being sent and retrieved from the server. I would understand it when the request was initiated from a web browser and the user needs to continue the flow on their phone but from what I understand this only works on mobile apps. So why doesn’t the library simply return the information and why are my users’ information sent to a third party server? The dpa states that no data are being stored, so I’m not sure I understand how the flow actually works. What does the developer exchange in return for the user’s info? The docs mention a client token. Is that a jwt or something that contains the users info? If so why does the dev need to send it to the server to unmarshall it? If not, it means that the library has sent the user’s data to the server and they are being stored between requests right? I’m most likely missing something though. Ps. The download links also don’t seem to work (404).
- vertical-ally 6y agoA device can be tampered with, that's why a backend verification is always needed. There may be use-cases where such security is not needed, but I think that's a separate discussion. The developer exchanges the token for the data. In the current implementation the token contains the user data (encrypted). You can reach me directly at robert@passportreader.app to discuss more Edit: links fixed