|
|
|
|
|
| Before the user’s personal information can be used to provide personalized services, users must first identify themselves to the service. One of the key advantages of a system like Talisman is the ability to perform “global single signon” – allowing users to identify themselves once per browsing session across the entire globe, rather than once for each and every website. |
|
| This identification process can take a wide variety of forms, only a few of which will be listed in this document. In particular, this document attempts to describe three primary signon methods: type-click, one-click, and no-click. While the end effect of each of these would be the same irrespective of the type of account is being used, the examples assume that distributed accounts are in use. In addition, the various mechanisms can surely be implemented in countless ways, all of which provide slight differences and benefits. For this document, however, the examples attempt to optimize the mechanism for reader clarity, rather than efficiency or security. |
|
|
|
| The first and most basic way to have users identify themselves is through a process called type-click signon. As the name implies, type-click signon involves two steps: (1) typing an account name, and (2) clicking a signon button. The first time a user does this, of course, more actions must be taken such as authenticating to an account provider. However, for the second and all other times, only the two steps are necessary: typing and clicking. |
|
| The various low-level steps that are taken on behalf of the user by the client computer and the various providers are outlined below. This example assumes the user has a distributed account, hosted by Accounts, Inc. and is attempting to access the eTrade online brokerage. |
|
1.
|
The client requests a web page from eTrade. At this point, the client has acquired no cookies from eTrade, and thus does not upload any cookies along with the request. |
|
2.
|
Per the client’s request, eTrade returns the web page. This web page contains an area called the signon area that contains an account name entry box, along with a signon button. At the same time, eTrade sees that it does not know the client (as the client didn’t upload any cookies), and thus returns to the client a cookie containing a unique identifier called the eTradeID. |
|
3.
|
The user types her account name (“alice@accountsinc.com”) into the signon area and clicks the signon button. This causes the client web browser to contact eTrade with the request to signon to the indicated user’s account. |
|
4.
|
eTrade decodes the account name indicated in the signon request and determines which account provider is its host (Accounts, Inc.). eTrade then redirects the client to the authentication page of Accounts, Inc., including the eTradeID and information indicating that the request originated from eTrade. |
|
5.
|
The client receives this redirect and transparently contacts the authentication page of Accounts, Inc. with the eTradeID and originating website. The client has never visited Accounts, Inc. and thus uploads no cookies. |
|
6.
|
Accounts, Inc. determines that it does not know the user (as the client uploaded no cookies) and presents a standard authentication web page (possibly nothing more than a simple name/password form). At the same time, Accounts Inc. returns a cookie containing a unique identifier, called the accountsIncID. The accountsIncID is entirely unrelated to the eTradeID, each of which is stored on the client with different, independent cookies. |
|
7.
|
The user receives this web page and cookie, and enters her name and password. |
|
8.
|
Upon a successful authentication, Accounts, Inc. contacts eTrade and notifies it that the client associated with eTradeID has successfully authenticated to the “alice@accountsinc.com” account. |
|
9.
|
Accounts, Inc. then redirects the client back to the original eTrade web page. |
|
10.
|
The client requests the original eTrade web page, uploading along with the request the cookie containing the eTradeID. eTrade can then use this eTradeID to determine that the client is acting on behalf of the “alice@accountsinc.com” account. |
|
Figure 1: Type-click Signon with eTrade
|
|
|
| The first time through, the process appears to have four end-user steps: (1) type in the account name, (2) click the signon button, (3) type in the password, and (4) click the submit button. All other complexity is handled outside of the user’s view. After this process completes, however, the account provider (Accounts, Inc.) has a cookie that can be used to bypass future authentication attempts. Specifically, through the use of the accountsIncID cookie, the account provider can skip steps 7 and 8. This has the effect of reducing the total number of user-perceived steps to just two: (1) type in the account name, and (2) click the button – halving the time spent authenticating. |
|
| The advantage of this system is its extreme decentralization – the only entity in the position to gather information about account behavior is the account provider itself. The realm plays no active part in the authentication process and as such cannot possibly pose privacy risks. |
|
| However, this system requires that users repeatedly enter their account names for each service. While not a terrible burden, it is unnecessary (as demonstrated by one-click signon, and no-click signon). Additionally, it requires that services maintain code that can redirect users to the appropriate account provider – a non-trivial task that introduces potential maintenance issues as the system evolves. |
|
|
|
| Slightly more convenient (to the user) and complex (to the services) is one-click signon. Unlike type-click signon, one-click signon requires no typing. Aside from the initial signon (which requires some form of authentication process), all future signons occur with a single click by the user. |
|
| The various low-level steps taken on behalf of the user are outlined below. |
|
1.
|
The client requests a web page from eTrade. At this point, the client has acquired no cookies from eTrade, and thus does not upload any cookies along with the request. |
|
2.
|
Per the client’s request, eTrade returns the web page. This web page contains an area called the signon area that contains nothing more than a single image button, which is hosted by the Merchant realm provider. At the same time, eTrade sees that it does not know the client (as the client didn’t upload any cookies), and thus returns to the client a cookie containing a unique identifier called the eTradeID. |
|
3.
|
When the client receives this page, it goes to retrieve the image for the button inside the signon area. The client has never visited the Merchant realm provider before, and thus does not upload any cookies. |
|
4.
|
The Merchant realm provider, seeing that it does not know the client (as the client hasn’t uploaded any cookies), returns a basic “Click here to sign on” button. This button is called the signon button. Along with this button image, the Merchant realm returns a cookie containing a unique identifier called the merchantRealmID. This merchantRealmID is different from the eTradeID, and both are maintained in separate cookies. |
|
5.
|
The user clicks the signon button, causing the client to contact the Merchant realm provider with the request to signon. Along with this request is included information indicating that the signon originated from the eTrade website, as well as is included the eTradeID of the client making the signon request. |
|
6.
|
The Merchant realm provider returns a form to enter the user’s account name. |
|
7.
|
The user types in her account name (“alice@accountsinc.com”) and submits it. |
|
8.
|
The Merchant realm provider decodes the account name indicated in the signon request and determines which account provider is its host (Accounts, Inc.). The Merchant realm then redirects the client to the authentication page of Accounts, Inc., including the eTradeID, the merchantRealmID, and information indicating that the request originated from eTrade. |
|
9.
|
The client receives this redirect and transparently contacts the authentication page of Accounts, Inc. with the eTradeID, merchantRealmID, and originating website. The client has never visited Accounts, Inc., and thus uploads no cookies. |
|
10.
|
Accounts, Inc. determines that it does not know the user (as the client uploaded no cookies) and presents a standard authentication web page (possibly nothing more than a simple name/password form). At the same time, it returns a cookie containing a unique identifier, called the accountsIncID. |
|
11.
|
The client receives this web page and the user enters in her password. |
|
12.
|
Upon a successful authentication, Accounts, Inc. contacts the Merchant realm provider and notifies it that the client associated with merchantRealmID has successfully authenticated to the “alice@accountsinc.com” account. |
|
13.
|
Likewise, Accounts, Inc. contacts eTrade and notifies it that the client associated with eTradeID has successfully authenticated to the “alice@accountsinc.com” account. |
|
14.
|
Finally, Accounts, Inc. redirects the client back to the original eTrade web page. |
|
15.
|
The client requests the original eTrade web page, uploading along with the request the cookie containing the eTradeID. eTrade can then use this eTradeID to determine that the client is acting on behalf of the “alice@accountsinc.com” account. |
|
Figure 2: One-click signon and eTrade
|
|
|
| To the user, this process appears to have five steps the first time through: (1) click the signon button, (2) type in the account name, (3) click the submit button, (4) type in the password, (5) click the submit button. However, this process results in the creation of a number of cookies that streamline all future attempts. Specifically, due to the merchantRealmID cookie, everything changes starting with step 4 the second time through. |
|
| When the client goes to retrieve the image that makes up the signon button, the Merchant realm provider detects the merchantRealmID cookie and thereby identifies the user associated with the client. Because of this, the Merchant realm provider returns a different image that indicates that the user is known, and that a one-click signon is possible. This image might blink, be a different color, or otherwise draw attention to itself. |
|
| Once this one-click signon button is pressed, the Merchant realm provider can skip directly to step 9 (redirect the client to the account provider’s authentication page) because the authentication provider and account name for this client is already known (through the merchantRealmID). Likewise, when the user gets to Accounts, Inc., the account provider detects the accountsIncID cookie created when she last authenticated. Thus, rather than re-requesting the password, the account provider can skip directly to step 13: notifying the originating website of the user’s identity and redirecting the client to the originating page. The result of all of this is that the user need only perform a single click to securely identify herself to the service for the second and all future signon attempts. |
|
| An advantage of one-click signon is allowing the user to do less work to signon to participating websites. Seeing as how a primary user motivator is convenience, this is a valuable improvement. Additionally, service providers need only free up screen real estate for a single signon button. Moreover, because user routing logic is centralized into the realm providers, the service providers need do less work integrating into Talisman. This simplifies the work required of service providers, as well as reduces the chance of maintenance problems. |
|
| Yet, this centralization introduces increased privacy and “single point of failure” risks into an otherwise decentralized system. For better or worse, one-click signon puts the realm providers into a much more controlling position over the realms they regulate. However, it is worth noting that these problems are not so much functional, feature differences, but rather intangible, business differences. |
|
|
|
| The only process more simple than having the user perform a single click is to require nothing. Hence, the no-click signon system. With no-click signon, users are automatically identified to websites upon their first log on, without any manual effort whatsoever. |
|
| There are two apparent ways that such a thing could be implemented. First, the user could install a web-browser plugin that automatically identifies the user wherever she goes. Second, the web page could use Java or Javascript to detect when the User Realm identifies the client, and somehow take action. However, this document describes neither in more detail, as the technical issues posed are less challenging to resolve than overcoming user privacy concerns. |
|
| Specifically, while no-click signon most definitely provides users with convenience (aside from the initial plugin installation), it comes at a cost of increased privacy risk. Quite simply, the choice of whether or not to be identified is taken out of the users’ hands, possibly resulting in users being identified when they would prefer not to be. Thankfully, this privacy risk can be mitigated through clever use of realm certification. |
|
| For example, realms might have multiple levels of certification, such as gold, silver, and bronze. Silver certification might require one-click signon, while gold services might have the benefit of no-click signon. Like everything, the user is free to override the realm’s default trust levels (the user could specify that nobody has the right to no-click signon, or everyone, or anything in between). However, by allowing realms to specify the default trust levels, privacy management can be put into the competitive marketplace. The use of multiple certification levels is described in more detail in the section entitled Active Certification Management. |
|
|
|
|
Synchronous vs. Asynchronous
|
|
|
|
| Each of these signon methods can be done in two ways: synchronous or asynchronous. Synchronous signon would have the actual browser window containing the web page being signed onto used to perform the authentication. In this way, the user is prevented from browsing the website in question until the signon process completes. Alternatively, an asynchronous signon approach would open a separate window that allows the signon process to take part in parallel with the website browsing. Once the authentication process completes in the signon window, the original website browser could be forced to reload. Both synchronous and asynchronous signon provides the same result, just in different ways. |
|
|
|
|