Re: The Register - UK firm touts alternative to digital certs (fwd)
at Monday, October 21, 2002 3:14 PM, Trei, Peter [EMAIL PROTECTED] was seen to say: I'd be nervous about a availability with centralized servers, even if they are triple redundant with two sites. DDOS attacks, infrastructure (backhoe) attacks, etc, could all wreck havoc. Indeed so, yes. I suspect (if it ever takes off) that they will have to scale their server setup in pace with the demand, but to be honest I think 600/sec is probably quite a high load for actual payments - we aren't talking logins or web queries, but actual real-money-payment requests. I suspect that, if it became the dominant payment method for amazon or ebay, they would need a much more hefty server, but at this stage I suspect a heavy load would be two auths per second :)
Re: The Register - UK firm touts alternative to digital certs (fwd)
On Mon, Oct 21, 2002 at 03:37:33PM +0100, David Howe wrote: at Monday, October 21, 2002 3:14 PM, Trei, Peter [EMAIL PROTECTED] was seen to say: I'd be nervous about a availability with centralized servers, even if they are triple redundant with two sites. DDOS attacks, infrastructure (backhoe) attacks, etc, could all wreck havoc. Indeed so, yes. I suspect (if it ever takes off) that they will have to scale their server setup in pace with the demand, but to be honest I think 600/sec is probably quite a high load for actual payments - we aren't talking logins or web queries, but actual real-money-payment requests. Looking at their web site, they seem pretty generic about what it's for, but I did not see any mention of using it for payments. So I assume it's for logins. They do say that their servers are benchmarked at 300 transactions/sec. That's pretty darn slow for single des. There would have to be an authenticated and probably encrypted session between the server accepting the login (or the merchant if it really does payments) and the back end. But even using SSL/TLS, which would be more than is required but an easy component to plug in, they ought to be able to get at least a true 1000 sessions/sec using one of the current SSL accelerators out there. Maybe they have a bunch of slow database lookups? Perhaps there is a long RTT for the check against the CIA blacklist? If it is for logins, how many sites would be willing to let someone else know when their employees log in? That could be useful competitive intelligence. Eric
Re: The Register - UK firm touts alternative to digital certs (fwd)
at Monday, October 21, 2002 4:20 PM, Eric Murray [EMAIL PROTECTED] was seen to say: Looking at their web site, they seem pretty generic about what it's for, but I did not see any mention of using it for payments. So I assume it's for logins. well, I was working from: The Quizid registry The Quizid registry is a database that translates the customer profile information required to facilitate secure online payment. Once a customer has been authenticated by the Quizid vault, the payment transaction is completed between the registry and the acquiring bank using the appropriate payment protocols. The bank then performs the necessary clearing between acquirers and issuers. As well as storing credit and debit card details the registry can be used to securely hold any personal information you would rather not enter over the Internet. So you can pre-load your delivery address, details of loyalty cards or even your seating preference for airline tickets. As well as being more secure this makes shopping online faster and simpler as you don't have to enter in the same information time after time. plus the two of their demo sites I checked offer it only as a checkout payment option. They do say that their servers are benchmarked at 300 transactions/sec. That's pretty darn slow for single des. Not sure that 1Des is the bottleneck. From my (perhaps incorrect) idea of the process: 1. user checks out with QuizID code 2. Website opens link to QuizID and presents *its* credentials 3. QuizID checks database, confirms valid login for the website 4. Website presents user ID and Quizid code 5. QuizID checks database, verifies that QuizID code was recently generated, the sequence number is in a reasonable range, and that the user hasn't closed his account or something 6. QuizID returns to Website any site-specific data held in its registry for that Website+Customer pair, plus any data that the user has marked of general accessability (such as delivery address) 7. Website requests payment of $amount 8. QuizID retrieves bank details from database for user, signs onto merchant services, and gets a authorization for the amount; signs on again and commits the payment; gets the account details for the Website owner from the database; signs on to the merchant services *again* and makes a payment of equal amount (presumably minus their fees) into the Website owner's account 9. QuizID sends a success (or fail) message to the Website there are probably enough individual comms and database lookup tasks there to slow things down quite a bit, even leaving aside the crypto aspects.
