Ideas

I think this is a good idea and could be very successful if you can make it work seamlessly. A lot of work has been done in this area. A lot of very smart cryptographers have created secure protocols for handling transactions and a lot of entrepreneurs have tried to implement them. See for example eCash and eGold as well as the various tipjar implementations.

I think the biggest hurdle to success is the fact that the current system is not that broken. It works well enough that consumers aren't clamoring for an alternative.

DTINGG, the user story sounds plausible, but it really is a matter of implementation details at this point to find a mechanism which will succeed where many many... many... prior attempts have failed.

For example, there's been "tolken" based solutions before... eCoin maybe? There was a system where the tolkens were stored on the client side... so what happens when the PC fails. It would be like iTunes DRM once you've migrated thru 3 computer, you can't access your music.

I may not understand the concept completely here, but you have to offer way more technical details to help communicate how your electronic currency system might work.

Maybe it'd be easier to take an existing one which is close (doesn't have to be a CH idea, can be an existing system or an earlier attempt that went bankrupt) and say how yours is different.

Micropayment problems would benefit the web immensely if they can could be solved.

Well let me expand on the concept a bit with a disclaimer that I am not a technical guy (that's where I need your help). The software would just be a token creator. The token would be a packet of information which would communicate with the i-token server. For instance, when you would create a token for payment with a shipping address and would drag your token into the vendors wallet, two transactions would be verified by the i-token system. One, when the token was created the i-token software would communicate with the server to generate a type of encryption or transaction code for the token (maybe utilizing some type of algorhythm?) and when the token is received another transaction code would be generated. Once the i-token server receives the second code, it would generate a receipt that verifies the transaction.
Also, though the current system we have now is not broken, a lot of people are still concerned with using their credit card online. The i-token will never share account numbers with either party. Another main advantage of this is the simplicity of the transaction. On your i-token program you could type in 5 cents for a token, generate and drag and drop into someones wallet.
Also another benefit would be identity verification. Where as you would no longer have to log into different websites, when you first create an account at a website, you would drag and drop an identity token into the account set with the requested information selected and your account is done. No user name and password (maybe still a nickname). Everytime you visit the site your i-token software could automatically verify identity or you could choose to do it manually. On more secure websites (i.e., company web portals, government websites, etc.) the website could request a High security identity verification (prompt for finger print scan). Also you could create sub accounts for your kids and you could set up an automatic age identity token where every time they visit an adult site, the program would automatically send a token that would notify the website that the user is a minor.
There is a lot of features and benefits to add, but the main advantage of this would be the security of the information exchange. Since the information sent and received is going to the i-token server no information that either party wishes to be undisclosed will be shared.
This could be used for both small and large transactions. Given the right type of support systems, you could literally use this to purchase real estate.

DTINGG, your system sounds a lot like credit cards, where your tokens are account numbers and the i-token server is the card authentication and charge process. As Gord says, the devil is in the details and you have to figure out how you can make your tokens so secure that fraud is an absolute non-issue (since fraud is a fairly small issue with credit cards) and usability is absolutely seamless (since credit cards already work pretty well).

You might take a look at Credentica. They're a new company doing partial disclosure systems. Their architecture might give you ideas or give you something to compare and contrast to.
http://www.credentica.com/

So how do you give the iToken value? You are trying to allay concerns people have of giving their CC # over the web to websites? But ultimately your system will be either prompting them for their CC # or bank account #. I mean you need the user to trust iToken as much as Amazon, as either way one of these 2 will be receiving a credit card #. Right?

So the typical usage would be user uses his own CC # with iToken to generate a token for appropriate value. Then that token is cashed in on a porn site because such sites are so sketchy no one would trust them with their credit card?

Ok, I can see that happening possibly, but it does seem like an extra step i'd only take with a site i don't trust. Maybe I'd be more open to spending $ online, where as right now I only spend it on sites I trust. Not JUST because they'll rip me off for the one-time-fee, but because they would have my credit card number.

BUT PayPal (if you trust PayPal) DOES offer this service (as do other credit card processing companies) where the CC # goes straight to their site and bypassing the sketchy site entirely.

I know I trust HTTPS encryption.

And I guess I trust PayPal with my CC # as much as any big company.

Not knowing iToken... I might not trust YOU! (ha HA!)

Some previous thoughts on micropayments indexed here...
http://www.cambrianh...php?id=micropayments

Well let me expand a little bit...

There are two routes to explore for account creation and funding i-token accounts.

First, would be to have customers open account with ABC Bank. This account could be funded by ACH deposits. This would enable the customer to determine how much money he/she would wish to keep in the account. See revolutionmoney.com on how this account could work. They have an account which clients fund and have a PIN based credit card system. They have a very high profile board and have put a lot of money into it.

The other route would be to solicit this to the financial institutions themselves. They could offer a high security method of transacting business online which could protect their identity and their account information.

The main thing I would like to make clear is that this is not a credit card transaction or anything of the sort. This is a new way of transferring funds online, as well as a identity management tool.

The main advantage we have over any of the other online transactions is the way we transfer information. Customers do not share any information with each other, but rather they share information with the i-token server which has been instructed (as per the i-token) what to do in the given transaction.

I could transfer cash to you and you would never know my name, email address, account information, or address.

I feel that this packet of information (the i-token) could be used in any number of ways. It could communicate with i-token server via https encryption and communicate via algorhythms. So even if you cracked the file only the server would know what it meant. Is that possible? I don't know...you tell me.

One thing I do know is that every major presence on the web is digging around this concept. They are looking for new ways to make the internet work seamlessly and not have people have to type in information everytime they visit a new site. The problem is they are looking at the problem from within the framework of the problem. See Paypal tool bar.

I am asking you to look outside the box and figure out how to make it happen. And your vote would be appreciated...

Thanks for the further explanation, but I still don't think you've sufficiently distinguished yourself from existing systems. Your tokens sound a lot like paypal except that paypal keys off of email addresses and your system would be more anonymous. That's basically paypal with nicknames or numbers instead of emails as the account index. Since anyone can get a fairly anonymous email address now through gmail or any other webmail service, what do you provide that really distinguishes you from them?

The latter part of your explanation (selective transfer of information) sounds a lot like Credentica that I linked to earlier. They have some very big brains behind that. How do you differ or compete with them?

Hi DTINGG, I'm quite new to this type of discussion rooms, but I have a good bit of IT background and Business Experience.

I basically see two issues to tackle:
1. technology-wise: you need to figure out how the information will be exchanged, otherwise you are going to define something very close to what micco said.
2. Credentica only deals with authentication, you need to add the financial service component that links to the bank. Here the are equal challanges, since you want to define a mechanism that is too close to paypal.

Have a look at http://www.revolutioncard.com for some food for your brain, you may find some interesting things. Even if this is not exactly what you are describing, it might trigger new thoughts...

mergellina, regarding your #2, Credentica seems to handle selective disclosure and non-repudiation (at least based on their PR material) which provides a lot more than just authentication in building toward a payment scheme. Seems like if you wanted to use existing credit cards and just make the transactions easier and more secure, that selective disclosure could be used to release the details you wanted (e.g. shipping address and credit card info) to a vendor.

Note, I'm not associated with Credentica and don't know anything about their system outside their website PR. I just happened to be thinking about it when I read this idea and it seemed to be very related. There have been lots of similar systems over the years (which failed to gain traction) but Credentica just happened to be the flavor of the day.

it sounds to me like paypal with a better ui. not a bad idea so i rate ok

I thank you all for you comments... And I agree with a lot of what has been said. One of the reasons I posted this on here was that I am not sure how this would best be done. What I see is that e-commerce transactions are heavily user ID based or transaction number based. Essentially what I am putting out there is something we could actually create to change the landscape of these transactions. A new way to package information in a highly secure way that will only speak to the i-token server. I believe that we could establish this in such a way that not only could you do micro transactions, but also macro transactions (Real estate, Trade, etc.) One of the other major things that I don't think that people see as a benefit is the ability to establish terms within these tokens. It essentially becomes a digital Letter of Credit which would have an escrow type system built in. None of these other systems offer anything like this.

Its something that is needed its just you have to prove that you are a good source that is secure.

something to take a look at:
http://identity20.co...eos/oscon_qt_lg.html