Cryptographically auditing OpenTransact transactions

[Pelle Braendgaard]

One thing that was part of NeuClear I worked on a few years ago that I
really liked was that transactions could be audited by third parties.
A payment message was XMLSignature with a RSA signature. The account
ids consisted of sha1's of the accounts public key and the signature
string itself was the global transaction id. So from the database
record you could rebuild the xml and verify the signature.

Why go through this? Well it would make it harder for an operator to
fiddle the books by faking book entries, which could make life more
difficult for Madoff wanabes.

While I don't think OpenTransact itself shouldn't define anything
about how transactions are stored, I think there are some interesting
possibilities for optionally providing the same capability for
OpenTransact based systems.

Firstly it would require using RSA signing which is not that common in
OAuth. There would also have to be some method of getting a public key
from the oauth_consumer field. This could be a service specific
directory but it could also be a public directory service.

For NeuClear I ran a small directory called pkyp.org. I've still got
the domain and would offer it up for this purpose.

So all we need to do is store all relevant oauth fields in the
database. This could either be individually or hell why not the whole
OAuth request. However this could be too much data to store if you are
storing lots of transactions.

I am working on an OpenTransact implementation where I am planning on
doing this and offer an audit feed.

P

--
http://agree2.com - Reach Agreement!
http://extraeagle.com - Solutions for the electronic Extra Legal world
http://stakeventures.com - Bootstrapping blog

[Anthony Schexnaildre]

While I think this is an interesting idea and I remember looking at your implementation in Neuclear I would be concerned that this would push your OpenTransact off into a corner as it seems as though it would make interoperabilty with other payment network systems difficult (i.e. ISO8583). Of course that may not be a concern of yours. I have tended towards more a more generic design with multiple levels of audit controls.

Secondly I don't think that is a silver bullet to the fraud as all it does is ensure the accounting records layed down match the original message but does not guard againt faking approvals themselves.

Lastly doing all encyption/decryption in software is kind of expensive and is not actually secure as your encryption keys are going to be laying around in the file system or in memory. Thus anyone with a real business case for this type of encryption is going to buy an HSM anyway and need to rip out the software based stuff.

Just my two cents

-Anthony

--

You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.
To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.

[Pelle Braendgaard]

Thanks Anthony,

On Wed, Dec 16, 2009 at 2:05 PM, Anthony Schexnaildre
<apsc...@gmail.com> wrote:
> While I think this is an interesting idea and I remember looking at your
> implementation in Neuclear I would be concerned that this would push your
> OpenTransact off into a corner as it seems as though it would make
> interoperabilty with other payment network systems difficult (i.e. ISO8583).
> Of course that may not be a concern of yours. I have tended towards more a
> more generic design with multiple levels of audit controls.

This should never be a requirement for OpenTransact, just a particular
way of implementing it. I'm a big believer in keeping the core
extremely simple.

With regards to interoperability OpenTransact was designed as simple
blank slate. But it would be pretty easy to do interoperability.

Lets say you want to offer a VISA card on an OpenTransact provider you
could create a gateway which acts as an OAuth Consumer, like the proof
of concept I created http://capcard.heroku.com/.

To go the other way, where I mean implement OpenTransact on top of an
existing system that would be pretty simple as well. You would just
present an OAuth enabled web service that on post translates the
payment into whatever the legacy system uses.

>
> Secondly I don't think that is a silver bullet to the fraud as all it does
> is ensure the accounting records layed down match the original message but
> does not guard againt faking approvals themselves.

This on its own would not do it, it would however provide an
interesting auditing layer. As every transaction would be signed by
an OAuth consumer, this could be independently verified. It doesn't
in itself do anything about the security of these consumers as that
should probably be a contractual issue between the provider and the
consumer. Similar to the PCI compliance requirements in the CC
industry.

>
> Lastly doing all encyption/decryption in software is kind of expensive and
> is not actually secure as your encryption keys are going to be laying around
> in the file system or in memory. Thus anyone with a real business case for
> this type of encryption is going to buy an HSM anyway and need to rip out
> the software based stuff.

With todays CPUs I don't think signing is that big of an issue
anymore? Am I wrong in this? HSM's are always great but not really an
option for cloud hosting either.

Thanks a lot for your comments.

P

[Anthony Schexnaildre]

I guess CPU expense really was not the concern as much as the total expense of the whole endevor like managing the pki, educating entry level developers on how it all works, getting people to create their public keys, etc.

