Password Card

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

As is says on the home page:

• A long term goal is that [the Higgins] client offer what might be called "universal login." This is the ability to log you in to almost any website or app (called a Relying Party (RP)) using a variety of methods including I-Card, OpenID and username/password.

This page focuses on the username/password subgoal mentioned above.

Benefits

The basic idea is to enhance the Higgins client to enable it to login to existing, unmodified websites that use username/password authentication (e.g. Amazon.com or BestBuy.com). The client would store the site-specific un/pw data as claims on information cards and leverage the users's selector to manage these cards.

With this enhancement the Higgins client would replace the browser's built-in password manager and offer these advantages:

• Single metaphor. All login-related information (whether un/pw or other kinds of personal and managed i-cards) would be managed in one place under a single user metaphor: the i-card.
  • If standard personal cards are used to store un/pw data it can be used as a standard un/pw archive format
• Multi-Browser. Since selector's card stores are external to the browser, a person with multiple browsers will have access to all of their passwords on all of them
• Multi-Device. With a synchronizing selector, the user's passwords are distributed and synchronized across multiple computers and devices
• Security: since few users turn on the optional "master password" protection in their browsers, most user's password data can easily be stolen by malicious browser plugins. With Password Cards the user's data is managed external to the browser and with some Higgins selectors protected by a "master password" that we believe will be used more often than the browser's master password mechanism.

Applying the Card Metaphor

There are three alternatives to consider in how the card metaphor could be applied here. Assume that the user has a maximum of M accounts at any single website, and a total of N websites and total of A accounts across all N>30 sites.

Per account

One password card would store one un/pw for one website. The user would have 1..M password cards for a single website. The user would have A password cards in total.

Per site

One password card would store the user's 1..M un/pw combinations for one website. The user would have N password cards in total.

Per role

One password card per role. One password card would store one SET of N username/password pairs. The user would have at least M password cards in total, though likely less than about 2M. Here the term "role" is use liberally, a mother with two children might decide have only one password card for herself and one additional card each for each of her children.

Requirements

a) Support these Password Card Use Cases

b) Adhere to these constraints:

• Add no extra UI on the browser chrome (e.g. a toolbar). Roboform and Google Toolbar require you to click a button on a toolbar.
• Automatically highlight fields that it can fill (like Google Toolbar, Sxipper). Browsers do not natively do this
• Implement a superset of the browser's built-in functionality

c) If either the per-account or the per-site design options is used, the selector must segregate Password Cards from other cards to eliminate clutter. Some Higgins selectors support "categories" which can be used to achieve this.

• Password Cards cannot be moved to other categories.
• Cards other than Password Cards cannot be moved to the Password Card category.
• The Password Card category cannot be deleted or renamed

d) Global On / Off – add a control to disable Password Cards.

• Default is “on”.
• If turned off, the Password Cards category is hidden from the UI, but Password Cards are not deleted. (In other words, if a user turns this off then back on, they should not have lost anything.)

Card Metaphor Tradeoffs

Per role:

• Pro: Small number of cards means that selector UI doesn't have to have special facilities (e.g. categories) for dealing with hundreds of cards (approx one per site) [Note: this is a non-issue for some Higgins selectors that have been designed in anticipation of managing perhaps 100 relationship cards].
• Pro: User can customize background image of small number of cards to provide antiphishing protection (recognizable card wallet). [Then again, this feature is already present on the managed cards in the person's selector]
• Pro: Fewer data objects (cards) for Higgins server operators to have to manage
• Con: since "role assignment" data is simply unavailable from legacy password managers, automatic import of a person's passwords and the generation of these password cards is not possible. An interface must be presented and the user must manually sorting their existing un/pw combinations (30+) into a handful or so of per-role password cards.

Per site:

• Pro: The per-account model is consistent with Higgins R-Cards where we expect the user to have one relationship card per site and potentially 100 cards. Then again, there may be advantage in keeping a separation between the user's profile on Facebook (e.g. as held by a Facebook relationship card)
• Pro: Supports automatic import of un/pw data from "legacy" password managers (e.g. IE's password manager, or Firefox's)

Per account:

• Pro: a Facebook password card (that only stores your Facebook un/pw) could gracefully be upgraded into a full R-Card that added your profile attributes. [OTOH, if we decide that there's a benefit to keeping your un/pw separate from your profile data then an r-card for Facebook could logically and conceptually be completely separate from a "per role" card that has (among a hundred others, your Facebook un/pw).]
• Pro: Supports automatic import of un/pw data from "legacy" password managers (e.g. IE's password manager, or Firefox's)

Open Issues

What Triggers the fill. Alternatives:

1. the user must click in username (or password??) field to trigger fill
2. automatic - native password managers automatically fill