<div><div dir="auto">(in reply to this thread: </div><a href="http://mailman.cs.huji.ac.il/pipermail/linux-il/2017-March/012522.html" target="_blank">http://mailman.cs.huji.ac.il/pipermail/linux-il/2017-March/012522.html</a> )<br><div class="gmail_quote"><div><div dir="auto"><br></div><div dir="auto">The reason a physical hardware reader (either an Android phone with NFC or a USB card reader) is necessary is that Rav Kav is based on the Calypso standard, and the card is a full microprocessor smart card that carries all the relevant information (passenger information, contracts, etc.) onboard the card itself. All transactions (loading/validating) are performed offline, with communication between the ticketing device and the card. This is as opposed to some other systems around the world, in which the card simply carries a static identifier and the ticketing system is based on a database that can be checked in real time. Here in Israel, while there is a database, it's not used online - instead it's updated at some later point with data downloaded from the buses etc. For this reason, for example, if a card is lost or stolen, there's a three day waiting period before the balances can be restored to the card. This is because the ticketing devices on buses are not all equipped for full reliable online connectivity (and in some cases, any connectivity), and because it's one unified, national card that needs to work with the different systems used by the different companies, it's not feasible to upgrade all the systems the way single, unified transport authorities in e.g. London can.</div></div><div dir="auto"><br></div><div dir="auto">In terms of the website and the program itself, I did a bit of analysis a few weeks ago. It uses the system PC/SC APIs, using the javax.smartcardio library. The code has a list of regexes that it checks, with the different models of reader that they've distributed/sold since launching the website, and doesn't use any reader that doesn't match. I don't know why they do that, but I can confirm that there's no technical reason for it - I happened to have a different reader on hand (some Athena model that I received with my Teudat Zehut), and when I edited the regex to match it it just worked.</div><div dir="auto"><br></div><div dir="auto">I don't know if it's possible for websites to interact with the PC/SC stack - I'm guessing not - so the way it works is that the browser side opens a Websocket connection to a server, IIRC wss://<a href="http://proxy.ravkavonline.co.il/" target="_blank">proxy.ravkavonline.co.il/</a><random UUID here>, and triggers a navigation to the same URL prefixed with the ravkav: scheme. This launches the client, which establishes a Websocket connection to the same URL, with the proxy server simply passing any messages along to the other side of the connection. This connection is used to send commands from the webapp to the client, and responses, reader status, etc. from the client back to the webapp. To perform any action with the card, a command is sent saying essentially "open a session with the card at this URL". The client connects to the URL and exchanges JSON messages that appear to carry base64-encoded raw APDUs and responses, which are relayed as-is between the card and the server (in the case of a simple "read card" operation, a fixed URL at <a href="http://datamodel.ravkavonline.co.il" target="_blank">datamodel.ravkavonline.co.il</a>. In the case of operations that need to modify the card contents, such as loading a contract onto the card, once the transaction is approved, the server-side generates a URL at some other server, presumably one that's connected to a SAM so it can sign the session with the card). At the end of the session with the card communication server, the server returns the result (for example, in the case of a simple dump of the card contents, a JSON document listing the contracts and history), which is then passed through the proxy server to the webapp.</div></div></div>