The virtual world platform Opensim is getting its first currency system. In the open environment where anyone can setup an Opensim server, the security must be addressed carefully.
The virtual world platform Opensim is getting its first
currency system. In the open environment where anyone can setup an
Opensim server, the security must be addressed
carefully.
As some of you may or may not be aware, earlier in the year
someone [see bottom of post] contracted us to develop a
secured currency infrastructure for a 'hypergrid-aware'
environment. Meaning, something that will work even when you cannot
guarantee the simulators (or their operators) themselves are
trustworthy. Within this infrastructure we only have two trusted
entities - the user, and the "bank" which holds their funds.
The flexibility of this design allows us to setup currency
systems that could work on a completely user-supported environment
like OSGrid, rather than relying on a "walled garden" ala Second
Life(R). It also could be used for multiple grids simultaneously -
that is, several independent grids agree to utilize a single
"bank", and are then capable of grid to grid user transactions
(most likely supported over a hypergrid link).
How does it work?
The basic method of operation is fairly simple - in both cases,
the user attempts to make a payment from within the viewer (such as
to another avatar, into a vendor, etc). Where the HG version
differs is, it then sends the user to a website operated by the
"bank" to confirm the action. The user is authenticated against the
bank (via a password or other login), and is presented with the
transaction details (amount, who to, etc). If the user is happy
with the transaction, they approve it - and it continues to process
on the server like any other normal transaction. If the user denies
the transaction, then it reverses itself as if it had never been
requested.
The basic process
If you examine the module we ship by default with OpenSim, the
"SampleMoneyModule" - it is fairly straight forward when operating
in a grid environment. When you make a payment in the
region (1), the simulator can check and
process the payment via the money server (2),
then finally confirm the transaction with the
seller (3). The biggest limitation here is
that it requires trust on most parties involved - for instance if
the simulator went 'rogue', then it would be possible to just say
you made a payment, without your involvement.
This is essential for some types of payments (eg, llGiveMoney),
but completely unpractical in an open environment. Eg - it allows
for the 'credit card fraud' situation, whereby if the seller knows
you exist and your account number, then it is entirely possible to
debit from it without your permission. Credit cards are badly
designed on this respect - there is no 'confirmation of identity'
with the bank required. (
Something there has been some work into fixing.)
By comparison, the DTL currency processor is a lot more
complicated - it requires some "handshaking" between the parties
before the transaction can proceed. To the user this is transparent
mostly, however on the backend there is a more complicated web of
data flow, of which there are six major steps.
The first step is the negotiation step - in this step, the user
initiates a payment to an object or user (requests a money
transfer). The simulator will contact its registered money server
and ask for a link that the user can confirm their intent
with (1). The user is then given that link
via an IM (we've also made it possible to configure so that you can
get that link sent to you via email from the moneyserver
directly.).
The user should at this point (for anti-"phishing" purposes)
check that the link they are given is sent from the money server
(we strongly recommend using a recognizable domain with an SSL
certificate). This link acts as a verification of intent - the
money server will present the user with the details of the
transaction, and ask them to login to confirm the
transaction (2). Eg, see the picture
below:
If the
user aborts the transaction, then it simply stops all further
processing - only a request for payment was made, and no funds have
exchanged hands. However, if the user approves the transaction,
then the money server notifies the simulator that the transaction
was approved (3), this acts in a similar way
to PayPal Instant Payment Notification. At this point, the
simulator can execute money() events in scripts,
approve an object purchase, or send notifications to
buyer (5) or
seller (6) that their balance has been
updated. The money server also updates the sellers account balance
with the new funds (4).
To the end user, the exchange can be shown in the following
screenshot (the user webpage is a slightly old version now, also
ignore the spelling mistake.)
Disclaimer of liability
The above does not guarantee security - we've made as many steps
as possible to make this usable in a public
environment, however OpenSim is alpha
software, and this code does not provide any kind of
guarantee of merchantability or usefulness. If you are planning on
starting a virtual bank with "Real Money Trade" allowed, then you
need to do a lot more work into fraud prevention and audits of this
code before thinking about using it. You use this
strictly at your own risk.
Final notes
This is not the final version yet, we still have work to do in
that department, however you can access a alpha version on the
OpenSimulator forge (Please note, there are no NAnt build files for
this project yet - it's on the TODO list, but Linux users will need
to generate them if you want to use this, or get a Visual Studio
user to compile for you.)
http://forge.opensimulator.org/gf/project/currency/
Credits
This was developed with funds provided by Michael Huntington -
credit to him for sponsoring this project.
Development was done by DeepThink's Shanghai development team
(Korey Wan, Leon Zhu and Jed Zhu [in our plush SH office shared
with SineWave]), planning was done by Korey and Leon, with the
master architectural design done by yours truly. We're planning on
finishing this project up this week, once we have done so - we will
be moving onto a Groups implementation, also sponsored by Michael
Huntington.