I thing the real challenge will be to come up with a standard set of important fields that you are actually verifing in addition to the identity of the sender. This way you can recive requests in one message schema (ISO8583) and format (hex bytes) and the auditors could consume the same data in some other schema and format  like JSON. I guess I am inclined to think that the first thing a third party is going to want to do is get the data in from their openTransact gateway and translate it into their own internal format. Once there they would verify the authenticity in their own legacy systems and business processes.

I do however think it would be of great value if all this could be implemented in a completely transparent way especially when you start talking about digital negotiable instruments such as cheques.

-Anthony

On Dec 16, 2009 3:24 PM, "Pelle Braendgaard" <pel...@gmail.com> wrote:

Thanks Anthony,

On Wed, Dec 16, 2009 at 2:05 PM, Anthony Schexnaildre <apsc...@gmail.com> wrote: > While I think t...

This should never be a requirement for OpenTransact, just a particular
way of implementing it. I'm a big believer in keeping the core
extremely simple.

With regards to interoperability OpenTransact was designed as simple
blank slate. But it would be pretty easy to do interoperability.

Lets say you want to offer a VISA card on an OpenTransact provider you
could create a gateway which acts as an OAuth Consumer, like the proof
of concept I created http://capcard.heroku.com/.

To go the other way, where I mean implement OpenTransact on top of an
existing system that would be pretty simple as well. You would just
present an OAuth enabled web service that on post translates the
payment into whatever the legacy system uses.

> > Secondly I don't think that is a silver bullet to the fraud as all it does > is ensure the acco...

This on its own would not do it, it would however provide an
interesting  auditing layer. As every transaction would be signed by
an OAuth consumer, this could be independently verified.  It doesn't
in itself do anything about the security of these consumers as that
should probably be a contractual issue between the provider and the
consumer. Similar to the PCI compliance requirements in the CC
industry.

> > Lastly doing all encyption/decryption in software is kind of expensive and > is not actually se...

With todays CPUs I don't think signing is that big of an issue
anymore? Am I wrong in this? HSM's are always great but not really an
option for cloud hosting either.

Thanks a lot for your comments.

P > > Just my two cents > > -Anthony > > On Dec 16, 2009 1:03 PM, "Pelle Braendgaard" <pelle@stak...

--

http://agree2.com - Reach Agreement! http://extraeagle.com - Solutions for the electronic Extra Lega...

[Miles Thompson]

Folks,

You must have heard of this 'square' thing by now..

"the technology, which converts data encoded in the magnetic strip of a credit card into audio tones; the reader plugs into the headphone socket of an iPhone or iPod touch, and those tones are interpreted by Square’s software"

I don't quite get how it would fit into alt-currency exactly but certainly seems like a *potential* game changer for things like CapCard and such?

https://squareup.com/
http://www.techcrunch.com/2009/12/01/square-jack-dorsey-launches-paypa/
http://www.slashgear.com/square-credit-card-reader-origins-in-dispute-1666129/


What do you think of it all Pelle?

Miles

--

You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.
To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.

--
miles
http://blog.tradeify.org
http://google.com/profiles/utunga

[Jake Howerton]

While cool, this is just a really cheap swipe card reader, with some
digital services on the backend. Excellent for people with mobile
businesses who want to accept credit cards. Their site also seems to
lean towards their abilities to get more people merchant accounts more
easily but I am not sure how much they can do about that. The rest of
the business seems to be the standard merchant/gateway model, with a
way better looking pitch.

--
Jake Howerton
http://twitter.com/jakehow
http://jake.howmeta.com

[Anthony Schexnaildre]

Agreed that it is very cool but it's kind of an apples and oranges comparison when talking about Pelle's OpenTransact I think.

-Anthony

[Pelle Braendgaard]

On Wed, Dec 16, 2009 at 5:12 PM, Anthony Schexnaildre
<apsc...@gmail.com> wrote:
> I guess CPU expense really was not the concern as much as the total expense
> of the whole endevor like managing the pki, educating entry level developers
> on how it all works, getting people to create their public keys, etc.

I see this as being a lot simpler than regular PKI. While you
certainly could do X509 PKI with this, it is as you say extremely
complicated.

I also think it's getting better with knowledge about creating public
keys as many developers now have had to do so for interfacing with
Google OAuth and Amazon web services by now.

Of course only developers would have to see this and depending on what
level they're at they will either see them as some key they generate
with a script or an opportunity to do something interesting with the
data. NeuClear depended on end users creating keys and signing, which
I have definitely discounted for this, even though technically
speaking it is now possible to hide the complexity of this in a mobile
app.

