Topic: [Pre-Announce] OpenPay, use your bitcoins at any merchant that takes Visa! (Read 6511 times)

I cannot wait until this becomes live and I can pay for gas with my Bitcoin card.

I know nothing about the credit card system but will gladly contribute my java programming skills, at the very least to help with bug testing.

For now we should just run with the OpenPay name, if there is an issue later we can cross that bridge when we get there.
In the meantime I've opened up a skeleton project on github for the software stack and will be committing the modules as they are completed.

I will also be posting the url of servers running each module so that they can be properly tested.
Once the reference implementation is operational I would like to see as many different attacks against the system as possible so that we can harden it before we go live.

There will be live bitcoins in the test system, all of them mine, they will belong to whomever can successfully execute any attack and post the method of the attack they used.
Enjoy!

I do think that giving the user the idea that this payment method is more secure, reliable and easy would help sell it.

Some thesaurus terms for secure:
assured, at ease, balanced, carefree, cinch, conclusive, confident, determined, easy, established, firm, hopeful, in the bag, locked on, nailed down, on ice, reassured, reliable, resolute, sanguine, self-assured, self-confident, settled, shoo-in, solid, sound, stable, steadfast, steady, strong, sure, sure thing, tried and true, unanxious, undoubtful, well-founded

reliable:
   candid, careful, certain, conscientious, constant, decent, decisive, definite, dependable, determined, devoted, faithful, firm, good, high-principled, honest, honorable, impeccable, incorrupt, loyal, okay, positive, predictable, proved, reputable, respectable, responsible, righteous, safe, sincere, solid, sound, stable, staunch, steadfast, steady, sterling, strong, sure, there, tried, tried-and-true, true, true-blue, true-hearted, trusty, unequivocal, unfailing, unimpeachable, upright, veracious

easy:
child's play, cinch*, clean, easy as pie, effortless, elementary, facile, incomplex, intelligible, light, lucid, manageable, mild, no problem, no sweat, not difficult, picnic, piece of cake, plain, quiet, self-explanatory, simple as ABC, smooth, snap*, straightforward, transparent, uncomplicated, uninvolved, unmistakable, untroublesome, walkover

I'm not particularly good at this but...
Secure-Pay
Safe-Pay
Padlock

I'll edit this if I think of more.

Not a bad idea, but I've been doing some research.  I think a name without the word pay and that can be trade marked might be a better idea.

Since OpenPay is intended to be a network like Visa, MasterCard, Discover, AMEX, it should have a unique name that doesn't nessecarily have anything to do with pay or payments.  I'm content for the term OpenPay to refer to the protocol, Open Payments Alliance to refer to any group that helps develop or steer it.  However a unique name, short, simple, memorable etc should be chosen for the network & tender type.

Thoughts?

Perhaps call it "Secure Open Pay"?

secureopenpay.com

I'm now working on the reference implementation of the OpenPay software stack.
This software stack will be a complete package of modular components called "services" that all run independently of one another.

The reference implementation will be completely written in Java, although there is absolutely no reason that other languages couldn't be used to re-implement any of the services or components.

I cannot stress this enough, the overall design is extremely secure, but presents the potential for a single point of failure if the implementation does not provide redundancy via multiple instances on separate machines.  (This is true of any distributed computing system).

An ideal professional implementation should be have a minimum of 2 instances of each service, running in geographically distinct areas.

The whole design is intended to provide military grade security and be all but impossible to knock offline. 
Thus the compromise of any single service (however unlikely) will not yield anything of value to a hacker. 
Complete compromise of the entire system could potentially be a problem and for that reason, each piece is broken out as an isolated & low value service with hardened security.

This was done so that all but the most inept IDS could detect a break in attempt before anything of value is compromised.

Beyond the security concerns, Denial of Service just "for the lulz", might cause grief any time there is only 1 instance of any of the individual services running.


Most of what follows here is necessary only for the Magstripe implementation.  However when the EMV, Chip & PIN solution rolls, magstripe may remain as a necessary fall back in the event the chip on the card becomes damaged or the merchant is not equipped for anything but magstripe.

In addition to Magstripe & Chip & PIN modes, there will also be an ultra light weight version of each service to enable full OpenPay usage on a smart phone, such as Android.

