|
|
|
|
|
| The user’s task of maintaining an account actually consists of several sub-tasks, most notably involving accuracy, usage tracking, and access control. |
|
>
|
Allowing the user to verify account accuracy requires ensuring that the user has maximum access to all information known about that user, as well providing some mechanism whereby the user can correct mistakes. The precise manner by which this information is presented and corrected depends heavily upon the type of data being verified – phone numbers, for example, can be corrected directly while credit reports must be corrected through official channels. However, in general it should be assumed that the user can easily and intuitively view and correct data of all types, irrespective of who gathered the data or where it’s stored. |
|
>
|
A key component of increasing a user’s sense of privacy is allowing the user to track the usage of all collected data. In general, whenever a service accesses data on a particular account, that access should be logged in a manner that the user can view. In this way, users can keep tabs on who knows what and, if they don’t like what they see, can have some form of audit trail to contact the appropriate authorities to take action. The goal with this particular feature is not so much to proactively prevent services from misusing data – something that is virtually impossible – but to empower the user to take positive reactive action when problems occur. |
|
>
|
Finally, users should have final authority in setting access control permissions on their data. While users should be able to trust the default settings proposed by the realm providers, more proactive users should be able to expand or constrain access to their information at will. When combined with the ability to track usage, users would have the ability to immediately detect, stop, and report improper usage. The result is a self-regulating system where users, services, and realms all play a part in overseeing the community. |
|
| In general, it is expected that traditional web interfaces be presented to the user to enable all of these tasks. However, the first question is: who hosts these webpages? The answer depends heavily upon who owns the accounts themselves – a question that has three possible answers: shared accounts, linked accounts, and distributed accounts. |
|
|
|
| The most basic, and the first type of account to be supported, is the shared account. Shared accounts are owned and stored by a single account provider, but used by many services. The Microsoft Passport system could be described as a type of shared account provider, in that a central account provider hosts accounts that are shared by all other service providers. However, Talisman differs from MS Passport in that Talisman supports any number of shared account providers while MS Passport only supports one: its own. |
|
| For an example of how it is valuable to support multiple account providers, consider how both Amazon.com and Borders.com are service providers that also offer accounts (thus, they are both service and account providers). Both account providers offer user accounts with nearly the same information: billing and shipping information, browsing habits, purchase records, etc. However, despite their similarities, their accounts are separately maintained and incompatible. |
|
| With Talisman, Amazon.com and Borders.com could create a Booksellers realm that defines a standard Bookbuyer account profile. In this way, accounts on Borders.com could be used directly on Amazon.com – users simply sign onto Amazon.com with their Borders.com accounts. |
|
| Because the account is stored in only a single location, changes made to this account by the account provider will automatically be reflected wherever this account data is used. Following the Amazon.com/Borders.com example, were the user to change her billing address using the Borders.com interface, the new address would automatically be used for all future Amazon.com purchases. |
|
| Technically, a shared-account system is rather straightforward, as illustrated and detailed below: |
|
1.
|
The Booksellers realm certifies Borders.com as authorized to host accounts with the Bookbuyer account profile. This ensures that only legitimate booksellers host Bookbuyer accounts. |
|
2.
|
Likewise, the Booksellers realm certifies Amazon.com as authorized to access information stored in the Bookbuyer account profile. This ensures that only legitimate booksellers access the information stored in Bookbuyer accounts. |
|
3.
|
The user creates a Borders.com account. Because Borders.com is a member of the Booksellers realm, the user’s account contains the Bookbuyer account profile. |
|
4.
|
The user signs onto Amazon.com using the Borders.com account. Because both Amazon.com and Borders.com are members of the Booksellers realm, they can share accounts. |
|
5.
|
Amazon.com contacts Borders.com and requests access to the Bookbuyer account profile. |
|
Figure 1: Shared Accounts with Borders.com and Amazon.com
|
|
|
| A major strength of the shared account strategy is its low barrier to entry. Participating services within an industry can adopt shared accounts one at a time, without giving up control over their existing userbases, authentication mechanisms, or way of business. |
|
| However, this strategy also has weaknesses. In particular, remote services (meaning, services using accounts hosted by some other account provider) are limited to exclusively that which is contained in the account profile. Although the account provider is free to store information about the user that does not fall into a standard account profile, remote service providers are limited to the data in the account profiles alone. Because of this, remote services are limited by the pace at which the account profile evolves. |
|
| For example, while Borders.com users could technically sign on to eTrade with their Borders.com accounts, eTrade requires different types of information than Borders.com. Even were Borders.com and eTrade to both join a Merchant realm that defined a Billing account profile, containing information of interest to both services, eTrade still would require more information to offer a valid service. The most reasonable solution to this problem would be for eTrade to create local accounts to store information about remote users – a solution akin to linked accounts described in the next section. |
|
|
|
| A more advanced type of account is the linked account. Linked accounts extend the base shared account functionality with the ability to maintain local information on remote accounts. Said another way, different accounts across many account providers can be “linked” such that those portions that are the same (and conform to the account profile) are synchronized. However, unlike shared accounts, each service is free to retain additional information about the remote user. Each service provider (which would also be an account provider) would maintain its own account for the user, with those accounts linked between account providers. |
|
| Returning to the Borders.com / eTrade example, assume Borders.com users are automatically given a new eTrade account to store eTrade specific data. Thus, while Borders.com and eTrade are both members of a Merchant realm with a Billing account profile (with credit card and billing address information), they each maintain separate information relating to buying books or managing a portfolio, respectively. |
|
| Both services expose a user interface to allow maintenance of their known subset of the account. In this case, Borders.com exposes an interface to modify billing information and book preferences, while eTrade exposes a UI for billing information and portfolio management. Both services allow modifications to the same Billing account profile, but because the accounts are linked, any changes to the billing information on one account are automatically reflected in the other. In this way, were the user to change her Billing account profile in the Borders.com interface, eTrade would automatically be updated. |
|
| The technical implementation of this linked-account system is a bit more involved than shared accounts, but is still rather straightforward: |
|
1.
|
The Merchant realm certifies Borders.com as authorized to store and make modifications to the user’s Billing account profile. |
|
2.
|
The Merchant realm certifies eTrade as also authorized to store and modify the account. |
|
3.
|
The user creates an account on Borders.com |
|
4.
|
The user visits eTrade and has a new account automatically generated upon signing on with the Borders.com account. |
|
5.
|
The user modifies her billing information through the Borders.com user interface. |
|
6.
|
This modification is automatically synchronized to the eTrade linked account. |
|
Figure 2: Linked Accounts between Borders.com and eTrade
|
|
|
| The major difference between linked and shared accounts is the use of multi-master replication. Whereas shared accounts have one defined “master” copy stored on the account server that all other services make use of, linked accounts are actually owned by many account providers. This redundancy allows for increased performance, reliability, and overall scalability, but comes at the cost of greater complexity. This complexity can be tackled with any level of consistency, from synchronous, globally locked ACID (atomic, consistent, isolated, and durable) transactions to asynchronous, conflict-resolved multi-master transactions. However, unless this problem is solved with an off-the-shelf solution (which currently does not exist), adopting linked accounts would require a great deal of custom development. |
|
| From a usability perspective, this approach is much stronger than shared accounts. Users retain the ability to make global changes from a single location, while services gain the ability to store local information about remote accounts. Yet there is still work to do: users still need to go to multiple places in order to administer their entire account. For example, a user could not update or monitor her eTrade portfolio from her Borders.com account. Likewise, she could not review her book buying preferences from within eTrade. While each service is free to add its own data to the user’s account, doing so complications administration of that data for the user. This final problem is resolved through distributed accounts. |
|
|
|
| The final type of account is an evolution past linked accounts to fully distributed accounts. With linked accounts, there is still the concept of users having many separate, but synchronized accounts. With distributed accounts, this changes. Each user has a single distributed account: There is only one account that it is physically “distributed” over many locations. |
|
| With linked and shared accounts, service providers are also assumed to be account providers – users are expected to get new accounts at each service. However, as the size, complexity, and accountability requirements forced upon services by the realms grow, the cost and difficulty of hosting accounts will increase. User accounts do not directly produce revenue, yet require costly infrastructures to maintain. At some point service providers will determine that it is not their core competency to host user accounts, and will instead choose to fully outsource account management. However, current service providers do not have the benefit of that choice – there is no way for services to store detailed information about a user without services hosting the user accounts themselves. |
|
| Furthermore, as accounts grow to include greater amounts of more diverse information types, the cost of account providers storing their own accounts grows dramatically. Consider, for example, the different requirements of medical patient records (which are reasonably small and requires extreme security) and home videos (which are extremely large and require less security). By recognizing the inherently different needs of different types of data, different storage infrastructures can be built for different types of data. These different storage infrastructures might be physically very different, and of prohibitive expense for a single account provider to support. |
|
| Talisman seeks to resolve these problems by anticipating the need for specialized account and storage providers. Account providers have been discussed already; they are just service providers that specialize in managing accounts. In a similar vein, storage providers are just service providers that focus on storing and hosting data. In all likelihood, account providers will also be their own storage providers at the start. However, as the burden of storing accounts increases, the argument for outsourcing storage will become increasingly compelling. |
|
| A high level overview of the implementation is given below. |
|
1.
|
The Brokerage realm certifies that Accounts, Inc. has taken the necessary steps to verify that the user legitimately maps to an actual human being. This prevents people from signing up with nothing more than an email address, and allows other services to offload the problem of verifying user authenticity to the account provider. |
|
2.
|
The Brokerage realm certifies that BitsRUs is secure and reliable enough to store Portfolio account profiles. This type of certification prevents fly-by-night storage providers from luring people into storing their sensitive and valuable data in an inadequate facility. |
|
3.
|
The Brokerage realm certifies that eTrade is a legitimate brokerage, and is by default authorized for both read and write access to the Portfolio account profile. |
|
4.
|
The user visits Accounts, Inc. and creates an account. |
|
5.
|
The user visits eTrade and signs on with the Accounts, Inc. account. |
|
6.
|
eTrade contacts Accounts, Inc. and indicates it’d like to add the Portfolio account profile to the user’s account, and requests a location at which to store it. |
|
7.
|
Accounts, Inc. contacts BitsRUs, purchases space of the quality necessary the Portfolio account profile, and notifies eTrade. |
|
8.
|
eTrade contacts BitsRUs and uses it to store the Portfolio account profile. |
|
9.
|
Later, the user visits Accounts, Inc. for central administration of her account. |
|
10.
|
Accounts, Inc. draws together the necessary data, retrieving the Portfolio account profile from BitsRUs, and provides a unified administration interface. |
|
Figure 3: Distributed Accounts and eTrade Portfolios
|
|
|
| The goal of this system is to break apart needs common to many services, such that these needs can be independently addressed by separate services in a competitive marketplace. The result is an environment where barriers to entry are reduced and each service can focus on its core competency. At the same time, users can more safely and with greater confidence provide personal information, enabling services to provide detailed personalization and streamlined services. |
|
|
|
|