>
> I thing the real challenge will be to come up with a standard set of
> important fields that you are actually verifing in addition to the identity
> of the sender. This way you can recive requests in one message schema
> (ISO8583) and format (hex bytes) and the auditors could consume the same
> data in some other schema and format  like JSON. I guess I am inclined to
> think that the first thing a third party is going to want to do is get the
> data in from their openTransact gateway and translate it into their own
> internal format. Once there they would verify the authenticity in their own
> legacy systems and business processes.

OpenTransact just have 2 required fields:

* to
* amount

and one optional

* memo

The from (debit) account is inferred through the OAuth token.

Anything else such as currency etc can be modeled by using different
transaction urls.

Of course how you store all of this is up to your application.

>
> I do however think it would be of great value if all this could be
> implemented in a completely transparent way especially when you start
> talking about digital negotiable instruments such as cheques.

There is a neat parallel project by Andreas Pizsa called OpenToken
which creates a bearer instrument using similar terms to OpenTransact.

>
> -Anthony

--
http://agree2.com - Reach Agreement!

[Pelle Braendgaard]

I agree. It's pretty neat from a gadget point of view, but I don't
find it too innovative from a financial stand point.

I'm not quite sure why but I find in general that there is very little
innovation in the US tech industry when it comes to financial apps.
PayPal was the last real high profile financial startup that attempted
to innovate. Allright I forgot about Prosper and the other social
lending companies that really are innovating.

But Mint, Square and most of the other darlings of the digerati seem
to be nothing more than innovative bandaids/guis on top of 1960s
financial products.

-P

[Anthony Schexnaildre]

Of course only developers would have to see this and depending on what
level they're at they will either see them as some key they generate
with a script or an opportunity to do something interesting with the
data. NeuClear depended on end users creating keys and signing, which
I have definitely discounted for this, even though technically
speaking it is now possible to hide the complexity of this in a mobile
app.

Ok, I can live with that.

OpenTransact just have 2 required fields:

* to
* amount

cool

The from (debit) account is inferred through the OAuth token.

The one problem that I have here is that you are assuming that the consumer is the owner of the "from" account. It kind of depends on the type of transaction and if their are tiers in the transaction pipeline. 

First the type of transaction. What you have described works fine for sending funds in a p2p type scenario. It kind of breaks down for other types like "request money" or a "merchant purchase". In those cases the "to" account would actually be the account identified by the OAuth token. 

Secondly if there are tiers like merchant-->acquirer-->authorisor-->issuer then depending where you are in the chain the OAuth token would not have any relation to the "from" or "to" accounts.

Seems like if you just add a "from" field instead of relying on the OAuth token in that way you gain a ton of flexibility and functionality. Of course I may be missing the entire point and you may be purposely limiting things for a good reason.

Anything else such as currency etc can be modeled by using different
transaction urls.

I am sure about this one yet. I personally model things a little different. Something feels awkward but I don't have anything constructive to add yet. I may be tempted to add actual "asset" field and use various rest urls in a different way.

There is a neat parallel project by Andreas Pizsa called OpenToken
which creates a bearer instrument using similar terms to OpenTransact.

I found the OpenToken facebook page but is there developer page with code or is this project still in concept form? I would really like to know more.

-Anthony

[Pelle Braendgaard]

Thanks Anthony for your questions, they are very helpful.

Most of these scenarios can actually be handled by the OAuth protocol.
OAuth in its normal "3 legged" variety is a delegated authentication
protocol so each request has the consumer (which is an application or
service provider) and a token which is the end user. The end user
actually has to authorize the token to give the consumer access to the
account, at this step we can add all sorts of limits like transaction
limits, time limits etc.

I've highlighted some use cases here. If there are any important use
cases not mentioned, please let me know and we can try to work it out
as an exercise.

http://wiki.github.com/opentransact/opentransact/use-cases

>
> Anything else such as currency etc can be modeled by using different
> transaction urls.
>
> I am sure about this one yet. I personally model things a little different.
> Something feels awkward but I don't have anything constructive to add yet. I
> may be tempted to add actual "asset" field and use various rest urls in a
> different way.

The idea is that OpenTransact is a very thin layer ontop of http. The
concept of URL's has as we've seen been able to model just about
anything. It is slightly unique in the payment world, that
traditionally has been message based, but if we accept everything as
http then we can model all sorts of rich applications on top of a url
space. Again OAuth works great in http as the url itself is part of
what is signed.

>
> There is a neat parallel project by Andreas Pizsa called OpenToken
> which creates a bearer instrument using similar terms to OpenTransact.
>
> I found the OpenToken facebook page but is there developer page with code or
> is this project still in concept form? I would really like to know more.
> -Anthony

I believe it is being developed. We need to get more info out there about it.

Regards

P