We will call this "phone mode" services.

This will allow customers who do not have the resources to host a full OpenPay service stack and who also do not wish to join a participating financial service to still participate fully in the OpenPay network.

We are also exploring NFC options outside of EMV cards.
Now for the design doc.  Understand that this is rough draft, spelling and grammatical mistakes are a real possibility.

The OpenPay stack will be comprised of a collection of low value, hard to crack programs running as a cluster of related services.

Services List -

Signing Service
Authentication Service
   2 factor auth module
   Static PIN module
   Non-PIN module
   Dynamic PIN module

Messaging Service
Balance Service
Enrollment Service
Currency Exchange Service (Cannot be documented at this time but a basic implementation will be provided upon request)
Merchant Gateway Service

Basic Workflow -

Payment Request Messages come in from the Messaging Service (Which straddles the bitcoin network and the openpay messaging network).

Authentication determines if the payment request is for us, by looking at the enrollmentID for a match.
If the enrollmentID is a match, then authentication will query the balance service to determine if sufficient funds are available to complete the transaction. 

If there is insufficient BTC, but the Exchange Service is enabled and configured, then the Exchange Service will attempt to perform a market transaction to acquire sufficient bitcoins to complete the transaction.

Once the service determines sufficient BTC funds are available, then the transaction engine is notified to begin constructing a "BTC spend" transaction. 

Once this transaction returns, then the authentication service sends the transaction, the enrollmentID half of the key and key hash to the signing service.

The signing service signs the transaction and returns it to the authentication service which passes it to the messaging service puts it on the bitcoin network and sends a copy of the signed transaction to the merchant.

