Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Password Card Metaphor Design Options

Revision as of 09:32, 9 March 2009 by Unnamed Poltroon (Talk) (New page: ''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 a...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.

Back to the top