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 websites that use username/password authentication. The client would store the site-specific un/pw data as claims on information cards and leverage the selector's UI to manage these cards. With this enhancement the Higgins client would replace the browser's built-in password manager and offer several advantages:

• 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
• 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
• 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.

Three ways to apply the card metaphor

There are three alternatives to consider in how the card metaphor could be applied to this problem space. Assume that the user has a maximum of M accounts at any single website, and a total of N websites and A accounts in total across all N 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.)

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