(Ideally the merchant's gateway should then verify the transaction using the normal methods of validation)

Transaction Pathway from Merchant - (Happy Path)
Note: This may change in the future once an IIN for OpenPay is created and we move to EMV

1 Transaction is sent to tender via the normal process.
2 The PIN pad will light up with the "OpenPay" option among the list of other MOPs (MOP = Method of Payment), such as credit, debit, ebt etc.
3 OpenPay is selected on the payment terminal by the customer.
3.5 (Optional) - Customer may elect to see the transaction in BTC or local currency

4 The terminal registers a normal cardswipe event.
5 The cardswipe event and transaction amount are routed to the OpenPay enabled MGS
6 The MGS converts the local currency transaction amount to BTC if this was not already done elsewhere such as by an Exchange Connection Service.
7 MGS calculates an enrollmentID and then hands the enrollmentID & amount to the messaging service.
8 The messaging service encrypts the transaction request message and prepends a messageID 
9 Messaging service then passes the encrypted request to the OpenPay P2P network as described in "Messaging Service"
10 Authentication service identifies that the transaction request is intended for it by attempting to decrypt the message, by using the enrollmentID as decryption key. (This only happens if there is only 1 message ID, after the initial exchange it only tracks message ID.)
11 Authentication queries the Balance service to determine if there are sufficient BTC funds.
12 Assuming there was sufficient BTC (or if an Exchange Service was enabled, a market order for BTC buy, executed correctly), Authentication will tell the transaction service to build the transaction.
13 Concurrent to the transaction being built, (assuming some form of secondary auth is enabled) a PIN request message is sent back to the PIN pad via the P2P network and the MGS sets the PIN acquire mode on the PIN Pad.
14 Concurrent to the PIN request message, and depending on the configured module(s) a PIN is either retrieved from the data store or generated and sent to the customer via the enabled modules.
15 The transaction service completes generating the Bitcoin transaction and hands it back to the authentication module.
16 The user enters a valid pin as instructed and this PIN propegates back to the authentication service.
17 Authentication validates the PIN via the relevant authentication module.
18 Assuming the PIN validated correctly, the Authentication service now hands the transaction to the signing service.
19 The signing service signs the transaction and hands it back over to authentication.
20 Authentication passes it back to the MGS via the messaging service.
21 The MGS (optionally, but a good idea), validates the entire transaction and then passes it to the Bitcoin network while sending a transaction complete message to the POS & payment terminal (pin pad).


Merchant Gateway Service (MGS) -
This is a "merchant only" piece of software and the expectation is that this will be the most widely modified & distributed piece of the stack because each merchant will want their own ruleset.  Additionally it is very likely that existing merchant gateway providers will simply incorporate the protocol into their existing products.


Signing Service -
The keys are to be stored and managed by a signing service.  The keys used will be standard ecdsa private/public pairs, but the private key stored on the wallet service is only one half of the key.  The other half is your enrollment ID (a hash generated from the card you registered).  The service itself will not have any idea of any mappings between enrollmentIDs and private half keys.  Instead when the keypair is generated a registration message (hash,hash) is passed up the line to the authentication service.  A complete compromise of the signing service would not do an attacker any good.  There is no money to steal because the keys contained are by themselves invalid, they need the other half of the key to run.  The signing service will be tiny enough to fit on an EMV compliant smart card and could find ample room on even the tiniest of modern devices.

The sole purpose of the service is to accept an input of enrollmentID, private key hash & pre-filled bitcoin transaction.  It's sole output will be a bitcoin transaction signed as per request or an error.  The preparation of the transaction is handled by the transaction preparation service, which is linked to the authentication service.


Authentication Service -
The authentication service is middleware.  It sits directly between the messaging service and the authentication service.
It's primary purpose is to manage communication between the messaging service(s) and the signing service(s).
It will manage the mapping of the enrollmentID to a hash of the signing services private key.  It should be obvious, but this service should never be run on the same physical box as the signing service, even if it's in a different VM.  The boxes should also have completely unique SSH keys.  To prevent a potential denial of service issue, communication between the two services should be via a VPN or other secured and authenticated channel. Preferably this would occur on a randomly assigned periodically changing port.  Port knocking to initiate communication is also a real possibility here.  Authentication is designed to be pluggable to meet the business needs of the entity or person utilizing it.  These plugins are called modules.  They primarily relate to various forms of additional authentication required.
The modules included and enabled by default in the reference stack will be...
   2 factor auth module  (google authenicator, gemalto key fob etc.)
   Static PIN module (Most currently deployed method of ensuring cardholder is present)
   Non-PIN module (Make the card work in swipe only mode, no pin required (insecure)
   Dynamic PIN module (Send a one time use pin via a back channel such as XMPP, SMS or telephone call)

The interaction path for the authentication service is a bit more complex than the others because it serves as a nexus of sorts.  It will not be spelled out here because the individual interactions are identified as each of the other services are called out.


Transaction Service -
The next service is the transaction preparation service.  Once a transaction request has been received it will check the balance via the balance service.  It will then take the output of the balance service and build (but not sign) the actual transaction.
This transaction is then handed to the authentication service which will have the signing service sign the transaction if authentication completed successfully.

Balance Service -
At this point the balance service merits some discussion.  It takes as it's input a public key and returns a list of unspent TxOuts from previous transactions.  Because it needs up to date information, it is quite likely that the balance service will be run as part of a mining pool.  However an exchange may wish to run it as part of their existing infrastructure.  The reference implementation for this will be based on the mining pool concept, but other possibilities would be trivial to implement.


Messaging Service -
The final part of the puzzle is the messaging service.
The OpenPay peer to peer network will utilize XMPP as the transport layer.
OpenPay P2P application layer messages are formated as JSON.

In addition to an SSL connection between the merchant gateway and his/her XMPP gateway, each message will also be encrypted. 
The encryption used will vary depending on the message type.
Every message on the network will have a timestamp, as well as one or two Globally Unique Identifiers (GUID) and an encrypted message body.
OpenPay transaction messaging by default will use Onion routing.  However DCC is a configurable option as well.

Onion routing is the process of passing a message along without any knowledge of it's source, it's destination or it's contents.  This provides very strong anonymity which is one of the goals of OpenPay.  TOR uses this same methodology and it has proven to be a very good method of ensuring strong anonymity.

Nevertheless XMPP (and thus OpenPay) provides a DCC like mode of operation.  In DCC mode, two clients directly connect to eachother to communicate instead of simply passing unknown messages from unknown sources to unknowable destinations.  The advantage of DCC mode is that speed will be greatly increased, the disadvantage is that it breaks the strong anonymity aspect of onion routing.  The choice of modes will be up to the individual or company who is running the messaging service.  The protocol will support both seamlessly.


When a card swipe occurs the Merchants MGS will create a message with 1 GUID a timestamp and a message body (containing the transaction request).
If DCC mode is enabled then the merchant gateway JID will be added to the message body as well.  Otherwise this step is skipped.

The message body is then encrypted using symetric key encryption.
The key to the encrypted portion will be the enrollmentID plus the timestamp.

This message will be handed to the immediate peers of the Merchant Gateway which will hand it to their peers and so forth.
The message passing will continue even if the message is intended for the recipient machine.  This is a security measure intended to prevent a snoop attack that could happen by identification of any particular message service with any particular transaction.
A message will be relayed ONLY if it's less than 5 minutes old and it's ID has not been seen in the last 30 minutes, this is intended to prevent the network from being overwhelmed with messages.

Each peer upon receiving a message containing only 1 message id, will attempt to decrypt it using the enrollmentIDs that it is in charge of.
If decryption was successful, an AES 256 bit key is generated at random and is used for the life of this transaction. 
A message is then created saying that the enrollment ID has been found.

Now at this point there are two possibilities.  If the messaging service is running in peer-discovery or DCC mode then the JID of the messaging service is added to the body of the reply.  If it's not running in discovery mode then that step is skipped, this is the only difference.


In the next step the newly generated shared key is appended to the message.

The message body is then encrypted using the enrollment ID plus timestamp.
2 message IDs and a timestamp are prepended, to the encrypted message body.
The IDs are the original message ID called a replyfor ID, and a second message ID called a replyto ID.

The purpose of the replyfor and replyto ID are for message tracking purposes. 
The messaging service will not try the decryption step on a message containing 2 message IDs (unless it's looking for a specific message reply) since it indicates relay mode only and would be a colossal waste of resources.

The newly crafted reply is then sent along to the merchant gateway using either DCC or Onion broadcast.
 
When the merchant gateway sent the message it began a countdown timer of 1 minute.
If it takes more than 60 seconds to receive a reply it will resend one last time and present alt tender options to the customer after the second minute has expired.
If it receives the intial reply message within a minute then it restarts the timer and updates the payment terminal with a "found" message.

If or when the reply is PIN_REQUIRED, then the merchant gateway will set the pin terminal into PIN_ACQUIRED mode and wait for customer PIN entry.  Once a PIN has been entered a new message is crafted containing the enrollmentID hashed with the PIN and the replyFor/replyTo fields filled out.  The message body is then encrypted using the previously received key and sent back along the network for further processing.

The messaging service will receive the message, decrypt it, compare the hashed enrollmentID with what it was expecting (via authentication service).
Authentication then send the transaction for signing (assuming it was a match)
Or sends a PIN_MISMATCH message back to the gateway (if the values don't match)

Once the transaction has been signed it is sent to the bitcoin network for processing and sent back up to the merchant via messaging (with the same encryption in place as before), for the merchant to independently confirm the transaction and pass it off to their bitcoin processor.

 
That's the documentation I have so far folks.  There are some proprietary bits I'm trying to work out such as the Merchant Gateway Service and the Exchange Connector.  But other than that this is the complete high level design for the OpenPay system.  Let me know what you think.

Oh cool. I haven't messed with Java, but I have played with Node.js(Javascript) and I prefer GitHub, and maybe a Node.js implementation would be good, I prefer Node.js to Java. So maybe I or a few other people could attempt to port it to Node.js? Mostly the logic and ideas can be put in to other languages. Then post it on GitHub also. I'm not the best programmer, but want to help. Seems like a good early project to get involved with.

Also, we can use TestNet to test with a POS system, and servers. Just create fake items to buy/test. then once it works, switch over to the real network. For us without POS hardware, and can't really afford them. We should have a emulator. I might be able to build one with Node.js. A little node app someone runs, and opens up localhost on some port, then enters in some info like production, test net, and can enter in card numbers to test with, the item, price. Something really simple, just for testing. then basically the POS would run some similar software, written in like C or something guess, that uses similar code to connect to the network once it sees that it's an OpenPay card. I guess we really need a really good detail spec, before we write any code, in any languages.

Then I guess some of the early contributors can form a organization and have a board, to self regulate the project, and new ideas, etc. I guess Bitcoin is like this. You have Bitcoin itself, and the non profit "governing" it.

I'm nearly done with the initial design document for the OpenPay reference software stack.
I'll post it here for comment within the next 24 hrs.
In the meantime, the word OpenPay appears to be a registered servicemark of HP. 
I don't think it's in use, nor has it really ever been.

Nevertheless I count HP among my clients, therefore it may put me and even potentially the whole project in significant legal peril if issues arise (no compete, all IP belongs to them etc). 

Let me be clear about this though, HP had nothing to do with OpenPay as we have been discussing it here.  In fact the division I was allied with at HP was printers specifically and I've had no particular contact with anyone outside that division.  It's a coincidence of naming and nothing else.

To prevent any possibility of legal encumberance, I'm willing to consider other names and probably we ought to put it to a vote.  For the record my significant other mentioned that Que Peso might be a good alternative   Nevertheless I'm open to suggestions.

You are quite correct, an IIN would be necessary in the long run especially once we go Chip & PIN.
The best way to help is to help. We're in the processing of ramping up and anyone that wants to lend their skills is definitely needed.  
We currently have documents that I used to present the basic ideas behind OpenPay.  I got partial buyin and then I received permission to take the whole thing open. I'm in the process of converting those docs into a standard format and ripping client proprietary info out of to turn them into standards docs.  I'm also working on some baseline marketing docs, but marketing isn't my strong point.  
What we really need for this process are editors (also translators would be nice since all the docs are in english), and a logo would be lovely to have as well.

I'm also personally writing a complete software stack, it's a reference implementation and will be in Java.
Once it's code complete we could use some willing folks to give it a try and provide feedback.  Good coders could help look for security vulnerabilities and bugs and develop patches to fix anything that might be found.  The entire project will be open, probably hosted on github or sourceforge.

The best way everyone can help is to encourage every merchant they know to start taking OpenPay.  Get to know it's strengths and weaknesses and sing it's praises whereever we can.  The more merchants adopt or commit to adopting as a valid method of payment the faster the momentum will build.  If you happen to be a merchant feel free to start talking to your customers about OpenPay and the advantages it will provide. (Transparency, anonymity, security, no fees, no overdrafts etc).

A final way to help is to make a donation to the address in my sig.  That wallet is a completely offline wallet being used to fund the development of open pay.  This includes laying down the basic infrastructure to make it work as well as funds to pay for marketing.  Merchants probably won't take it if they don't know about it.  This is not a donation beg, we do have $10k USD in exploratory funding on hand, more will follow if we can create a proof of concept quickly and meet certain milestones.  Nevertheless it would be nice to have a few hundred bitcoins on hand for testing the network with real funds.  Also participating in the testing would be a good way to help and make money at the same time.  /end beg

Now as to your question about P2P networks, most P2P is really fairly simple.  There is a chat room, for instance IRC on freenode.  All the clients connect to it and listen for events.  They then respond to those events either via the broadcast & discovery channel (bad idea), or via the back channel requested by the peer (In most cases this is DCC or direct client connection).  At this point the peers have all discovered eachother and then do the work that they are programmed to do.

You are also correct that OpenPay will need to use it's own custom P2P network as a backchannel around the speed limitations of the bitcoin network.  This will be used for transaction requests.  The difference is this network is based on onion routing, which is what TOR uses for anonymity.
The specific methods used should provide a significant speed up to the current system and will be light years ahead of either TOR or Bitcoin in terms of messaging speed.  The bitcoin network will still be used to prove all transactions though.  

This would actually make for a very easy way to exchange BTC for cash if you provided an option for "cash back".

Buy a pack of gum and ask for $20 cash back. They get the cost of the gum and $20 worth of BTC and you get the gum and cash.

Every time I see these sorts of things it always seems to be that the solution ultimately comes down to a trusted Bitcoiner running their own payment processing network or trusted node. I think multi-sig will fix some of this, but the scale of the Bitcoin network is rapidly outpacing what joe-schmoe can run. What's essentially going to have to happen is that we're all inevitably going to become Bitcoin bankers for our friends and family, and we'll provide lower fees for both them and merchants and slowly replace the banks, too.

Things like Openpay seem to confirm this is how it has to go down...

Quite so. But I am working on the assumption that Bitcoin transactions would be converted to fiat instantly to prevent exchange fluctuation risk, and sometimes refunds don't even happen the same day. This also assumes that the customer gets their refund back as bitcoins, and not fiat.

I've been reading this, and I think this would be really cool. I'm not sure If I could be any help, but I'm guessing it could be a P2P network on it's own, running along side Bitcoin would be a good idea. Maybe getting our own 4 digit network ID would be helpful. I really would love to make this happen, not sure if I could be any help. I would love to learn about how to create a P2P network, I have some ideas on how they work...


And I'm guessing it would be like cash. If you spend cash on something at a store and you don't like it. There's no magical button to get it back, you have to tell the store and hope they help you solve it. if not, then maybe you try to sue them. But I guess in the end, It would be just like cash. That reminds me, someone was making Bitcoin physical coins or something, that you could trade offline. I guess it had the key info inside as a QR code, but you could tell if someone attempted to open it or not. Forget who.

Don't forget to figure out some way for the POS owner to process a refund. Even though chargebacks aren't possible, refunds are still necessary.

Make no mistake, it's anything but easy.
Technical limitations aside, there are political & legal considerations that must be taken into consideration.

However OpenPay does have one significant advantage.  
This advantage is what has colloquially been called, the "will of the economic majority".  
Most people want to pay with a card.  The majority of bitcoin holders would like to be able to use their cyberspace currency, in meatspace and do so securely and seamlessly.  

The majority of merchants would like to
A) Pay less in transaction fees
B) Never have another chargeback
C) Do so while processing payments electronically
D) Attract an entirely new market of people with money to spend who are eager to spend it
E) Do the above with a minimum of effort
F) All of the above

