Thursday, November 15th, 2012
    • HOME
    • MISSION
      • The larger vision
        • Four-party model
      • The origins
    • SERVICES
      • AUDIO: Nine minutes
      • Service detail
      • Service examples
      • Network services
      • Listen
    • CLIENTS
    • PARTNERS
    • NEWS
    • ABOUT US
      • Clickshare Blog
      • Our team
      • Privacy policy
      • Software Engineering Jobs at Clickshare
    • SUPPORT
    • CONTACT
  • How Clickshare was set up to enable
    a shared-authentication user alliance

    By Bill Densmore
    Clickshare Founder

    Clickshare gives a consumer access to lots of websites, without having to pass around personal information, or register repeatedly. The consumer can buy quickly, easily and securely with charges ending up on one account.

    The system permits single registration, but also universal log-in, or sign-on, to multiple, independent websites which participate. It protects user privacy by avoiding the need for a massive central database.

    The Clickshare backend basically does nothing except serve as a proxy for audience owners, forwarding and verifying the authentication of their own users, and logging the activity of those users at participating websites. The logs, however, contain only a one-time alpha-numeric which only the user’s home base can map to an identified user. So Clickshare knows the user is unique, but doesn’t know who the user is.

    This elegant architecture is what makes Clickshare the ideal “federated authentication” service. Clickshare reliably shares among websites the fact that a user is “authentic”, but doesn’t, itself, need to know who that user is.

    The Clickshare Service was conceived in 1994 and prototyped in 1995 and 1996. In news releases on PR Newswire back then, we described its unique features in these words:

    • One-account, one-ID, single sign-on for users to multiple websites.
    • No central data repository of private consumer data.
    • Ability to log transaction details of purchases across all Clickshare-enabled websites.

    In that era, we described Clickshare as a “micropayments” system, not recognizing that was a feature of the service but not the fundamental value proposition.

    We conceived Clickshare originally as a solution to a problem which we foresaw newspaper publishers having — how to hold onto users. We designed the system to allow a user’s “home-base” newspaper — that was the phrase we used — to maintain and control the billing and customization relationship with the user. And yet the home base would have the ability to help that user find and pay for information from multiple other sources.

    We called this, as early as 1995, “distributed-user management” (not a good marketing term, since it’s acronym is DUM, but descriptive). Today we refer to it as “distributed customer management.” (DCM sounds better).

    The notion of keeping control of the user base out of the hands of a central “Big Brother” type authority was absolutely the bedrock of our idea and technology. It was natural for a publisher and journalist to be sensitive to this. In all the years since 1994, we have been continually amazed at the litany of dot-com’s which tried to control the user and so ended up with no users because nobody would cooperate with them.

    Amid all the wreckage of dot-gones, Clickshare stands and thrives because we started with a very simple premise — create a marketplace for the exchange and sharing of digital content among distributed, independent audience owners.

    • spacer Bookmark on Delicious
    • spacer Digg this post
    • spacer Recommend on Facebook
    • spacer share via Reddit
    • spacer Share with Stumblers
    • spacer Tweet about it
    • spacer Subscribe to the comments on this post
     
     
     
    gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.