Q: What kind of connection is used between merchants (publishers) and Clickshare (e.g. requesting/ authenticating a token)?
A: The Clickshare Web Server at each Clickshare Service Provider (publisher or billing entity ) maintains a persistant connection to the Clickshare Authentication Service. Billing entities request authentication tokens for their valid users; publishers ask that these be validated.
The protocol running over this connection is our own design, as lightweight as possible. The protocol is datagram-based, with reliable-delivery provisions built-in.
The "Clickshare Authentication Service" consists of a set of machines, operated by Clickshare Corp, that offer Clickshare Authentication. If a Web Server's connection to one such server is broken due to server error, bad network, etc, it is possible to reconnect to another authentication server on the fly.
Q: Is this connection always open or must it be re-established everytime?
A: The connection is initiated when the Web Server starts up. It is always open, re-established only after failure (of either end).
Q: How many of these connections per second can a typical server handle?
We need to re-phrase this, given the above, into two questions:
1. How many requests (acquire, validate, invalidate...) can one Clickshare Authentication Server handle per second?
A: This depends very much on the quantity of "iron" one throws at the problem. Our early experience suggests that one small machine (Intel Pentium, say) can handle about 25 requests per second - or about 1M requests in a (12 hour) day. We have noted that this volume scales well with changes in processor performance probably to the point where throughput is limited by the network interface (ability of the network to deliver packets to the machine's network adaptor, and the ability of that adaptor to deliver packet's to the process).
Please recall that Clickshare's "token validation" bears NO resemblence to the "credit card verification" process (where, for each request, a separate call is opened and closed).
The Clickshare Authentication Service can be thought of as an "authentication proxy". The billing entity's Web Server tells Clickshare:
"This is a valid user. Register this user for a new session, and validate all the user's requests for me (within the confines of service parameters and so forth that we both agree on)".
All other Web Servers then request authentication information from Clickshare, which can perform this service at very high speed.
2. How many Web Servers can a Clickshare Authentication Server handle at once?
A: Given the numbers above, the volume of requests to be processed is more important than the number of servers handled. It might be that 5 high-volume web servers (+250,000 requests per day) might be served by a single Clickshare Authentication Server, or that 25 medium volume servers (50,000 requests/day) are serviced.
Each server of the Clickshare Service is designed to handle a scalable number of Web Server "clients". Clickshare Corp advises the operators of these Web Servers which authentication servers it can connect to. The "load" is balanced by authorizing a mixture of sites for each authentication server. (wouldn't an automatic load-balancing technique be nice?! coming soon...).
Requests are handled on a first-come, first-served basis. No priority is given to large sites (for example), even though a large site may consume 25% of an authentication server's service bandwidth.
Q: Can the token authentication be handled by some distributed processing network or must it be centralized? Are there any concerns for bottlenecks during peak times?
A: As explained above, the Clickshare Authentication Service is very distributed (offered by a set of machines, not a single machine). The Service can be scaled by adding more authentication server machines, by making each machine more powerful, and by judicious placement of the servers around the internet (to limit the number of hops between Web Server and Authentication Server). Each Web Server has a set of machines that it can contact for service.
It is certainly true that the Clickshare Service "imposes" a third party into the transaction scheme. And, of course, when thinking from a "vulnerability" viewpoint, adding anything between the two parties of a transaction creates weak points (if, say, the mid-point goes down). However, the weakness is also the strength - imposing a neutral third party on the process provides for third-party verification. We think this is crucial for widely adopted transaction services. Its an engineering problem to design the service in such as way that it is tolerant of many kinds of failure. (That's been our goal from the start).
Q: What kind of security is used to prevent unauthorized use of tokens? (no encryption?)
A: We have always felt that the need for security must be balanced with the risk of exposure. There are two ways to minimize that risk: technical and financial.
Tokens in the Clickshare Service have limited value - limited in time, and limited in dollar value (in that everyone we're currently in discussion with wants begin by using the Service for small-value transactions ($.10 -> $1.00), as we had planned). The contents of the token are not readable by any of the Web Servers (who deal with the token as an opaque string in all cases). Therefore, private key encryption can be used for the token (since only the Authentication Server that issued the token has to read its contents). Second, several parameters are built into the service that can act as a "throttle" on the amount of use a token gets. This prevents a thief from rapidly acquiring volumes of chargable material (say, using a specially designed "agent" program). Thirdly, each token is anchored to one IP address, and valid for only one session. Thus, theft of a token also requires IP spoofiing by the host as well.
That's the current technical setup. In the immediate future, we see several schemes for providing a high-security service that could comfortably scale to higher dollar values per transaction. These depend on widely available browser features which are not yet available, though they are being "standardized" (by the browser vendors, through the Internet's IETF). We think it is important to remain "browser independent" even if that appears to limit our available options.
Note however, that there is a quantitative difference between low value transactions and high value ones: in the latter, the user expects to "pre-approve" each one. For low value fare, it's probable that the user will not want to be interrupted for every information request, but rather might want to be advised at the end of a session. The Clickshare Service is designed to be a minimally intrusive service, fast-acting and out of the user's view. Thus, it lends itself to the high-volume, low-value arena of purchasing information rather than "objects".
The other aspect of security is bearing the financial risk. If the user or the web server operator were to bear all the financial risk for purchasing information, then the Clickshare Service would have to be very close to "perfectly secure" (impossible actually) to be accepted. In fact, Clickshare does bear some of the financial responsibility, and needs to build into its service fee structure a buffer for dealing with fraudulent transactions.
Q: Who would handle customer complaints? (home publisher?)
A: The experience at First Virtual Holdings is that they get every kind of customer service call possible - even though they are responsible for a very tiny part of their customer's Internet use. Therefore a question like this is hard to answer authoritatively.
We feel customer service complaints are likely to be handled most often by the billing entity. That's one reason why we profit-share with the "home publishers". However, I think that users will quickly recognize repeated failures on the part of specific publishers, and directly interact with them. Further, I think large numbers of complaints against a publisher will result in action by the home-site operators themselves (in this regard it is very similar to the credit card model, I think).
Clickshare will be involved as a record-keeper, I think - verifying records of transactions.
Q: What share of total costs (averaged over all transactions) would arise from customer service?
A: That's a question I can not answer from experience - I can not point you to any deep experience here at Clickshare, or with any other service except First Virtual (who published a paper on this topic!). Of course, FV is not a micro-transaction service.
Our financial model shares a portion of the service fee with the billing entity that actually manages the customer relationship. Thus, we recognize the customer service challenge implicit in managing that relationship.
Q: What share of total costs would arise from server processing and storage both publishers and Clickshare?
A: Clickshare Corporation's largest cost is likely to be the authentication and logging servers themselves, especially if we generate the high volume of transactions we hope to generate. We will probably require premium "real estate" on the network, which adds to the cost.
The costs for publishers and service providers will very widely depending on how the Clickshare model is adopted. If publishers themselves wish to acquire and manage bases of users (so that they can provided such users with personalized services), then publishers will have to bear the expense of serving that user base (see above). However, if banks, credit companies, and/or telcos become the organizations that service users, then publishers will have near-zero user service costs (that is, belonging to the Clickshare universe will have minimal operational cost impact). In this latter model, billing entities will bear the cost of maintaining the customer relationship (but, on the other hand, get to have the financial an service advantage of that relationship as well).
Early on, we viewed the world as "publisher-centric" (owning both content and users). Now, we see a recognition that customer service is a challenge most publishers are not used to. Over time, we think that the traditional billing companies will provide some advantages, while the publishers themselves provide others. The Clickshare Service itself is not biased toward a certain outcome.
Q:What increased bandwidth for the merchant might be required to handle transactions? What share of total costs would arise from communications (bandwidth) both for the publishers and Clickshare?
A: Sadly, we are not able to provide anything but a heuristic answer to this at this time: Our service is as low bandwidth as is possible with today's IP technology. In the model where service providers and publishers are distinct, publishers will see very limited bandwidth decay due to our service alone. The service providers, who are likely to be providing a set of auxiliary Clickshare services to users (daily expense reports, balances, transaction history, etc) will see more decay certainly.
But, overall there are fewer than 1000 bytes per request - actually fewer than 500. So, if one can (dare!) assume that the average URL request results in 8192 bytes sent to the client (which itself generates a lot of connection setup/tear down bandwidth), then our service adds 6% (including both authentication and logging in this value).
Actually, we think bandwidth is not the concern. We think LATENCY is the concern. We have designed a system that is low-latency so that the consumer sees no "interference" in acquiring information. Recall that there is NO bandwidth increase at all between client (browser) and Web Server, where the connection speed is typically poorest.
Q: What fraud/ error rate to you anticipate using Clickshare?
A: Again, very difficult to determine beause no one has any experience with "systematic fraud" (which, in my mind is the danger here). The large credit card companies use about 12-18 basis points to cover fraudulent charges (this compared to 300 basis points as the number of users from whom they generate zero income due to the party paying his/her bill on time!).
Techical inquiries to David M. Oliver, Managing Director-Technology: < dave@clickshare.com>