I have crossposted this onto the bitcoinj mailing list as I sure they will all be interested.
More technical/ API details please !
That's good, the reference implementation is built on top of bitcoinj.
I've already documented quite a bit of the technical details in another thread on this forum, but I'll explain how it works here in a shorter summary.
There are 2 basic versions of OpenPay, these are EMV (chip & pin or NFC) and magstripe.
EMV is by far the easiest from a technical standpoint, we load a transaction signing applet onto the card along with a a standard bitcoin keypair with the private key encrypted with a strong encryption such as AES. (Card here can also be any NFC device that is EMV compatible such as your cellphone)
The POS terminal queries the card and asks for a list of public keys (bitcoin addresses) that the card can sign for and hands this list off along with the amount of the transaction to the merchant gateway service. The gateway service queries an exchange (assuming the merchant wants local instead of BTC) to convert the transaction amount from local currency to BTC. Next the gateway queries a balance service which returns a list of unspent txouts for the addresses stored on the card. The gateway then assembles the transaction and hands it to the card for signing. The card tells the PIN terminal to prompt for a pin, this PIN is used as an oncard decryption key for the private portion of the key. Assuming the key decrypts properly then the card signs the transaction and sends it back to the pos terminal/gateway. This is now a standard BTC transaction that can be sent off to the network. Since the gateway is the one crafting the transaction there is no need to wait 10 minutes for verification.
If the merchant is configured for clearing in local currency then after the network verifies the transaction then their service provider will execute a BTC sell to convert the BTC into the merchants local currency. This could happen periodically say once a day, or really whatever the merchant and service provider agree to.
That was EMV, it's very straightforward, simple and direct. All we need is to get an IIN for OpenPay from ISO and we can get that service operational in a few weeks.
The more complicated situation is the magstripe scenario.
Magstripe cards suffer from hundreds of different vulnerabilities and yet it's the most popular method of payment (at least in the USA).
We needed to come up with a solution that would be as convienent as magstripe while closing up the gaping security holes.
Also since magstripe is on it's way out eventually, we didn't want to invest in a lot of infrastructure that would be needed to produce magstripes with a custom IIN on them.
To do this we took a step back and analyzed all the known financial attack vectors and engineered a system that we hope is immune to them.
The first thing with magstripe is that ANY card will work, anything with a standard readable track 1 or track 2 data line ought to work. Yes you can enroll your visa or mastercard, but you can also enroll an old gift card, a loyalty card from your favorite gas station, even your drivers license or library card. We call this the "Any Card" method. If it's readable in an MSR, then it will work for you.
When you enroll the card, the card info contained in the track is converted into an enrollmentID. This enrollmentID is an SHA-256 hash of an SHA-256 hash of the number. In addition to the enrollmentID your service will assign you a UUID, we've taken to calling this a userID, but it can be literally anything that uniquely identifies you to your chosen service provider (you can be your own service provider BTW).
The enrollmentID is hashed with the userID and used as a seed to an ecdsa key, the private portion of the key is discarded at this time and the public portion is used to calculate a public bitcoin address.
This way no bitcoin private key is ever stored.
Finally the stock enrollmentID is used to calculate an AES key which is used for encrypting traffic on the messaging system.
Now let's see how this comes together from a POS perspective.
Jimmy swipes his card at the POS terminal and selects OpenPay as a tender type (just like he might select credit or debit).
The card number is passed from the POS terminal to the merchant gateway. The gateway is connected to the OpenPay network which is an XMPP based onion routing network.
The card number is used to generate an enrollmentID and an AES key. A request for payment is generated by the gateway, and encrypted with the newly generated AES key. It is then timestamped (default TTL for messages is 5 minutes) and handed to the messaging service. All the messaging service does is relay any received messages to all contacts in it's contact list.
Eventually Jimmy's service provider (which could just as easily be software running on his phone, as it could be a separate company) pickups up the message via it's messaging service. All incoming messages are routed to the authentication service which tries exactly once to decrypt the message using all the AES key's it's in charge of. If the message decrypts correctly then the authentication service begins authenticating the validity of the request using one or more authentication modules.
Planned authentication modules include SMS, XMPP, hardware key based 2 factor, and static PIN. There is also the possibility of accepting PINless transactions, but that's up to the service provider and the user.
Jimmy was configured for SMS so he receives a message containing a PIN and enters that into the pin pad. The message follows the same path as before and it ends up at Jimmy's service provider.
From here the path is essentially the same as with EMV, a public key is returned, a list of unspent transactions is queried and used to build a BTC transaction (all using different modules running in their own memory space), finally a transaction is constructed and sent to the signing service along with the enrollmentID and the userID. The primary difference being that with "Any Card" the signing service is residing on a server somewhere and not on the physical card. Also the signing service doesn't actually have access to any private keys, unlike EMV where the keys are strored on the card itself. The bitcoin private key is reconstituted on the fly using the enrollmentID and userID and is then used to sign the transaction. The signed transaction is then sent back to the merchant gateway, which hands it off to the merchants service provider for validation.
I know it sounds complex, but the implementation is actually pretty simple. It's more or less a matter of who does what at what stages of the pipeline,
I'll keep everyone informed here as the various modules & services are completed, enjoy!