Password Card Metaphor Design Options

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

Options

We have identified three alternatives to consider in how the card metaphor could be applied. If we 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 then here are the options:

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.

Tradeoffs

Per account:

• 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: 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)
• Pro: A simple set of single-valued claim values can persist the data within the personal card's XML format
• Pro: Supports multiple accounts (un/pw combinations) on a single site, using the same 'pick a card' UI ceremony for the user to choose between them.
• Con: In situations where the same un/pw credentials are used at multiple sites (this often occurs within an enterprise, where multiple apps access some central authentication directory), it becomes difficult to manage the single un/pw across many cards.
• Con: Lots of cards to manage.
• Con: In situations where the user intentionally reuses the same username/pw combination (as is recommended in some enterprise settings) this approach would lead to a confusing/wasteful excess of cards (that all shared the same un/pw combination).

Per site:

• Pro: Supports automatic import of un/pw data from "legacy" password managers (e.g. IE's password manager, or Firefox's)
• Con: Requires the invention of a way to store in the personal card's XML format a "map" of 1..M un/pw/domain triples as the value of a single claim.
• Con: If a user has multiple accounts on the same web site, this approach requires a UI to choose among these accounts on a single card.
• Con: In situations where the user intentionally reuses the same username/pw combination (as is recommended in some enterprise settings) this approach would lead to a confusing/wasteful excess of cards (that all shared the same un/pw combination).

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
• Pro: User metaphor/experience is consistent with managed password cards (which are a different animal from the personal password cards described on this wiki page, but have already proven themselves to be useful to solve a slightly different set of problems)
• Pro: One person on a higgins dev call (Hank) mentioned that he thought that the per-role approach was more similar to commercial "password managers" and thus would be something familiar
• 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.
• Con: Requires support for a new kind of claim value: an array of string pairs [see Supported Claims section below]
• Con: Requires special logic be added to the self-issued IdP/STS for processing the username and password claims. [See Preventing Phishing section below]
• Pro: Supports multiple accounts (un/pw combinations) on a single site, using the same 'pick a card' UI ceremony for the user to choose between them.