search

status-im / status-keycard

Our Javacard Implementation for making secure transactions within Status and Ethereum
Apache License 2.0
215 stars 65 forks source link

Can our API and hardwallet applet be compliant with EMV standard ? #22

Closed guylouis closed 5 years ago

guylouis commented 5 years ago

Credit and debit card follow the EMV standard, which is an old standard with a lot of legacy stuff. Still all POS and banking cards are compliant with it.

Can we have our API compatible with EMV standard to facilitate adoption of our cryptocards ?

bitgamma commented 5 years ago

@guylouis at a first analysis of the EMV specs, I would say that it is theoretically possible. However, this wouldn't win us automatic compatibility with any existing technology and the API would be much more complex than what we have now, making it harder to integrate in new systems (unless we keep both APIs, but documentation would still grow and make it harder for developers).

The reason why we wouldn't get automatic compatibility:

1) All EMV compatible applet have payment-method specific extensions which must be implemented in the terminal 2) There is no "EMV Applet" AID which we can adopt because of point 1, every applet has its own AID and terminals have a fixed list of supported AIDs 3) Terminals will need to connect to the Ethereum network to submit the transaction and wait for confirmation. Alternatively some sort of gateways must be set in place (hello single point of failure) to abstract that away, but I do not know if there is an EMV standard online endpoint. 4) The base concept of banking cards and POS is that there is an Issuer who controls your funds and the card is an authorization mechanism. The hardwallet is not a banking card, it is the entire bank from this point of view. We can make it fit, but it will require some effort both card side and terminal side.

All in all, I feel like we would bring a lot of legacy concepts which would bloat the applet without a tangible compatibility advantage. Before undertaking this task I would at least try to contact an EMV terminal manufacturer interested in crypto and see what they think about that.

guylouis commented 5 years ago

Very interesting thanks!

so (for the record) since technically speaking it seems possible, the question is now to see if it makes sense from an ecosystem point of view to implement such a compliance (or a partial level of compliance) with EMV/Book3.

This is something we can investigate with POS manufacturer, especially those who are looking into developing POS w/crypto capabilities, and other existing actors of the payment channel world. As discussed: does it make sense from them to have some compliance, or having another API (still compatible with EMV Book1 for electrical and ISO7816 point of view of course) is even simpler and more straight forward.

Any opinions welcomed :) !

mechanikalk commented 5 years ago

My thought here is that we should be able to fit all needed functions within the EMV standard. I do not think that we need a singular AID as part of the standard but rather a singular AIP. This AIP could be thought of as the blockchain AIP rather than Visa, Mastercard. Then when POS manufacturers want to support blockchain cards in the future, it is like adding a new schema or interchange like visa or mastercard. Any of the cards that conform to the AIP although they might have different AID will work. Here is the pertinent link to the EMV book 3 standard for discussions.

https://www.emvco.com/wp-content/uploads/2017/05/EMV_v4.3_Book_3_Application_Specification_20120607062110791.pdf

Also, it is within the gridplus roadmap to make a POS version of the Lattice which will accept Visa/Mastercard/Blockchain.