This means that there is the potential for a lot of momentum and once an idea has significant momentum behind it, it becomes nearly impossible to stop.

I still have major reservations about how easy it is to bolt together the traditional payment systems and Bitcoin, but I too am eager to hear of any progress.

Please do, this is sounding good.

I don't think these are mutually exclusive goals.
The marketing for OpenPay would have several facets.

The merchant side actually will focus on the severely reduced transaction fees, the lack of charge-backs and the ability to accept merchants without need of new equipment.

The consumer side will focus on the security features (no one can touch your money but you) and of course the ability to spend BTC.  There will also be an attempt to capture some of the un-banked marketshare as well.  Lots of folks don't have bank accounts for one reason or another, lots of others are simply denied the ability to have a bank account without any due process at all thanks in large part to consumer reporting systems like ChexSystems.  Thus for all intents and purposes, a person with an OpenPay card really wouldn't need a separate bank account once enough merchants begin to accept it.

The complete proposal for OpenPay includes creating an infrastructure that allows an easy and seamless standard for transition between BTC , Local fiat, and back again.

OpenPay as I've described it, is intended to be a payment standard AND a payment network.  This payment network functions as a bi-directional, bitcoin to fiat gateway.  It rides directly on top the bitcoin network and uses bitcoins as it's interchange currency.

It is expected that other services will crop up to use the standard and create a healthy and competitive eco-system.

To speed the adoption of, and promote the use of OpenPay, there will be a non-profit organization who's purpose is
To promote the adoption of the OpenPay network by,
#1 Developing the OpenPay standard and providing reference implementations of these standards for free or low cost,
#2 Recruiting users (consumers, banks, exchanges etc) into the network.
#3 Certify experts and provide an exchange of experts in OpenPay to assist incoming users in developing niche applications for the ecosystem.

The proposed name for this organization is the "Open Payments Alliance", yes we've been calling it grandpa around here
The only reason it's a proposed name instead of an actual name at this time is that a trademark search has yet to be completed and the name does seem like something that ought to have been trademarked by someone, however a cursory search shows nothing.

I'm going to keep posting updates here a they happen, so stay tuned!

It would be even better to not have to convince a merchant at all.  If it could function with existing merchant solutions and only be a change on the consumer side, I wouldn't need or want my bank accounts.